kafka @RetryableTopic 에 대해 알아보다보니 궁금한점이 생겨 질문 드립니다. @RetryableTopic 가 없어도 retry 는 기본적으로 진행하는거 같은데요. 제가 알아본 바로는 아래와 같은 차이점이 있는것 같았습니다. @RetryableTopic 을 사용하지 않으면 'dlt' 로 메시지가 이동되지 않는다. @RetryableTopic 을 사용하면 'dlt' 토픽이 없는 경우 자동으로 만들어주고 dlt 토픽으로 메시지를 이동시켜준다. @RetryableTopic 을 사용하지 않으면 재시도는 하지만 재시도동안에는 partition 을 blocking 한다 (= 블로킹). @RetryableTopic 을 사용하면 재시도 하기전에 retry 토픽으로 이동시키고 consumer 의 스레드를 blocking 하지 않고 별도 스레드에서 retry 를 진행한다. (= 논블로킹) 강좌에서는 retry 중에는 partition 이 blocking 된다고 하셨는데, 그 부분과 좀 다른거 같아서 문의 드립니다..! 만약 @RetryableTopic 이 논블로킹으로 별도 스레드에서 진행이 된다면 순서보장이 안되는거라서 순서보장이 필요하다면 이걸 사용하면 안되는게 아닌가 싶습니다.
강의 앞부분에서는 JAVA에서는 print 뒤에 ln을 붙여서 개행한다고 설명해 주셨습니다. 그런데 뒷부분 예제에 Systenm.out.print("Character:"+ch+"\n"); 이런 명령문구가 있는데 정답 해설하실 때도 \n에 대해서는 설명 안해주시네요. 작성해 주신 출력 결과를 보면 Character:A가 출력되고 개행이 되는 것 같은데, JAVA에서 +"\n"으로도 개행을 할 수 있는건가요?
[Live 챌린지] 6주 완성! 개발 실무를 위한 고농축 바이브코딩 (Cursor AI, Figma)
셀렉트박스 다크모드에서 사용할수있는 체크아이콘 파일이없습니다. 라이트모드에서는 check_outline_light_xs.svg를 사용하는데 다크모드에서는 사용할 아이콘이없어서 동일한 아이콘을 사용해 피그마에서는 체크아이콘이 하얀색인데 초록색으로 생성되는 문제가 있습니다.
강의를 보다보니 궁금한 점이 있어 질문 남깁니다. 첫번째로 궁금한 점은 AbstractPagingItemReader의 코드를 doRead 함수 안에서 lock을 잡고 있으며, doReadPage가 끝난 후 lock을 푸는 것을 확인할 수 있었습니다.. doReadPage에 실제로 paging 로직이 존재하니 사실상 paging 로직은 직렬로 수행되는 것과 다를 바 없을 것이며, 성능적으로 크게 증가하지 않을 것 같다는 생각이 드는데요.. (거의 직렬 처리와 유사할 것 같다는 생각이 드네요..) 사실상 병렬 처리라해도 Reader쪽에서 성능 향상이 거의 없다고 보면 될까요? 두번째로 궁금한 점은 AbstractPagingItemReader 상위 클래스인 AbstractItemCountingItemStreamItemReader의 read 함수를 보니 멤버 변수인 currentItemCount를 증가시키는 로직이 존재하더라구요.. 이 부분도 병렬처리에 문제가 될 것 같다는 생각이 들고 해당 클래스의 주석에도 "Subclasses are inherently <b>not</b> thread-safe." 라고 적혀있는 것으로 봐서는 문제가 존재하는 것 같은데요.. 그럼에도 불구하고 기능상 영향이 없으니 하위 클래스인 AbstractPagingItemReader는 thread-safe하다고 나와있는 것이라고 생각하면될까요??
[Live 챌린지] 6주 완성! 개발 실무를 위한 고농축 바이브코딩 (Cursor AI, Figma)
Cursor ⚠ The window terminated unexpectedly (reason: 'oom', code: '-536870904') We are sorry for the inconvenience. You can reopen the window to continue where you left off. ☐ Don't restore editors 왜 이런걸까요? 이때까지 이런적이 없는데 ui 생성에서 버튼 생성할때 위와 같은 오류가 생겨요 커서 종료하고 다시 해도 계속 이런 오류가 생기는데 ai에게 물어보니 메모리 부족이라는데 제컴퓨터가 메모리가 부족한 사양이 아니라서요 그리고 다른 앱도 안키고 하는데 계속 같은 일이 발생하네요 오류나서 정지된곳 부터 계속 해달라고 요청해서 마무리 하긴했는데 해결책이 있을까요? 위 사항에서 클로드가 버튼 노드를 못찾고 아래와 같은 피그마 문서 전체 검색을 한다고 한후 메모리 폭발한것을 확인했습니다. 노드 3:1461은 "드롭다운"이라는 프레임으로, 버튼 컴포넌트가 아닌 것 같습니다. 프롬프트에서 "참고할 공통컴포넌트 노드ID: 3:1461"라고 했는데, 이것이 버튼이 아닐 수 있습니다. 버튼 컴포넌트를 찾기 위해 주변 노드들을 확인하거나, 문서 정보를 확인해야 할 것 같습니다. 또는 현재 index.tsx의 주석에 있는 "Figma Referen ce: Node ID 3:1528"을 확인해보겠습니다. 프롬프트에 조건-피그마) 참고할 공통컴포넌트 노드ID: 3:1461 다음 노드의 스타일만 가져와. 절대 다른 노드 탐색하지 마 위 빨간색 문구를넣고 해결했습니다. ai 가 커서룰도 대충읽고 안지키고 그냥 대충 만드네요 ㅠㅠ 몇번 재검토 하니깐 룰 지켜서 만들어주네요
예제에서는 StringSerializer 와 StringDeserializer 를 사용하도록 설정하고 ObjectMapper 를 통해 직렬화/역직렬화를 해주셨는데요. 혹시 JsonSerializer 와 JsonDeserializer 를 사용하지 않는 이유가 있을까요? 그리고, JsonDeserializer 를 사용하든 StringDeserializer 를 사용하든 역직렬화를 할 때 실패하게 되면 offset commit 이 되지 않고 재시도를 하는동안 해당 message 의 partition 은 blocking 된다고 이해하고 있는데 맞을까요? 이 경우에도 retry 이후, 해결 안되면 dlt topic 으로 이동하는게 맞을까요?
강사님 안녕하세요. 잘 배우고 있습니다. 강의를 보다가 든 생각인데 실제로 Secret을 현업에서 관리하게 될 때는 아래와 같은 구조로 이뤄질 것 같은데 맞나요? 신규 피쳐에 새로운 시크릿이 필요하다. 개발자가 devops 팀에 추가를 요청한다. devops 에서 마스터 노드로 접근하여 kubectl 을 통해 secret 을 생성한다. 해당 사항을 개발자가 노티 받고, 배포를 진행한다. SealedSecret이라는 걸 알게 되었는데, 이걸 이용하면 개발자가 직접 추가할 수도 있고, git에도 비대칭 암호화된 값이 남아 안전하다고 합니다. 보통 SealedSecret 방식을 적용하여 프로젝트를 운영하나요, 아니면 책임 관리 소재에서 저 과정을 거치나요?
리서치를 하다보니 실무에서는 auto.create.topics.enable=false 설정을 사용하는게 좋다는 글을 많이 보게 되었습니다. 네이밍 컨벤션이나 예상치 못한 topic 의 생성 등을 방지하기 위함으로 이해했는데요. 그럼, xxx.dlt 와 같은 topic 들도 직접 생성을 해줘야 하는지 궁금합니다. 그리고, 실제로 실무에서 해당 설정을 많이 사용하는지 또한 궁금합니다 🙂
