On 17 January 2013 21:51, Robbie Gemmell <[email protected]> wrote:
> > On 17 January 2013 21:06, Hiram Chirino <[email protected]> wrote: > >> FYI there is a good reason to NOT preserve the message id. It's fairly >> common for clients to do things like: >> >> msg = session.createTextMessage(); >> msg.setText("Hello"); >> sender.send(msg); >> msg.setText("World"); >> sender.send(msg); >> >> You don't want the 2nd msg sent /w the message id used in the 1st. >> > > Agreed, this was the exact type of use case I was concerned with in an > earlier message. > > >> The only time your really want to do the id preservation is when a >> 'foreign' jms message is being sent. At least this is what ActiveMQ does. >> If a Qpid JMS message is sent on an ActiveMQ sender, the message id will >> be preserved. >> >> > How do you handle the situation above where the message was foreign, just > let it duplicate the ID for the foreign message, given it it would be ever > so slightly slightly less usual to send the foreign message twice? > > (...err...obviously its not exactly the same situation, since you wouldnt be able to call setText on the message given it had been recieved....but the send twice bit still applies I guess :P ) > >> >> On Thu, Jan 17, 2013 at 1:07 PM, Rajith Attapattu <[email protected] >> >wrote: >> >> > On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell >> > <[email protected]> wrote: >> > >> >> > > Yep, 3272 >> > >> > Gotcha. >> > >> > > 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. >> > >> > Thanks for clarifying. It makes sense. >> > >> > >> > On a separate note : All though (based on the updated info) we don't >> > need to consider preserving the original message-id for now, this may >> > become important in the future. >> > Consider a message being routed through a federated network, where it >> > takes several hops before reaching the endpoint. >> > One of those hops could very well be implemented using a JMS client. >> > In this case the Qpid client will overwrite the message-id with a new >> > one. >> > The hops are merely forwarding/routing agents and in that sense >> > tampering with the original message properties may not be a good idea. >> > In such a situation it would be useful to have a configurable way to >> > ensure the send-impl doesn't override the message id. >> > I think we will be seeing such use cases in the near future. >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> >> -- >> >> ** >> >> *Hiram Chirino* >> >> *Engineering | Red Hat, Inc.* >> >> *[email protected] <[email protected]> | fusesource.com | redhat.com* >> >> *skype: hiramchirino | twitter: @hiramchirino< >> http://twitter.com/hiramchirino> >> * >> >> *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>* >> > >
