activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mittler, Nathan" <nathan.mitt...@sensis.com>
Subject RE: STOMP and connect/connected handshake
Date Mon, 12 Jun 2006 14:24:27 GMT
There is already a correlation-id header defined in the AMQ extensions:
http://www.activemq.org/site/stomp.html - I was trying to reuse this
header for the connect handshake.  I don't feel that strongly one way or
the other. The name "response-id" is fine - we'd just have to add
another header to our list of extensions (we'd have to do that for the
"command-id" header anyway).

Nate

-----Original Message-----
From: chirino@gmail.com [mailto:chirino@gmail.com] On Behalf Of Hiram
Chirino
Sent: Monday, June 12, 2006 10:05 AM
To: activemq-dev@geronimo.apache.org; dev@stomp.codehaus.org
Subject: Re: STOMP and connect/connected handshake

Cross posting to the stomp mailing list too since someone there might
have some input on this.

I like the idea about supporting a command-id header.  I might prefer
the correlation header to be called response-id instead of
correlation-id.

---------- Forwarded message ----------
From: Nathan Mittler <nathan.mittler@gmail.com>
Date: Jun 12, 2006 6:13 AM
Subject: STOMP and connect/connected handshake
To: activemq-dev@geronimo.apache.org


For the new activemq-cpp library, we need to extend the STOMP
connect/connected handshake so that we get back a correlation-id for our
response correlator.  To do this, we need to send something in the
connect
request that contains a client-defined command-id.  My first thought was
to
just reuse the message-id header, but that is typically reserved for
cases
when a client is expecting to acknowledge a message.  So rather than
risk
breaking that paradigm, I created a new header "command-id" that is just
used on the connect message.  When the broker receives a connect request
with a command-id header, it creates a connected response with a
correlation-id set to the command-id of the original request.  This way
the
client can treat the handshake as a true request/response.

Does anyone see any problems with adding this to the broker?

Regards,
Nate



-- 
Regards,
Hiram

Mime
View raw message