On 17 January 2013 17:30, Rajith Attapattu <[email protected]> wrote:
> 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 ? > > Yep, 3272 > > 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). > Seperate as in store the provided String in a field which is separate from the UUID in the header where we would normally store the passed in message id value, and return this when getJMSMessageID is called. There would be no custom header property like you originally suggested, as based on the updated information I dont see a need to to preserve the a foreign providers message ID when sending the message across the wire with Qpid, the issue is the reverse in that the foreign providers are trying to set their new provider-specific message ID on our message object so that they can then send it themselves, and we arent letting them. If we allow that, and the same message was given to Qpid again later to send, we would generate a new Qpid specific message id and set that on the message (clearing any otehr value) and send that on the wire as always. > > 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] > >
