You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2013/01/16 22:50:13 UTC
Preserving the original JMS Message ID when a message is sent across
multiple vendors using a bridge.
There are two issues preventing the above when using the Qpid JMS client.
1. Qpid JMS client currently enforces the message ID to be a UUID as
it's needed by the underlying 0-10 implementation.
Therefore when a message bridge attempts to copy a message from
one vendor to the Qpid message, it is unable to preserve the original
message ID.
2. Even if we get past the first hurdle, the other issue is that we
ignore whatever is set and instead set the message ID in our send
impl.
Now based on the JMS spec, a JMS provider is within it's right to
ignore any previously set value and set it's own ID.
"When a message is sent, JMSMessageID can be ignored. When the
send or publish method returns, it contains a provider-assigned value.
"
However in order to play nice, we could allow the message ID to be
set, as the spec does not seem to explicitly prohibit it.
Therefore I like to propose the following. I'm of course open to other
solutions as well.
1. We could allow users to configure the client not to override a
message ID, if it's already set. (The default will always override
it).
2. If the supplied message ID is not a UUID as required by the AMQP spec,
2.1 we will set the message ID to null (which we currently allow
and is an acceptable value as per the 0-10 spec).
2.2 carry the supplied id as an application property (ex,
qpid.jms.message_id)
2.3 on the receiving side, we look at this property if the
message-id is set to null in the AMQP message properties and use that
as the JMS message id.
The above solution provides a reasonable compromise without breaking
the AMQP spec.
What do you folks think?
If there are no objects and alternative solutions, I'm planning to
implement this by thursday.
Regards,
Rajith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jan 17, 2013 at 4:06 PM, Hiram Chirino <hi...@hiramchirino.com> 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 <ra...@gmail.com>wrote:
>
>> On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell
>> <ro...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
>
>
> --
>
> **
>
> *Hiram Chirino*
>
> *Engineering | Red Hat, Inc.*
>
> *hchirino@redhat.com <hc...@redhat.com> | 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jan 17, 2013 at 5:27 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> I was actually asking Hiram what ActiveMQ does...
Gotcha. It would be interesting to know the details.
Rajith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2013 22:19, Rajith Attapattu <ra...@gmail.com> wrote:
> On Thu, Jan 17, 2013 at 5:00 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
> >
> > ( ( ...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 ) )
>
> The default behavior we provide guards against all these things.
> If a user make a conscious decision to alter the default behavior (i.e
> to preserve the original ID) then they should also consider the
> implications of such an approach.
> It would be impossible to make software completely idiot proof.
>
> Ideally the documentation that describes this config option should
> have a warning about the perils of reusing the message as it can send
> a number of messages with the same message id.
>
> Rajith
>
>
>
I was actually asking Hiram what ActiveMQ does...
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jan 17, 2013 at 5:00 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
>
> ( ( ...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 ) )
The default behavior we provide guards against all these things.
If a user make a conscious decision to alter the default behavior (i.e
to preserve the original ID) then they should also consider the
implications of such an approach.
It would be impossible to make software completely idiot proof.
Ideally the documentation that describes this config option should
have a warning about the perils of reusing the message as it can send
a number of messages with the same message id.
Rajith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2013 21:54, Robbie Gemmell <ro...@gmail.com> wrote:
>
>
>
> On 17 January 2013 21:51, Robbie Gemmell <ro...@gmail.com> wrote:
>
>>
>> On 17 January 2013 21:06, Hiram Chirino <hi...@hiramchirino.com> 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 <rajith77@gmail.com
>>> >wrote:
>>>
>>> > On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell
>>> > <ro...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>>> > For additional commands, e-mail: dev-help@qpid.apache.org
>>> >
>>> >
>>>
>>>
>>> --
>>>
>>> **
>>>
>>> *Hiram Chirino*
>>>
>>> *Engineering | Red Hat, Inc.*
>>>
>>> *hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com
>>> *
>>>
>>> *skype: hiramchirino | twitter: @hiramchirino<
>>> http://twitter.com/hiramchirino>
>>> *
>>>
>>> *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
>>>
>>
>>
>
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2013 21:51, Robbie Gemmell <ro...@gmail.com> wrote:
>
> On 17 January 2013 21:06, Hiram Chirino <hi...@hiramchirino.com> 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 <rajith77@gmail.com
>> >wrote:
>>
>> > On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell
>> > <ro...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: dev-help@qpid.apache.org
>> >
>> >
>>
>>
>> --
>>
>> **
>>
>> *Hiram Chirino*
>>
>> *Engineering | Red Hat, Inc.*
>>
>> *hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com*
>>
>> *skype: hiramchirino | twitter: @hiramchirino<
>> http://twitter.com/hiramchirino>
>> *
>>
>> *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
>>
>
>
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 18 January 2013 14:33, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On Thu, Jan 17, 2013 at 4:51 PM, Robbie Gemmell <robbie.gemmell@gmail.com
> >wrote:
>
> > > 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?
>
>
> Correct. Then again, ActiveMQ also has dup detection logic, a subsequent
> send /w the same message id would get dropped.
>
>
Ah I see. The Qpid brokers dont currently de-dupe messages, but we could
potentially add some client-side ability when dealing with messages from
foreign providers that e.g allowed for a choice between throwing an
exception to let them know they cant send again or allowing the same id to
be used if you attempted multiple sends on the foreign message with the
'preserve id' option enabled (since they aren't strictly duplicate messages
but rather different messages with non-unique ids...ick).
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Thu, Jan 17, 2013 at 4:51 PM, Robbie Gemmell <ro...@gmail.com>wrote:
> > 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?
Correct. Then again, ActiveMQ also has dup detection logic, a subsequent
send /w the same message id would get dropped.
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2013 21:06, Hiram Chirino <hi...@hiramchirino.com> 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 <rajith77@gmail.com
> >wrote:
>
> > On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell
> > <ro...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
>
> --
>
> **
>
> *Hiram Chirino*
>
> *Engineering | Red Hat, Inc.*
>
> *hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com*
>
> *skype: hiramchirino | twitter: @hiramchirino<
> http://twitter.com/hiramchirino>
> *
>
> *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
>
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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.
On Thu, Jan 17, 2013 at 1:07 PM, Rajith Attapattu <ra...@gmail.com>wrote:
> On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell
> <ro...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
--
**
*Hiram Chirino*
*Engineering | Red Hat, Inc.*
*hchirino@redhat.com <hc...@redhat.com> | fusesource.com | redhat.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jan 17, 2013 at 12:43 PM, Robbie Gemmell
<ro...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
On 17 January 2013 17:30, Rajith Attapattu <ra...@gmail.com> wrote:
> On Thu, Jan 17, 2013 at 11:52 AM, Robbie Gemmell
> <ro...@gmail.com> 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 <ra...@gmail.com> 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
> >> <ro...@gmail.com> 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jan 17, 2013 at 11:52 AM, Robbie Gemmell
<ro...@gmail.com> 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 ?
> 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).
Rajith
> Robbie
>
>
> On 17 January 2013 16:19, Rajith Attapattu <ra...@gmail.com> 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
>> <ro...@gmail.com> 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: dev-help@qpid.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
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.
>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
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. 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.
Robbie
On 17 January 2013 16:19, Rajith Attapattu <ra...@gmail.com> 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
> <ro...@gmail.com> 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Rajith Attapattu <ra...@gmail.com>.
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
<ro...@gmail.com> 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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ke...@gmail.com> 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: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Preserving the original JMS Message ID when a message is sent
across multiple vendors using a bridge.
Posted by Keith W <ke...@gmail.com>.
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org