You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by mjparme <mj...@west.com> on 2007/05/17 15:48:48 UTC

Correlation ID for request/response

When you are using JMS for request/response and you set the correlation ID on
the message does this ID have to be unique for the lifetime of the
well-known queue you are sending to or does it only have to be unique for
the messages currently in the queue?
-- 
View this message in context: http://www.nabble.com/Correlation-ID-for-request-response-tf3772033s2354.html#a10664553
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Correlation ID for request/response

Posted by James Strachan <ja...@gmail.com>.
On 5/17/07, mjparme <mj...@west.com> wrote:
>
>
> >>I've tried to describe it here....
> >>http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
>
> >>by all means edit that wiki page if you think it could be more clear etc.
>
> Yeah, I used that wiki page for my initial development a few weeks back;
> very helpful, the correlation ID question was the last thing I needed to get
> clear in my head.
>
> Adding a couple of more examples to that wiki page is actually still on my
> todo list (literally), I will make sure to do it sooner rather than later.
> Just need to take some time to anonymize my code...don't want to send
> INFOSEC into a tizzy.

LOL! Great stuff many thanks!

-- 
James
-------
http://macstrac.blogspot.com/

Re: Correlation ID for request/response

Posted by mjparme <mj...@west.com>.

>>I've tried to describe it here....
>>http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html

>>by all means edit that wiki page if you think it could be more clear etc.

Yeah, I used that wiki page for my initial development a few weeks back;
very helpful, the correlation ID question was the last thing I needed to get
clear in my head.

Adding a couple of more examples to that wiki page is actually still on my
todo list (literally), I will make sure to do it sooner rather than later.
Just need to take some time to anonymize my code...don't want to send
INFOSEC into a tizzy.


-- 
View this message in context: http://www.nabble.com/Correlation-ID-for-request-response-tf3772033s2354.html#a10665385
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Correlation ID for request/response

Posted by James Strachan <ja...@gmail.com>.
On 5/17/07, mjparme <mj...@west.com> wrote:
>
>
>
> On 5/17/07, mjparme <mj...@west.com> wrote:
> >
> > When you are using JMS for request/response and you set the correlation ID
> > on
> > the message does this ID have to be unique for the lifetime of the
> > well-known queue you are sending to or does it only have to be unique for
> > the messages currently in the queue?
>
> It can be any ID at all; whether unique or not. e.g. you could recycle
> the same ID after each conversation terminates if you like; so it only
> needs to be unique among the currently active conversations. Often a
> client creates it to correlate responses on a temporary queue; so it
> can be unique within a single JVM in some circumstances.
>
> Ahh ok, that makes sense.  The correlation ID is only there so the client
> that sent the request knows which response matches which request (assuming
> the client sends multiple requests at a time). The "server side" (i.e. the
> consumer of of the well-known queue) doesn't care about the correlation ID
> it just needs to make sure to send back the correlation ID it received (and
> I do) so the client can correlate responses to requests...

Bingo! :)


> see this all makes
> perfect sense I just had to talk it out:-)

:).

I've tried to describe it here....
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html

by all means edit that wiki page if you think it could be more clear etc.

-- 
James
-------
http://macstrac.blogspot.com/

Re: Correlation ID for request/response

Posted by mjparme <mj...@west.com>.


On 5/17/07, mjparme <mj...@west.com> wrote:
>
> When you are using JMS for request/response and you set the correlation ID
> on
> the message does this ID have to be unique for the lifetime of the
> well-known queue you are sending to or does it only have to be unique for
> the messages currently in the queue?

It can be any ID at all; whether unique or not. e.g. you could recycle
the same ID after each conversation terminates if you like; so it only
needs to be unique among the currently active conversations. Often a
client creates it to correlate responses on a temporary queue; so it
can be unique within a single JVM in some circumstances.

Ahh ok, that makes sense.  The correlation ID is only there so the client
that sent the request knows which response matches which request (assuming
the client sends multiple requests at a time). The "server side" (i.e. the
consumer of of the well-known queue) doesn't care about the correlation ID
it just needs to make sure to send back the correlation ID it received (and
I do) so the client can correlate responses to requests...see this all makes
perfect sense I just had to talk it out:-)

Thanks!

-- 
View this message in context: http://www.nabble.com/Correlation-ID-for-request-response-tf3772033s2354.html#a10665025
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: Correlation ID for request/response

Posted by James Strachan <ja...@gmail.com>.
On 5/17/07, mjparme <mj...@west.com> wrote:
>
> When you are using JMS for request/response and you set the correlation ID on
> the message does this ID have to be unique for the lifetime of the
> well-known queue you are sending to or does it only have to be unique for
> the messages currently in the queue?

It can be any ID at all; whether unique or not. e.g. you could recycle
the same ID after each conversation terminates if you like; so it only
needs to be unique among the currently active conversations. Often a
client creates it to correlate responses on a temporary queue; so it
can be unique within a single JVM in some circumstances.

-- 
James
-------
http://macstrac.blogspot.com/