안녕하십니까 코드빌런님.이번 추석 연휴동안 레빗 엠큐 강의 잘 들었습니다. 다름이 아니라 강의에서 알려주신 여러 내용을 바탕으로 기존에 구현하였던 redis pub/sub 기반의 알림 기능에 레빗 엠큐를 적용해보고 있습니다. 그리고 구현 중 두가지 질문이 있어 질문을 작성하게 되었습니다. 1. 동적 큐 이름 설정 방식우선 알림을 전송하는 과정에 대해 말씀드리면 다음과 같습니다.알림 객체 저장성공 시 알림 발송sse 연결들을 ConcurrentMap으로 관리하여 대상 userId의 sse연결을 찾아 해당 연결로 알림 객체 전송 현재 메시지 큐 구조는 다음과 같습니다. 알림 저장 메시지 생성 (direct exchange, saveNotificationQueue) -> 메시지 저장 성공 시 알림 전달 메시지 생성 (fanout exchange, publishNotificationQueue), 메시지 저장 실패 시 데드레터 큐로 전달 현재 서비스는 3개의 인스턴스로 동작하고 있습니다. 이때 알림 저장 큐는 1개라서 복수 저장될 일이 없지만, 그 후에 진행되는 알림 전달의 경우 단일 큐로 작동하면 대상 sse 연결이 없는 인스턴스에서 해당 메시지를 소비하게 되면 전송이 실패합니다. 그래서 각 인스턴스마다 큐를 만들어주고 fanout exchange에 모두 바인딩하여 사용하는 방식으로 만들어야 할 것 같다고 생각하였습니다. 그래서 찾아보니 SpEL 기반 동적 큐 이름 지정 방식이 있다고 하여 해당 방식으로 구현해보았습니다.// RabbitMQConfig.java // 알림 발송 큐 @Bean public String dynamicPublishNotificationQueueName() { String randomString = UUID.randomUUID().toString(); return PUBLISH_NOTIFICATION_QUEUE + " : " + randomString; } @Bean public Queue publishNotificationQueue() { return new Queue(dynamicPublishNotificationQueueName(), false); } @Bean public FanoutExchange publishNotificationExchange() { return new FanoutExchange(PUBLISH_NOTIFICATION_EXCHANGE); } @Bean public Binding publishNotificationBinding() { return BindingBuilder.bind(publishNotificationQueue()).to(publishNotificationExchange()); } // NotificationSubscriber.java @RabbitListener(queues = "#{@dynamicPublishNotificationQueueName}") public void consumePublishNotificationMessage(Notification notification) { notificationService.publishNotification(notification); }해당 방식으로 정상 작동은 확인하였는데, 혹시 해당 방식 외에 더 나은 방식이 있는지 궁금합니다.2. SimpleRabbitListenerContainerFactory의 재정의에 따른 Retry 설정 미적용강의 18강에서 application.yml에 retry 관련 프로퍼티를 설정하는 것만으로 자동으로 retry가 적용된다고 하여 해당 방식을 프로젝트에 적용해보았습니다. spring.rabbitmq.listener.simple.retry.enabled=true spring.rabbitmq.listener.simple.retry.initial-interval=1000 spring.rabbitmq.listener.simple.retry.max-attempts=3 spring.rabbitmq.listener.simple.retry.max-interval=1000 spring.rabbitmq.listener.simple.default-requeue-rejected=false하지만 어떤 이유인지는 몰라도 retry가 작동하지 않았습니다. 실제로 실행되는 코드에 로그를 찍어봐도 한번만 시도하고 설정한 예외가 발생 후 바로 DLQ로 이동하였습니다. 그래서 원인을 찾던 도중https://inf.run/bsxxr에서@RabbitListener를 사용하면 내부적으로 SimpleMessageListenerContainer가자동으로 생성되기 때문에 retry 설정을 읽어서 exception 이 발생할 경우 RetryTemplate을 사용해서 자동으로 설정된 속성에 해당하는 작업을 수행하게 됩니다.라고 코드빌런님이 말씀하신 것을 보았습니다.확인해보니 메시지큐에서 객체 자동 역직렬화를 위해@Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setMessageConverter(messageConverter()); return factory; }이렇게 SimpleRabbitListenerContainerFactory를 정의하여 빈으로 등록해놓았는데, SimpleRabbitListenerContainerFactory를 살펴보니public class SimpleRabbitListenerContainerFactory extends AbstractRabbitListenerContainerFactory<SimpleMessageListenerContainer> { ...말씀하신 SimpleMessageListenerContainer를 타입파라미터로 받아 상속받고 있는 형태였습니다. 이에 말씀하신 SimpleMessageListenerContainer가 자동으로 생성되어 retry 설정이 적용안되는것인가? 라고 예상하여 application.properties에 정의하는 대신 @Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setMessageConverter(messageConverter()); factory.setDefaultRequeueRejected(false); factory.setAdviceChain(RetryInterceptorBuilder.stateless() .maxAttempts(3) .backOffOptions(1000, 2.0, 10000) .build()); return factory; }이렇게 직접 retry 설정을 넣어주니 그제야 재시도가 정상적으로 작동하였습니다. 해당 원인이 제가 생각한 직접 팩토리를 Bean으로 등록하면 application.properties의 retry 설정이 무시되는 것이 맞는지 궁금합니다. 코드는 아래 url에서 보실 수 있습니다.https://github.com/Dockerel/4th-SC-TEAM1-BE/pull/15/files 강의 정말 잘 들었습니다! 이렇게 프로젝트에 바로 적용해볼 수 있어서 기분이 좋네요.나중에 코드빌런님의 다른 기술 스택 강의도 들어보고 싶습니다.감사합니다.

