결제 서비스를 만들고 테스트하던 중 인덱싱 되지 않은 컬럼을 검색 조건으로 활용한 Update에서, 단건의 요청 처리에 대해 문제가 없었으나 다수의 요청 동시 처리 시 데드락이 발생하는 상황을 경험했다. 1. 데드락 확인 org.springframework.dao.TransientDataAccessResourceException: execute; SQL [UPDATE payment_ordersSET payment_order_status = :status, updated_at = CURRENT_TIMESTAMPWHERE order_id = :orderId]; Deadlock found when trying to get lock; try restarting transaction 스프링을 통해 어떤 로직을..
스프링의 Task Executor 설정을 특별히 건드리지 않았더니 요청이 몰려드는 시점에 @Async를 붙인 메서드들의 처리가 느려지는 것을 확인했다. 서버 설정을 수정하는 김에 Task Executor 관련 주요 개념과 설정을 정리하려 한다. Task Executor 스프링 어플리케이션에서 @EnableAsync 설정을 추가하고 @Async가 붙은 메서드를 런타임에 호출 시 Runnable 혹은 Callable의 형태로 스레드 풀의 Blocking Queue에 작업을 등록한 뒤 비동기로 처리된다. 비동기 처리 시 작업을 등록할 스레드 풀이 필요한데, 스프링 부트가 아닌 순수 스프링 환경에서는 별도의 설정이 없다면 AsyncExecutionInterceptor에 의해 요청마다 스레드를 새로 생성하는 ..
회사에서 한 장비에 수십 개의 도커 컨테이너를 동시에 운용할 상황이 생겼다.컨테이너 각각에서 작업이 이루어지고 ssh를 통해 접속해서 확인할 수 있도록 구성하였는데,컨테이너가 많아지자 모든 컨테이너로의 ssh 접속이 불가해졌다는 연락을 받았다.ssh -vv로 로그를 확인하니 접속 시 인증 단계는 정상적으로 넘어가나, 셸 할당이 실패하는 상황이었다. 결론적으로는 ssh 접속 시의 사용자에 대한 프로세스 제한을 늘려주어 임시로 해소하였고,각 컨테이너에서의 사용자 UID를 구분해 주어 근본적인 문제를 해결하였다. 컨테이너에서의 ulimit -a로 프로세스 제한을 확인했을 때는 분명 unlimited로 표시되었고,서버 자원은 충분하며 각 컨테이너에서의 프로세스/스레드는 수백 개 수준이었는데도 프로세스 생성이 불..
사내에서 diff와 patch를 다룰 일이 잦아 관련 내용을 정리해보고자 한다. git version 2.39.2 (Apple Git-143), patch 2.0-12u11-Apple에서 확인한 내용이며 버전에 따라 출력 형식은 조금 변할 수 있다. diff? git diff라는 명령으로 사용 가능하다. 깃의 워킹 디렉토리와 스테이징 영역을 비교하거나, 특정 커밋과 비교하거나, 로컬과 원격 깃 레포지토리를 비교하는 명령이다. diff 사용법 diff라는 폴더에 first.txt라는 파일을 생성해 임의의 최초 커밋을 생성한 다음, second.txt라는 파일을 생성한 뒤 git log를 확인한 결과는 아래와 같다. # git log commit 8d475c23f8ac7f857ca6f1ab7790f03446..
JVM이 Lambda를 어떤 방식으로 다루는지 궁금해서 찾아보던 중 Oracle 블로그에서 Red Hat의 시니어 엔지니어인 Ben Evans가 쓴 글을 찾을 수 있었다. 이를 이해하며 Lambda가 JVM에서 어떻게 다뤄지는지 살펴보려 한다. https://blogs.oracle.com/javamagazine/post/behind-the-scenes-how-do-lambda-expressions-really-work-in-java https://blogs.oracle.com/javamagazine/post/behind-the-scenes-how-do-lambda-expressions-really-work-in-java blogs.oracle.com javac, javap 모두 19.0.1을 사용하였다...
버전이 올라가며 이전, 이후 버전의 DB 스키마가 크게 바뀌었다. 주요 테이블의 네이밍이 수정되었고 서비스 로직이 변경되며 컬럼의 위치도 일부 수정되었다. 개인 별로 저장되던 스터디 참여자들의 진행 정보가 기획이 수정되며 함께 관리되도록 바뀌었다. 문제: 스키마는 바꼈지만 이전 버전의 데이터도 신버전에서 실시간으로 보고 싶다 스키마의 변경 자체는 크진 않지만 신규 배포를 무중단으로 진행해야 한다는 점이 가장 큰 문제였다. 서비스에는 다음의 세 주요 기능이 존재한다. 1. 스터디 함께 진행하기 2. 혼자 공부하기(다인 스터디를 혼자 진행하는 형태) 3. 자신의 스터디 기록 조회하기 이번 배포에서는 기능이 빈약한 '1. 스터디 함께 진행하기'에 실시간 동기화 기능을 추가하는 것이 가장 큰 변경이었고, 기능이..
- Total
- Today
- Yesterday
- Spring
- GitHub Discussion 템플릿
- GitHub Discussion
- 의존성 주입
- RandomPort
- Jenkins 예약 배포
- 함수형 인터페이스
- Spring 테스트
- 람다식
- Java
- stubbing
- MySQL 이벤트 스케줄
- java switch case
- 우테코
- Spring Boot Monitoring
- 우테코 프리코스
- 생성자 주입
- JPA JSON
- logback-spring.xml
- springboottest
- Fromtail
- GitHub Discussion Template
- 자바
- Payload 암호화
- 우테코 5기
- thenComparing
- JPA
- 스프링
- MySQL
- invokedynamic
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |