[jira] Commented: (QPID-2242) JMS_QPID_DESTTYPE is not set making getJMSDestination unusable.

["Martin Ritchie (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786914#action_12786914 ] 

Martin Ritchie commented on QPID-2242:
--------------------------------------

0-10 code has an ExchangeQuery method that allows the type lookup of the destination to be performed. However, whilst it is currently doing this it is not calling setJMSDestination when it creates the message so null is always returned.

0-9/8 code set the JMSDestination to be the same as the consumers destination during postDelivery. This means that using receive the value will be set and appear correct. If queried during an onMessage receive then the exchange value will be 'unknown'. However, the value is wrong, the spec says that " When a message is received, its JMSDestination value must be equivalent the the value assigned when it was sent." 

So by testing that a message moved from a topic to a queue the JMSDestination should reflect its original destination. Testing under 0-10 proves that this works correctly (required some work on QPID-2244)

Problem with the 0-8/9 code path is that there is no ExchangeQuery option. However, the same code can be used as it is preloaded with the default exchange names and this will be sufficient for the majority of use cases.


> JMS_QPID_DESTTYPE is not set making getJMSDestination unusable.
> ---------------------------------------------------------------
>
>                 Key: QPID-2242
>                 URL: https://issues.apache.org/jira/browse/QPID-2242
>             Project: Qpid
>          Issue Type: Bug
>            Reporter: Martin Ritchie
>
> The problem is that Qpid M2.1 (and earlier) sets the JMS_QPID_DESTTYPE header property before sending. 
> If you try and do that on a message that doesn't have the property set then it will attempt to write it into the _encodedForm ByteBuffer if there is one.
> In the scenario where you are receiving messages and then re-sending them not creating new ones. The header has already been read so the buffer limit and position are the same which means any write to the buffer will throw a BufferOverflowException. In short the headers are Read Only.
> I have tested with M2.1 After the merge to trunk for M3 the setting of this property was removed. Which does mean that the JMS Destination is marked as 'unknown' rather than 'direct' which means if you attempted to do message.getJMSDestination() to send the message back in to the queue for reprocessing it would fail.
> Further investigations:
> Understand why this setting was dropped after the Merge from M2.x to trunk. This property is used to control the type of Destination that message.getJMSDestination() returns.
> Need to check M1 to see if it sets the value on sent Messages.
> Also need to check how the 0-10 code path defines the JMSDestination() as it too appears to never to have a value set and so will be an 'unknown' destination.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org