리승자이의 삽질 그리고 정리

개발을 하다가 어드민을 사용하시는 부분에서 제보가 들어왔다.request log를 보니 LocalDate 를 받도록 되어있는데 분명히 yyyy-MM-dd 형식으로 request log가 찍혔는데?근데 좀 달랐다. access-language가 en-US로 되어있는것!어드민 사용하시는 분에게 여쭤봤더니 자신은 크롬 브라우저를 영어모드로 사용한다고 했다.시작점아, 설명하기 앞서 이 상황은 앞단에 proxy 서버가 따로있다. 호출 방식이 아래처럼 되어있다.앞단은 proxy server라고 지칭하겠다.client ->  proxy server -> 우리의 serverproxy server에서는 우리 server로 bypass 시켜주며 그 때 call 해주는 방식을 Spring Cloud OpenFeign을 사용..

개요 회사의 기술스택에서 카프카를 사용하고 있다. 내가 이번에 정리하는 글은 막연하게 ack을 날리는 부분에 있어서 간과했던 로직 때문에 벌어진 이슈를 정리한다. 어떻게 로직이 생겼었는가? 우선 카프카를 사용하기 위해선 스프링 부트에서 Spring for Apache Kafka 를 사용해야 한다. 나는 로직에서 try-catch-finally 를 붙여 사용했는데 동료 개발자분께서 의도하신 것인지는 모르겠으나 catch절을 빼고 로직을 구성했다. @KafkaListener public void consumeExample(final ScrapeUpdateDto dto, final Acknowledgement ack) { try { // do something } finally { ack.acknowledge..

의문점 스크래핑 로직 실행 시간에 대해 의문을 가졌다. 평균 시간이 그럭저럭 다들 비슷한 수준에 머무는데, 이상하게 한 부분만 너무 느렸다. 증권사에 대한 스크래핑 내역이었는데, 특정 증권사만 중복 로그인이 감지되었을 경우 30초를 대기했다가 다시 수행할 수 있게 하는 로직이 들어있었고, 테스트 코드는 그에맞는 정말 30초를 기다리는지에 대한 여부를 테스트 하고 있었다. 🤔 그냥 30초를 기다리는것보단 특정한 법인이 아니라면 30초를 기다리지 않는다 를 테스트하면 되지 않을까? 이렇게 생각했던 이유는 30초를 테스트에서 기다리는 비용이 비싸다고 생각했고, 전체 테스트를 돌릴 때 이 부분때문에 30초를 더 기다려야 한다는 것이다. 그리고 milliseconds 차이값을 비교했기에 간헐적으로 실패하는 경우도..

예제는 깃허브에 있다. 트랜잭션을 공부했다고 생각하고 업무에 임했던 나였는데, 도저히 풀리지않는 느낌으로 예외를 받았던게 있다. 이전에 한번 포스팅했던 Stream Closed 에러였는데 이게 또 한번 나를 붙잡았다. 처음 개발환경에서 OpenFeign을 사용하면서 또 logging level에서 IOException이 나는줄알고 이부분으로 삽질을 했다. 근데 그게 아니어서 이 포스팅을 작성했다. HelloController.java @RestController @RequiredArgsConstructor public class TestController { private final TransactionParentService transactionParentService; @GetMapping("/tra..

회사의 서비스들이 여러개로 쪼개져있다. 그래서 우리는 주로 FeignClient를 사용하는데, 애를 먹었던 로깅레벨에 대해 포스팅한다. 업무중에 삽질을 진행했었으며, 해당 내용으로 자바스럽게 고쳤던 경험을 좀 풀어본다.. 스프링 프레임워크를 사용하고 있기에 여기서 같이 제공해주는 Spring Cloud의 OpenFeign을 사용하였다. 아래는 사용하는 예시이다. 해당 예시처럼 나는 FeignClient를 구현했었다. 물론 @EnableFeignClients 는 별도의 Configuration 클래스 파일에 설정을 해주었었다! 여기까지는 일단 기본적인 설정이지만, 아래의 레벨 설명이 진짜다. Feing Logging Level은 총 4단계로 이루어져있다. NONE: 로깅 없음(Default) BASIC: ..

오랜만에 포스팅하는데 회사에서 그동안 앱 2.0 버전을 출시한다고 이래저래 바빴던 나날을 보냈다. 결과적으로는 만족스러운 출시..? 였던것 같다 ㅋㅋㅋ 버그도 많았고, QA 엔지니어께서 고생을 많이 하셨을 수도 있고 내가 구현한 메시지 플랫폼도 테스트하기가 정말 까다로웠다. 각설하고.. 해당 에러사항을 구현하는건 Kafka를 이용하지 않아도 되기 때문에 RestAPI로 구현했다. (+ 테스트코드로만) 모든 코드는 깃허브에 있다. 이번엔 무슨 버그였냐? 이런 에러가 쏟아져나왔다. 기존 레거시 푸시는 NHN Toast를 이용한 푸시서비스로 구성되어 있었다. 변경한다고 해도 과도기가 존재하기 때문에 바로 지울수는 없고 이전 앱을 사용하는 사용자들에게는 해당 푸시로 알림은 계속 받아야되기 때문이다. 왜 났던 에..

Jenkins 위키백과에서 발췌한 내용에 따른다. 젠킨스(Jenkins)는 소프트웨어 개발 시 지속적 통합(continuous integration) 서비스를 제공하는 툴이다. 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git등의 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해 준다. MIT 라이선스를 따른다. 발생 시점 현재의 회사에서 배포를 젠킨스를 이용하여 배포를 진행한다. 신규 기능개발과 레거시를 청산하는 작업을 주로 해왔었어서 이쪽을 고치는게 우선은 아니었다. 그래서 모르고 있었던 것일수 있다. 에러 상황을 확인해보자 에러 상세 [Pipeline] End of Pipeline java.lang.InterruptedEx..

Unable to load credentials from any of the providers in the chain AwsCredentialsProviderChain(credentialsProviders= SystemPropertyCredentialsProvider(), EnvironmentVariableCredentialsProvider(), WebIdentityTokenCredentialsProvider(), ProfileCredentialsProvider(), ContainerCredentialsProvider(), InstanceProfileCredentialsProvider()]) : SystemPropertyCredentialsProvider(): Unable to load credentia..

전역 값 회사 프로젝트에서 resources 디렉토리에 있는 설정파일은 application.properties를 사용한다. 그래서 여기에 값을 할당해주고 @Value를 가져다가 사용한다. properties의 값을 가져올때는 @Value("${properties키 값}")으로 불러오기 때문에 이번에 내가 진행하게된 프로젝트 설정파일 application.yaml에도 똑같이 @Value가 적용될줄 알았다. 근데 적용하려고 보니까 에러가 나는것이다. 에러메세지부터 바로 보자. 에러메세지 Could not resolve placeholder 'application.open-api.adminKey' in value "${application.open-api.adminKey}" 라는 에러가 발생했..

HandlerMethodArgumentResolver 이 HandlerMethodArgumentResolver에 정의되어있는 자바독을 읽으면 주어진 요청의 컨텍스트에서 메소드 매개변수를 인수 값으로 해석하기 위한 전략 인터페이스라고 설명되어 있다. 이 HandlerMethodArgumentResolver에는 이렇게 두개의 메소드가 있는데 supportsParameter()로 메소드의 매개변수를 처리할 수 있는지 여부를 판단한다. @RequestBody @RequestBody 어노테이션을 읽으려면 HandlerMethodArgumentResolver AbstractMessageConverterMethodArgumentResolver AbstractMessageConverterMethodProcessor R..