On 17 January 2013 21:54, Robbie Gemmell <[email protected]> wrote:
> > > > 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 ) > > ( ( ...and in continuation of this one-thought-per-email demonstration, it further occurs to me that you can reset 'read only' messages and then use them again so I guess thats going back to the original question hehe ) ) > >>> >>> 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/>* >>> >> >> >
