Forwarded message ids

[timfox]

A quick sanity check

When sending a foreign message do we need to preserve it's JMSMessageID if set?

I'm assuming not, since the spec states that on sending a message, message id is ignored and then set to a provider assigned value after the send.

This kind of implies that any "forwarded" message (whether foreign or not) can legally have it's message id overwritten with a new one.

Do you think this is right....?

[apwalker]

Looking at the spec I think that's a pretty safe assumption, although from a tracking prespective it might make it a bit harder to track messages from one provider to another.

Maybe a custom JBoss property could be used to hold the Original JMSMessageID value so a consumer could access the original value if they really needed it.

cheers

Aaron Walker

[timfox]

"apwalker" wrote:

Maybe a custom JBoss property could be used to hold the Original JMSMessageID value so a consumer could access the original value if they really needed it.

Interesting idea.

On a related note, in the javadoc for javax.jms.Message.setJMSMessageID:

Sets the message ID.

JMS providers set this field when a message is sent. This method can be used to change the value for a message that has been received.

I find this confusing.

If the provider wants to set the message id it has access to the implementation classes so soesn't need to use this method.

If it can be called by the user after receipt of a message to change the message id - why would a user want to do that?

[adrian.brock]

"timfox" wrote:

I find this confusing.

If the provider wants to set the message id it has access to the implementation classes so soesn't need to use this method.

The JMS Spec allows one provider to use the messages of another provider.

JBossMQ used to do this, i.e. At send it would wrap the message in an ObjectMessage,
at receive it would unwrap it before giving to the receiver.
To make this work as per spec, JBossMQ had to set the message id, timestamp, etc.
on both the wrapped message and the SpyObjectMessage.

I removed it, because the code was broken when it was used in a transaction.
Instead, it converts the message from the external provider object into a JBossMQ object.

[adrian.brock]

"timfox" wrote:
A quick sanity check

When sending a foreign message do we need to preserve it's JMSMessageID if set?

I'm assuming not,

That is correct, each new send is a new message and therefore a new message id.

You should however preserve the message id if it is not a direct send using the
JMS api, e.g. message bridging.

[timfox]

JBossMQ used to do this, i.e. At send it would wrap the message in an ObjectMessage,
at receive it would unwrap it before giving to the receiver.
To make this work as per spec, JBossMQ had to set the message id, timestamp, etc.
on both the wrapped message and the SpyObjectMessage.

I removed it, because the code was broken when it was used in a transaction.
Instead, it converts the message from the external provider object into a JBossMQ object.

Similarly, we currently always convert the foreign message to a JBossMessage on send so jboss messaging always deals with JBossMessage instances, so we don't use the setXXX methods.

This seems perfectly legal specwise to do this.

Moreover since javax.jms.Messages doesn't extend Serializable it's not easy to see how you would do it any other way.

Kind of baffles me why they have the setJMSMessageID() on the public API at all.

I've been googling and I've seen this question raised before.

The only possible reason I can see for this method is the application sets the message id to some innocuous vaue on receipt in order to hide it from the rest of the application for perhaps "security" reasons.

Althought this is very tenuous.

[adrian.brock]

Like I always say in the user forums.
If you find the spec confusing, speak to the spec lead ;-)

From the spec itself

Please send technical comments on this specification to: [e-mail]