비전공자이고 백엔드로 하고 싶은데,AI가 발전한 현재 시점에서 어떻게 공부를 해야 할지 조언을 구하고 싶습니다.

리프레시 토큰은 알아서 구현해야 하면 되는건가요?? 따로 없는데..

아직 코틀린에 익숙치 않은데 어떤 경우 Data class를 선언하고 어떤 경우 일반 class를 선언하는지 감이 안잡히네요.추가로 object나 compainon object는 어떤 경우 사용하게 되나요?

강의 잘듣고 있습니다. 혹시 다음 강의 계획은 없으신가요?

강의에서 STOMP 동작 간 /app, /topic 요청을 동시에 보낸다고 하셨는데 그럼 app 경로 발행된 메세지는 broker를 통해서 topic 경로로 전달이 되고 맨 처음에 동시에 보낸 topic 요청도 broker를 통해서 전달이 되어서 broker에서 구독하고 있는 사용자들에게 메세지를 보내준다고 이해하면 되는 것일까요? /topic으로 2번 가는 것 처럼 느껴져서 약간의 혼동이 있었습니다!

JwtAuthFilter에서 토큰이 없을 때 예외를 던지지 않고 그냥 chain.doFilter()를 호출하는 이유는?

자바 17로 되어 있던데 자바 21로 소스 작성해도 되나요?

안녕하세요, 강의에서는 메시지 브로커용으로 redis를 사용하셨는데, redis 외에도 rabbitmq나 카프카 같은 것들도 사용되는 것으로 알고있습니다. 그 중에서 특별히 redis를 사용한 이유가 있는지 궁금합니다.그리고 무중단 배포 시 스프링 내장 브로커를 사용하면 서버 재실행 시 구독 정보가 초기화되기에 메시지 브로커를 도입하려고 하는데 이때는 셋 중에 어떤 것을 사용하면 좋을지 궁금합니다.

WebSocket 연결이 처음 http요청으로 시작하기 때문에 필터 체인이 요청을 가로챈다.따라서 /connect를 permitAll()로 풀어줘야 400에러가 안난다.  로 이해했는데 맞을까요?

강의자료가 PDF로 변환하다보니, 문자 길이 때문인지 끊어지는 경우가 있는거 같은데 혹시 Notion 페이지로 제공해주실 수 잇나요? 

로그인을 했을 때 소속된 채팅방에 안 읽은 메시지가 있다면, 알림(보통 종모양)에 +안읽은메시지숫자를 구현 하려고할 땐 sse 통신을 이용하는게 좋을까요?  

stomp 웹소캣을 사용할때도 ChatWebSocketHandler를 구현해야 할까요??아니면 raw websocket만 구현하면 되는 건가요??

raw level 말고 stomp로 개발하고 싶으면 섹션7 부분만 조금 다른게 코딩하면 될까요??

우선 최초 웹 소켓 연결에 토큰 검증을 진행하고, 연결에 성공하면 특정 토픽에 바로 구독하는 걸로 알 고 있습니다.이 두 작업이 거의 동시에 이루어진다고 보는데, 구독 검증은 왜 필요한가요 선생님?

왜 도커 Redis cli 터미널 내에서 강사님이 말씀해주신 거처럼 해도 메시지가 안 오고 PUBSUB CHANNELS Empty List라고 뜰까요 근데 강사님처럼 8080 8081 서버간에 통신은 돼서 문제가 무엇인지 모르겠습니다.

의도적으로 토큰을 누락하면 403 포비든이 발생하는데, 이는 말씀하신데로 filterConfig에서 에러를 잡는다고 하면,해당 에러 코드와 내용을 커스텀 하려면 어떻게 처리하나요? 일단 컨트롤러까지 제어가 안오고 바로 에러가 반환되는듯하네요

강의마다 모든 수업자료를 다 다운받아야하나요?;;

StompCommand.SEND 도 있길래 궁금해서 질문 남깁니다! 메시지 전송 시 subscribe할 때와 같은 검증을 할 필요는 없을까요?"채팅방에 참여자여야 메시지를 보낼 수 있다" 라는 검증이 자연스러운 흐름이 될 수 있을 것 같다고 생각했습니다.

안녕하세요.JWT를 생성하는 코드(JwtTokenProvider.java의 createToken)에서는 Claims 객체를 먼저 생성하고 claims.setSubject()로 설정한 후, 이 claims를 builder에 전달하는 방식을 사용하고 계신데요.Builder에도 setSubject() 메서드가 있는데, Claims 객체에서 먼저 설정하신 이유가 궁금합니다.혹시 custom claim인 role을 함께 추가하기 위해서 Claims 객체를 먼저 생성하여 사용하신 건가요? 아니면 다른 이유가 있으신지 궁금합니다.