It would be good to add the additional detail to the JIRA (QPID-3273), its useful in considering the actual intent of the setJMSMessageID call.
>From reading of the stacktraces, I'd say it looks like the foreign senders are setting their new message ID on our message object, and then probably subsequently reading the necessary elements (including message ID) back from the message when actually sending over the wire in the relevant format, whereas we appear to copy the foreign message and then manipulate our own copy (which presumably means we dont actually set our message ID on foreign messages as we probably should). We enforce that this should be a UUID because our venfdor-specific message IDs are, and so it throws an exception as theirs are not. Since the javadoc says that setJMSMessageID() can be used to change the value for read messages, and send() says that value is then ignored when sending, this seems to be allowable use and we should look to support it. It would also be fine from the perspective that we wouldnt ever be trying to send a non-uuid across the wire within Qpid, because we would replace their message ID with our own if the message object was ever provided to Qpid again to send. Having a quick browse, our message sending code actually uses an implementation specific setJMSMessageID method which takes a UUID, further reason we *really* dont need to be restricting the behaviour on the string variant, just supporting all strings I think I would approach the problem by simply storing values set as a String seperately from those values set as a UUID (if the String isnt a UUID, that is) and return the String version in preference if the message had just been recieved and both existed, since the only way it would be used is if someone who received a message had set the ID with the String method, which is allowable. Robbie On 17 January 2013 16:19, Rajith Attapattu <[email protected]> wrote: > 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 > <[email protected]> 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 <[email protected]> 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
