On Thu, Jan 17, 2013 at 4:06 PM, 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. > > 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.
Agreed. The use cases we are discussing is for 'foreign' messages and forwarding/routing agents. The default behavior will always assign a unique message-id before sending it on the wire. > > > 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/>* --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
