After some further investigation it appears I have got the
requirements wrong. Sorry about that.
The second issue I mentioned (provider overriding the message -id)
*may* no longer be a concern here.
(My original email was based on a conversation I had when trying to
find the use cases behind the request).
After looking at some stack traces it appears that these bridges are
trying to send a message they received from Qpid through their system.
(Please see the stack traces below).
Since there is no requirement in the JMS spec that says the message id
needs to be a UUID, we should probably allow a way to relax this
constraint unless the STRICT_AMQP is set.
I believe that should be good enough to get Qpid working properly with
these message bridges.
javax.jms.JMSException: MessageId
'ID:dhcp209-12.gsslab.pnq.redhat.com-45266-1305237148981-3:0:3:1:1' is
not of the correct format, it must be ID: followed by a UUID
at
org.apache.qpid.client.message.AMQMessageDelegate_0_10.setJMSMessageID(AMQMessageDelegate_0_10.java:165)
at
org.apache.qpid.client.message.AbstractJMSMessage.setJMSMessageID(AbstractJMSMessage.java:92)
at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1727)
at
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:231)
javax.jms.JMSException: MessageId
'ID:414d5120495045344445563420202020aa4085502c747620' is not of the correct
format, it must be ID: followed by a UUID
at
org.apache.qpid.client.message.AMQMessageDelegate_0_10.setJMSMessageID(AMQMe
ssageDelegate_0_10.java:194)
at
org.apache.qpid.client.message.AbstractJMSMessage.setJMSMessageID(AbstractJM
SMessage.java:63)
at
com.ibm.mq.jms.MQJMSMessage.setHeaderFromMQMD(MQJMSMessage.java:932)
at
com.ibm.mq.jms.MQMessageProducer.sendInternal(MQMessageProducer.java:1813)
at
com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:1139)
On Thu, Jan 17, 2013 at 6:13 AM, Robbie Gemmell
<robbie.gemm...@gmail.com> wrote:
> I would echo Keiths point, and also have some other items to consider.
>
> I'm not sure I think the spec really is all that loose on this subject, and
> the bit you quoted was just a natural phrasing and not really intended to
> implying you can feel free not to overwrite it. For example, I can quote a
> bit that is fairly specific on the behaviour:
>
> 3.4.3 JMSMessageID : "When a message is sent, JMSMessageID is ignored. When
> the send method returns, the field contains a provider-assigned value."
>
> Do we have examples of other providers supporting preservation of the
> message ID? I didnt look hard but googling on the subject only seemed to
> return questions on the behaviour, not examples where preservation was
> supported (though I guess it isnt necessarily a prominent feature people
> would call out). The closest I noticed was some talk of possibly supporting
> it in future where the both sides of a bridge were the same provider.
>
> If the intention is to preserve an ID across a bridge, is there a reason
> JMSCorrelationID cant be used, given it is specifically supports
> application specified IDs whereas JMSMessageID specifically does not?
>
> Allowing the client not to overwrite the message ID also seems to open us
> to the possability of duplicate message IDs on outbound messages. There is
> nothing stopping someone sending a given message object multiple times, and
> unlike the intended behaviour of JMSMessageID it would seem that each time
> it was sent it would get the same ID (unless we did something horrible to
> prevent that, such as caching IDs).
>
> With regards to the special header property, what restriction would there
> be around that? Presumably we would have to prevent application usage of
> that property, which might imply it should be a vendor-specific property
> instead...although the spec says those shouldnt be used for JMS to JMS
> messaging, so ho hum.
>
> Robbie
>
>
> On 17 January 2013 09:31, Keith W <keith.w...@gmail.com> wrote:
>
>> Hi Rajith,
>>
>> I'm interested to know more background. When exactly is the ability
>> to preserve JMSMessageIDs in this way useful? Does this change give
>> us compatibility with particular (bridging) product(s)? If so, which
>> ones?
>>
>> Thanks, Keith.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
