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?
>
>
> 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/>*
>
