SimpleMessageListenerContainer을 사용하여 여러 대기열에 첨부되고 ChannelAwareMessageListener으로 구성됩니다. 메시지가 소비 된 큐를 결정할 수 있습니까? 특히 메시지가 Exchange에서 대기열로 라우팅 된 경우메시지가 사용 된 RabbitMQ 대기열의 이름 검색
MessageProperties#getReceivedRoutingKey에 큐 이름이 포함될 메시지를 큐로 직접 보내지 만 메시지가 Exchange를 통해 큐에 라우팅되는 경우이 정보에는 사용 된 라우팅 키가 들어 있습니다.
메시지가 큐로 전달 된 방법에 관계없이이 정보를 올바르게 추출 할 수있는 메커니즘을 찾고 있습니다. 또는 RabbitMQ 측면에서이 정보를 포함하는 헤더로 정보를 풍부하게하는 메커니즘.
slf4j MDC 컨텍스트에 큐 이름을 추가하려는 것과 비슷한 문제가있었습니다.
내가 찾은 유일한 해결책은 서브 클래스 SimpleMessageListenerContainer이며 큐 이름 또는 내 경우에는 기본적으로 threadlocals 인 ThreadLocal 변수를 설정하는 것입니다.
SimpleMessageListenerContainer은 어떤 큐 (컨테이너에 여러 큐를 바인딩 할 수 있는지)를 정확히 알지 못하기 때문에 컨테이너 당 하나의 큐만 허용해야합니다. 내 의견으로는 관계없이 수행해야합니다. 내 회사 자신의 코드베이스에서
우리는 (AMQP에 대한 스프링 MVC @RequestMapping 생각) 라우팅 주석을 기반으로 사용자 정의 SimpleMessageListenerContainer의 생성을하는 마법 SimpleMessageListenerContainerFactory 있습니다. 아마도 관심이 있다면 우리는 그것을 오픈 소스로 신속하게 보낼 수 있습니다.
그게 우리가 한 일이 거의 끝난 것입니다. – bstick12
메시지가 대기열로 직접 보내지면 실제로 직접 교환기로 전송됩니다. 이 직접 교환은 라우팅 키를 메시지를 전달해야하는 큐 이름으로 해석합니다. 그래서 라우팅 키는이 경우 큐 이름과 동일합니다. – Bengt
메시지에는 정보가 포함되어 있지 않습니다. 정보가 라우팅되는 곳 (그리고 나는 합리적이라고 생각합니다). 이 시나리오에서는 소비자가 메시지를받은 큐를 알 수있는 책임자라고 생각합니다. 시나리오에 대한 자세한 정보를 추가 할 수 있습니까? 대기열 이름을 알아야하는 이유는 무엇입니까? 아마도 다른 메시징 패턴이 더 잘 맞을 것입니다. – Bengt
메시지는 실제로 수신 된 교환을 포함합니다 (또는 확실하지 않은 Spring AMQP 구현에 의해 결정될 수 있습니다). 따라서 라우팅 정보가 있습니다. 나는 대기열에 관한 정보를 얻으려고하고있다. 여러 대기열에 연결된 소비자가 있고 메시지 대기열을 확인할 수 없습니다. 내 고객을 단 하나의 대기열에 연결 한 다음 대기열을 결정할 수있었습니다. 대기열에 대한 각 연결에는 consumer_tag가 주어지고 대기열을 확인할 수 있어야하지만 노출되지는 않는 것 같습니다. – bstick12