[
https://issues.apache.org/jira/browse/QPID-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787568#action_12787568
]
Martin Ritchie commented on QPID-2242:
--------------------------------------
I have restored the setting of JMS_QPID_DESTTYPE on the 0-8/9 code path during
message send.
When the message is received on the 0-8/9 code path it will consult the
JMS_QPID_DESTTYPE first if that fails then it will fallback to use the lookup
tables used by the 0-10 code path.
Testing on trunk has been performed by using the new multi-protocol broker and
so is only run with the 'java.0.10' profile.
The changes have all be merged to the 0.5.x-dev branch though the
JMS_QPID_DESTTYPE test had to be modified to only validate that we can forward
current messages ok. The lack of multi-protocol support means that we are
unable to test this functionality.
> 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:[email protected]
