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

["Guggemos Dominik (INST/ECS1)" <Dominik.Guggemos@xxxxxxxxxxxx>]

After some more talking on the chat, we want to propose a tradeoff so that we don’t have to decide about the pattern (now): we support both patterns (Message ID and Correlation ID) in Hono. That means if a client sends a message with messageId and replyTo headers, we copy the messageId to the correlationId in the response, if a client sends a message with messageId, correlationId and replyTo headers we copy the correlation from the original message to correlationId in the response. Of course we need to document this properly but this way we would stay AMQP compliant and support JMS based clients at the same time. As mentioned earlier we can drop one pattern later if problems will arise. Sounds reasonable?

> -----Original Message-----
> From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Hudalla Kai (INST/ESY1)
> Sent: Monday, June 27, 2016 12:00 PM
> To: hono-dev@xxxxxxxxxxx
> Subject: [hono-dev] Why we shouldn't correlate messages based on message ID
> 
> 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
> 
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this
> list, visit https://dev.eclipse.org/mailman/listinfo/hono-dev