Qpid
  1. Qpid
  2. QPID-4617

getJMSReplyTo does not return null for when ReplyTo property is empty

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.21
    • Component/s: Java Client
    • Labels:
      None

      Description

      If the replyTo property is not set or explicitly set to null, on the receiver side, getJMSReplyTo should return null.

        Issue Links

          Activity

          Hide
          Rajith Attapattu added a comment -

          Added a fix at rev http://svn.apache.org/r1451727
          This is based on a patch provided by Pavel Moravec.

          Show
          Rajith Attapattu added a comment - Added a fix at rev http://svn.apache.org/r1451727 This is based on a patch provided by Pavel Moravec.
          Hide
          Robbie Gemmell added a comment -

          This seems like a good final check to make to stop the non-null ReplyTo object from causing the wrong value to be returned, but it doesn't seem to me that it fixes the real underlying issue: why does the client have a non-null ReplyTo object, i.e think there was a reply-to set when there wasn't?

          I think its worth looking into that, as it implies either an issue further down inside the transport code, that the client is actually sending the wrong information to the broker originally, or the broker is sending the wrong information back to the client. Identifying which of these it is and rectifying that might even allow for resolving this issue for older version clients when they are interacting with the newer clients/brokers, rather than confining the workaround to only consumers using the new client.

          (P.S. was there a reason not to use the original JIRA with Pavel's patch attached to it? Or to not fully update either one after the commit?)

          Show
          Robbie Gemmell added a comment - This seems like a good final check to make to stop the non-null ReplyTo object from causing the wrong value to be returned, but it doesn't seem to me that it fixes the real underlying issue: why does the client have a non-null ReplyTo object, i.e think there was a reply-to set when there wasn't? I think its worth looking into that, as it implies either an issue further down inside the transport code, that the client is actually sending the wrong information to the broker originally, or the broker is sending the wrong information back to the client. Identifying which of these it is and rectifying that might even allow for resolving this issue for older version clients when they are interacting with the newer clients/brokers, rather than confining the workaround to only consumers using the new client. (P.S. was there a reason not to use the original JIRA with Pavel's patch attached to it? Or to not fully update either one after the commit?)
          Hide
          Rajith Attapattu added a comment -

          Robbie,

          The underlying issue is that when you set the replyTo property we set the packing flag even though it's null.

          public final MessageProperties setReplyTo(ReplyTo value) {
              this.replyTo = value;
              packing_flags |= 2048;
              setDirty(true);
              return this;
          }
          

          I will be adding a null check there to ensure we don't create a ReplyTo struct with null values.

          I missed the original JIRA. I will look for it and close that as a dup.

          Regards,

          Rajith

          Show
          Rajith Attapattu added a comment - Robbie, The underlying issue is that when you set the replyTo property we set the packing flag even though it's null. public final MessageProperties setReplyTo(ReplyTo value) { this .replyTo = value; packing_flags |= 2048; setDirty( true ); return this ; } I will be adding a null check there to ensure we don't create a ReplyTo struct with null values. I missed the original JIRA. I will look for it and close that as a dup. Regards, Rajith
          Hide
          Robbie Gemmell added a comment -

          Ok great. I guess we also need to clear the flag if the replyTo was previously non-null and then gets set null.

          Show
          Robbie Gemmell added a comment - Ok great. I guess we also need to clear the flag if the replyTo was previously non-null and then gets set null.
          Hide
          Rajith Attapattu added a comment -

          Added a fix to clear the replyTo field if the destination is null.
          See http://svn.apache.org/r1453041

          Show
          Rajith Attapattu added a comment - Added a fix to clear the replyTo field if the destination is null. See http://svn.apache.org/r1453041

            People

            • Assignee:
              Rajith Attapattu
              Reporter:
              Rajith Attapattu
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development