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: [email protected]
For additional commands, e-mail: [email protected]
