fmtn/a

Setting replyto parameter does not set JMSReplyTo in delivered message

ErikaBi opened this issue · 3 comments

version :
Latest

JVM version (java -version):
openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)

OS version (uname -a if on a Unix-like system):
Linux segotl2618 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019 x86_64 x86_64 x86_64 GNU/Linux

Description of the problem including expected versus actual behavior:
I am sending a batch of messages.
In documentation, -r should set the JMSMessage replyTo attribute in the outgoing messages. But it doesn't. It is always null when entering the queue. The class MessageDump that is used for copying one object to a JMSMessage does not have a member for replyTo.
(Another thing is that using --reply-to instead of -r will not work at all)

Steps to reproduce:

  1. Create a message file "m.txt" containing one or more messages.
  2. send in the file with
    -p "PLACEHOLDER" -S "msg.body=msg.body.replace('PLACEHOLDER',entry);" -W ./m.txt
    --correlation-id anyID42 -r DEVICE.NOTIFY.RESPONSE
  3. Check that the AMQ got the message anyID42 and verify that the replyTo is null instead of DEVICE.NOTIFY.RESPONSE.

Seems like replyTo (and perhaps other JMS props) are not working on batch messages.

The function transformMessage is used here.
This function creates a new message without the ReplyTo that was set on the original outMsg.
Many properties are copied by the Writer/Reader combination, but ReplyTo is not one of them.

Here is a tested fix.
(sorry, too lazy for a PR)

diff --git a/src/main/java/co/nordlander/a/MessageDump.java b/src/main/java/co/nordlander/a/MessageDump.java
index c049786..d6acd07 100644
--- a/src/main/java/co/nordlander/a/MessageDump.java
+++ b/src/main/java/co/nordlander/a/MessageDump.java
@@ -3,6 +3,7 @@ package co.nordlander.a;
 import java.io.UnsupportedEncodingException;
 import java.util.HashMap;
 import java.util.Map;
+import javax.jms.Destination;

 import org.apache.commons.codec.binary.Base64;

@@ -16,6 +17,7 @@ public class MessageDump {
        public Boolean JMSRedelivered;
        public Long JMSTimestamp;
        public Integer JMSPriority;
+       public Destination JMSReplyTo;

        public Map<String,String> stringProperties = new HashMap<String,String>();
        public Map<String,Integer> intProperties = new HashMap<String,Integer>();
diff --git a/src/main/java/co/nordlander/a/MessageDumpReader.java b/src/main/java/co/nordlander/a/MessageDumpReader.java
index dbd38fb..4eca3c5 100644
--- a/src/main/java/co/nordlander/a/MessageDumpReader.java
+++ b/src/main/java/co/nordlander/a/MessageDumpReader.java
@@ -163,6 +163,9 @@ public class MessageDumpReader {
                if (dump.JMSPriority != null) {
                        msg.setJMSPriority(dump.JMSPriority);
                }
+               if (dump.JMSReplyTo != null) {
+                       msg.setJMSReplyTo(dump.JMSReplyTo);
+               }

                return msg;
        }
diff --git a/src/main/java/co/nordlander/a/MessageDumpWriter.java b/src/main/java/co/nordlander/a/MessageDumpWriter.java
index ac4ed62..59197a5 100644
--- a/src/main/java/co/nordlander/a/MessageDumpWriter.java
+++ b/src/main/java/co/nordlander/a/MessageDumpWriter.java
@@ -74,6 +74,7 @@ public class MessageDumpWriter {
                dump.JMSRedelivered = msg.getJMSRedelivered();
                dump.JMSTimestamp =  msg.getJMSTimestamp();
                dump.JMSPriority = msg.getJMSPriority();
+               dump.JMSReplyTo = msg.getJMSReplyTo();

                @SuppressWarnings("rawtypes")
                Enumeration propertyNames = msg.getPropertyNames();

I updated the putBatchMessage + a test case that should fix the issue above, since it uses -W (Batch mode) - not write/restore dump.

I don't know about DumpWriter. Perhaps in dump reader instead? Got to give some rework to that feature