블로그 이름

Spring Boot / 순수 Java 어플리케이션 운영 시 JMX 보안 설정 및 오류 해결 방법을 정리하고자 한다. 1. JMX 인증 설정jmx.id=xxx, jmx.pw=yyy 와 같이 프로퍼티로 설정하는 것이 아님JMX 인증은 application.properties 에 ID/PW 를 쓰는 게 아닌 연결 시 ID/PW 를 사용하는 것이며, JMX 인증은 JVM 레벨에서 설정하며 ID/PW는 반드시 파일로 관리해야 한다. JMX 기본 설정 (Windows 기준)com.sun.management.jmxremote=truecom.sun.management.jmxremote.port=1099com.sun.management.jmxremote.rmi.port=1099com.sun.management.jmxr..

A테이블에 데이터 약 10만~30만개, B테이블에 데이터 약 300만개 존재하는 상태에서 JOIN 사용 시 대용량 데이터 JOIN이 발생하여 속도 저하 및 쿼리 성능 저하 및 리소스 과다 사용하는 경우가 존재. 해당 쿼리를 효율적으로 변경하기 위해 NOT EXISTS 를 사용하기로 한다. 우선 목표는 A테이블에는 존재하나 B테이블에 미존재하는 A를 조회하고자 하였고, 참조키로 C를 사용하는 상황이다.기존 쿼리SELECT * FROM A LEFT OUTER JOIN B ON A.C = B.C WHERE B.C IS NULL해당 쿼리의 경우 직관적이나 (A테이블 유지, B테이블 조인, B테이블에 C가 없는 A를 조회)동작 방식을 보면1. A과 B를 먼저 JOIN2. 조인 결과를 전부 생성3. 그 중 B가 N..

Liquibase 를 사용하여 DB 형상 관리 중 context를 지정한 changeset이 실행되지 않는 현상 발생 INSERT INTO test_table (id, name) VALUES (1, 'test'); 위 changeSet 추가 후 Liquibase 실행 시 에러는 발생하지 않으나 쿼리가 실행되지 않고, databaseChangeLog 테이블에도 기록되지 않는다. 로그에도 별다른 오류가 없다. 우선 Liquibase에서 context가 무슨 역할을 하냐면 특정 환경에서 실행되어야 하는 changeset을 구분하기 위한 필터 조건이다. context 옵션을 "test" 로 하면 test인 changeset만 실행되고, "dev" 로 하면 dev인 changeset이..

SQL문 실행 중 예외가 발생. 에러 메세지는 다음과 같다.Cause: java.sql.SQLSyntaxErrorException: 'i.test’ isn’t in GROUP BY ...딱봐도 GROUP BY 절 문제 같아 보인다.해당 에러는 MySQL/MariaDB 환경에서 GROUP BY 문법 규칙을 위반했을 때 발생하는 오류이다. SQL문은 다음과 같다.SELECT i.id, i.test, COUNT(*) AS cntFROM item iGROUP BY i.id; ORACLE 이나, 일반적인 MySQL/MariaDB에서는 발생하지 않으며, sql_mode 에 ONLY_FULL_GROUP_BY 옵션이 활성화되어 있는 환경에서 발생한다. GROUP BY 같은 경우 SELECT 절에 있는 컬럼이 GROUP..

에러로그는 다음과 같다org.springframework.dao.IncorrectResultSizeDataAccessException: result returns more than one elements; nested exception is javax.persistence.NonUniqueResultException: result returns more than one elements 에러 발생 행은 JPA 쿼리 findById 메서드에서 발생하였다. 단건 조회를 기대했는데 실제로는 여러 건이 조회된 경우에 발생하는 에러로, 조회 메서드는 1건 결과를 기대하였으나 DB 조회 결과가 2건 이상이 조회되어 JPA가 어떤 값을 반환해야 하는지 알 수 없어 발생하는 에러다. User user = userRep..

Java에서 배열 내 특정 값 존재 여부 확인 시 List와 Set의 성능 차이를 비교하고자 한다.(10개 정도 검사하는 경우 크게 차이는 안나는데 몇만개 를 넘어 자주 사용하는 경우 성능 차이가 나기 때문에) 자료구조대표 구현체contains() 시간복잡도탐색방식ListArrayListO(n)순차 탐색SetHashSetO(1) 평균 / O(n) 최악해시 기반SetTreeSetO(log n)이진 탐색 트리List(ArrayList) 는 내부적으로 앞에서부터 끝까지 하나씩 비교하며 equals() 를 사용하여 값을 비교한다. 때문에 데이터가 많아질수록 시간이 선형적으로 증가한다.Set(HashSet) 은 hashCode()로 해시 버킷 위치를 계산하며 동일 버킷 내에서 equals() 로 비교한다. 평균적..

우선 해당 메서드의 차이점을 비교하게 된 계기는 다음과 같다.API로 데이터 조회 후 특정 코드가 실행되도록 하려 하였으나, 동기로 동작하도록 수정하는 부분에서 정상 동작하지 않거나 일부 버벅이는 현상이 존재하여 setTimeout과 Promise 중 한 메서드를 사용하여 해당 현상을 해결하고자 하였다.결과적으로 말하자면 Promise보다 setTimeout이 나중에 실행된다. JavaScript 비동기 처리에서 setTimeout과 Promise는 자주 등장하는 개념으로 실행 순서, 동작 방식, 사용 목적에서 차이가 존재한다.오늘은 JavaScript 실행 모델(Event Loop), 두 메서드의 내부 동작, 실행 순서 차이 (Microtask vs Macrotask) 를 알아보고자 한다. 1. Jav..

서버 운영 중 시간이 갑자기 이상하게 표시되는 현상 발생Java 프로그램이 실행된 후, 서버의 OS 타임존을 변경하는 경우 서버 OS의 타임존은 변경되지만 이미 실행 중인 프로그램의 타임존은 함께 변경되지 않는다. 이 때문에 서버의 OS 타임존을 변경하는 경우 운영 중인 프로그램도 전부 내린 뒤 수정하여야 하지만 프로그램을 내리지 않고 리눅스 OS 타임존을 변경한다면 DB에 데이터가 잘못 쌓이기 때문에 리눅스OS의 타임존이 변경된 시각을 확인하여 잘못 쌓인 데이터를 복구해주는 작업이 필요한데, 이 때 정확한 시각을 확인하기 위해 리눅스 OS 타임존 변경 이력을 확인한다. timedatectl : 우선 현재 OS의 타임존 확인, Asia/Seoul (KST, +0900) 표시됨stat /etc/localt..

운영 중인 서버에서 문제 발생 시 원인 분석을 위한 스레드 덤프 출력 및 분석 방법을 정리하고자 한다.Java 어플리케이션이 갑자기 느려지거나 응답이 멈추는 등 이슈 발생 시 스레드 덤프를 사용하여 원인을 분석한다. 스레드 덤프(thread dump) 는 JVM 내부에서 실행중인 모든 스레드의 상태와 스택 정보를 보여주는 로그다. 1. 스레드 덤프 출력 Java 스레드 덤프 출력 방법은 여러가지가 있다. kill -3, jstack, 톰캣 출력 등 다양하게 있는데 보통 jstack 으로 하면 되므로 jstack 명령어로 출력하는 방법을 정리하고자 한다. jps -l : PID 확인jstack -l > threadDump.txt : 스레드 덤프 파일로 출력 2. 데드락 찾는 방법 데드락이란 스레드가 서로..