[hono-dev] Why we shouldn't correlate messages based on message ID

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

Guys,

we have been exchanging arguments pro and con the usage of the message
ID to correlate requests and responses. In a green field world we would
simply copy the message-id of inbound messages in Hono to the
correlation-id of the response and be happy.

However, since we do not live in dream land there are existing systems
and technologies already in use that I think we should at least try to
be interoperable with.

One of these technologies is JMS and the Apache Qpid project actually
provides a JMS provider based on proton-j for interacting with AMQP 1.0
based peers using the JMS API.

It seems reasonable to me to assume that Qpid JMS will be used by
people who are already experienced in using JMS to interact with
message brokers and would therefore like to also use JMS to take
advantage of Hono's functionality.

One of the main discussion points so far was whether in Hono's
Registration API we should use an incoming AMQP 1.0 message's message-
id property as the value for the response's correlation-id property or
whether we should better use the request's correlation-id as well. 

There has been some concern that it is not possible for a JMS client to
explicitly set and/or retrieve the message ID on a request sent to
Hono. The JMS spec defines that a client must be able to retrieve the
message ID from a message it has sent via a MessageProducer AFTER the
message has been sent. While this seems to enable the usage of the
message ID pattern for correlating a response with a request, I do not
think that it the JMS client's behavior is sufficiently specified to
make this work in reality.

Here's an excerpt from javax.jms.Message.setJMSMessageId(String)
JavaDoc:
"This method is for use by JMS providers only to set this field when a
message is sent. This message cannot be used by clients to configure
the message ID."

This means that the ID to correlate a received response upon CANNOT be
known until the message has been sent. When implementing a
MessageListener that needs to correlate this ID with the received
message's JMSCorrelationID property, a potential race condition occurs.

This problem does not exist when using the correlation ID pattern
because a client can explicitly generate and set the JMSCorrelationID
property on the request BEFORE it is sent and can thus make sure that a
listener knows about the ID to correlate upon upfront.

Dejan has made a comment on IRC that we "need to make sure we work well
with the routers, brokers and other messaging component". Is there any
particular property of the Dispatch Router or any of Red Hat's message
brokers that would prevent us from using the correlation ID pattern?

Are there any more arguments that need to be heard apart from personal
preference and/or hear say favoring one or the other?

If not, I would like to come to a decision quickly in order to proceed
with implementation so that we can create the 0.5-M1 release this week.

Whatever decision we make now doesn't necessarily need to last for
eternity. If we learn more about how Hono is used and why our decision
might have been wrong we simply change it :-) We are still in a very
early stage of Hono's development so I would like to focus more on
delivering a working first version soon than delivering the "perfect"
version in a year ...
-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn