Hi,
I am using ReactorNettyTcpStompClient to connect to RabbitMQ STOMP. During frame handling, i am NACKing messages and are routed to dead letter exchange.
While examining the messages from DLX, i noticed that x-death header is missing.
The following headers are available:
x-first-death-exchange
x-first-death-queue
x-first-death-reason
x-death header contains useful information but unfortunately that is not available in STOMP headers.
Looks like a bug to me. Please let me know a way to get the x-death header while processing the messages from DLX
Thanks, Strive
Comment From: rstoyanchev
Can you provide more details? Are you connecting directly to a RabbitMQ server, and where is the header lost, e.g. where is it last seen?
It seems unlikely that this would have anything to do with ReactorNettyTcpStompClient given that other headers do make it. There is no specific handling of these headers.
Comment From: onlybytes
Thanks for your response.
I am connecting to RabbitMQ using ReactorNettyTcpStompClient. I have subscribed to a queue.
I am printing headers and the message in the @override public void handleFrame(StompHeaders headers, Object payload) method
When i receive the first message, the following headers are there:
subscription
destination
message-id
redelivered
ack
reply-to-dest
content-type
content-length
I am NACKing the message with requeue parameter set to false.
The message is dead-lettered and it is routed to the dead-lettered exchange. The following headers are seen when we print the headers of the message received from dead-lettered exchange:
subscription
destination
message-id
redelivered
ack
reply-to-dest
content-type
content-length
x-first-death-exchange
x-first-death-queue
x-first-death-reason
I logged into RabbitMQ management page and verified the message. I can see x-death header there along with other headers. But it is not available when we are processing the message in handleFrame method.
Some additional details:
The x-death header is of type list. Its a list of maps.
Similar usecase works fine in AMQP. List<Map<String, ?>> xDeathHeader = in.getMessageProperties().getXDeathHeader();
Looks like the issue is with StompHeaders
Comment From: rstoyanchev
StompHeaders is a very simple, holder of headers, like a Map. What could possibly be an issue there? Likewise seeing the header in the RabbitMQ management page may be a false lead. The question is how the RabbitMQ STOMP plugin adapts it to a STOMP MESSAGE frame and what actually comes on the wire.
The logic for parsing the incoming stream is in StompDecoder. You could debug there and see what headers are actually received. I don't think a header can get lost. It would more likely cause a parse error if there was any problem. This is why I doubt it is anything on the client side.
Short of that you can try using a different STOMP client to isolate the issue but I think debugging it in StompDecoder is probably the easiest way to see what actually comes in. If you have further doubts you can ask https://github.com/rabbitmq/rabbitmq-stomp/issues but I would first do more narrowing down.
Comment From: onlybytes
@rstoyanchev
Thanks a lot. I tried it in different STOMP client (apache camel), the behavior is the same.
I debugged the StompDecoder. The readHeaders method is processing the message properly. It is not dropping any headers.
The issue could be on RabbitMQ STOMP plugin. I will raise the issue in RabbitMQ project.
I am closing this issue.
Comment From: rstoyanchev
Ok, feel free to comment further when you find out for others.
Comment From: onlybytes
Adding the response from RabbitMQ team for others who hit similar issue. See the links below
https://github.com/rabbitmq/rabbitmq-stomp/issues/143 https://groups.google.com/forum/#!topic/rabbitmq-users/4z6bDyS9iWU
Until retry-count header is included, one has to design their own caching solution to keep retry count of messages based on message ids