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

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

+1

-- 
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


On Mi, 2016-06-29 at 08:15 +0000, Guggemos Dominik (INST/ECS1) wrote:
> 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@eclipse
> > .org] 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
> _______________________________________________
> 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