On Thu, Jan 17, 2013 at 11:52 AM, Robbie Gemmell <[email protected]> wrote: > 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.
Is there a typo in the JIRA id ? > 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 This seems to be the case. > 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. This is fine with me as well. > 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. Sorry could you explain a bit more as to how you would store them separately ? Maybe I misunderstood your intention here, but it seems something similar to what I suggested in my original email (of course based on wrong info I received). Rajith > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
