qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-2242) JMS_QPID_DESTTYPE is not set making getJMSDestination unusable.
Date Tue, 08 Dec 2009 16:41:18 GMT

    [ 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:dev-subscribe@qpid.apache.org

View raw message