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 Mon, 07 Dec 2009 13:44:18 GMT

    [ 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

View raw message