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

["Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>]

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

Rajith Attapattu commented on QPID-2242:
----------------------------------------

There were several bugs in the 0-10 code path.
The method "updateExchangeType' is doing a lookup on a map keyed by "exchange-name" using the "exchange-type".
In the same method the queried exchange-type is not saved, therefore unable to make use of it in "generateDestination" method
The code never worked for anything other than the standard exchange types. The only reason why it worked for the standard exchange types was due to the map being pre-populated.

> 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
>          Components: Java Client, Java Common
>    Affects Versions: M3, M4, 0.5
>            Reporter: Martin Ritchie
>            Assignee: Martin Ritchie
>             Fix For: 0.6
>
>
> 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