From users-return-20075-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Tue Aug 11 21:39:13 2009
Return-Path:
Delivered-To: apmail-activemq-users-archive@www.apache.org
Received: (qmail 96082 invoked from network); 11 Aug 2009 21:39:13 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 11 Aug 2009 21:39:13 -0000
Received: (qmail 76286 invoked by uid 500); 11 Aug 2009 21:39:19 -0000
Delivered-To: apmail-activemq-users-archive@activemq.apache.org
Received: (qmail 76261 invoked by uid 500); 11 Aug 2009 21:39:19 -0000
Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: users@activemq.apache.org
Delivered-To: mailing list users@activemq.apache.org
Received: (qmail 76221 invoked by uid 99); 11 Aug 2009 21:39:19 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 21:39:19 +0000
X-ASF-Spam-Status: No, hits=1.2 required=10.0
tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [206.190.38.116] (HELO web50807.mail.re2.yahoo.com) (206.190.38.116)
by apache.org (qpsmtpd/0.29) with SMTP; Tue, 11 Aug 2009 21:39:08 +0000
Received: (qmail 83937 invoked by uid 60001); 11 Aug 2009 21:38:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s1024; t=1250026727; bh=g4Sq1kDgJT4nvds4DzrvQwd6jStfTrd52c0Q5ycuAjM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RbqiwdwcTOh3FT4jIWTviatEG99wV9+BpUcn0VeOithKwwtn+BdV3+tRXYTvQcFgDdNFQHD17YSW6qe0BCukxLLrNoPwMmjay3m7b0TJYaGsGoMg8VOL9chjgyH8tUZihkRRWM3V22Tb5oQc9z1BpzxwmD1MUeWi5pmYrd0a3jE=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=rocketmail.com;
h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type;
b=L3H8A8H2ier3J48f8P0YDs6eWqdc2JeSa4/rFZzzi7AnvqPZBJsznCY2R3vLVX/+/2r4+cY+T8Xi0RqTNBNGKg/ly9BVpjjgmiwDVF7BONsYoDv5m84kbqXXrpxnxIvJgWs7G3Bd2ZqQFgZBevky1EVkhpwL2z9oJM0K58zYzf8=;
Message-ID: <611667.82852.qm@web50807.mail.re2.yahoo.com>
X-YMail-OSG: 87vWf08VM1kTA6YnCRT1A.uQsg_zz2.XtM9A8MrFO3NJF2vUhO1cHEkwBr_Bftn2poWMn82sVGqMmAP7IcIYcQtbvAowPpFqQEnP0.A3phYWAYXQRjnEJ196hSjoN9myRMPM5aSx1AcUIP4ynypXdOAmHE0O0_J7VTC4GfFJ8nZxet_C.j2hDq0_u4T31r4GgoeJrESJlO9MfMZ.kmxehIhOOs.zsgkKk43v3IjZPx3xkUCW9.jtNBXC25SARwykovmCVFGFTED0QEjxromZz3_MMUx8cm12aEtQ7tmX66pnp_TAwlhfx.JxYFfFLvHkKbGvgxPq2A--
Received: from [68.110.129.14] by web50807.mail.re2.yahoo.com via HTTP; Tue, 11 Aug 2009 14:38:47 PDT
X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1
References: <24914033.post@talk.nabble.com> <323251.32214.qm@web50809.mail.re2.yahoo.com> <24919423.post@talk.nabble.com>
Date: Tue, 11 Aug 2009 14:38:47 -0700 (PDT)
From: Jose Luna
Subject: Re: Implement request response with JMS over Stomp
To: users@activemq.apache.org
In-Reply-To: <24919423.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Checked: Checked by ClamAV on apache.org
> If I understood right, then each requesting service A (A1...An) should
> maintain its own unique correlation id (permanent during the connection's
> life).
My initial suggestion was actually to have a unique correlation-id for each request. This provides greater granularity than the above proposal, but has the overhead of creating/destroying a consumer for every request. In short, my initial suggestion wasn't a very good one (especially if you're processing a very large volume of request/response messages).
I realized that not having access to temporary queues is actually not a very big limitation as long as you can provide unique queues for the services that are making the request. If you read about the suggested way to implement request-response (http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html), you'll see that temporary queues are not strictly required. You have to be sure to include the reply-to destination in the request, and then you know which destination to check for the response. Since we don't have access to temporary destinations, we simply make sure that destination exists before making requests. So the requesters A1, A2, and A3 might create the following queues:
/queue/responses.A1
/queue/responses.A2
/queue/responses.A3
Then, when A1 makes a request, it sets the reply-to header to "/queue/responses.A1", and then checks that queue for the response. Of course, we can still use the correlation-id to correlate the requests and responses. The benefit of using the temporary queue is that the queue is destroyed when the consumer unsubscribes. So without temporary queues, we need to have a finite number of requesters with some way to uniquely identify themselves. If this requirement cannot be met, then our queue creation could easily get out of control. In other words, we could end up with thousands of queues of the form /queue/responses.{ID}. This can cause problems with resource usage (memory and threads).
If your particular use case can't provide a limited number of unique services, I can think of two possible solutions:
1.) Set your broker config so that it doesn't create previous queues when starting up, then set up a cron job (or windows task schedule) to restart the broker nightly or weekly. This is the cheap solution and would require that you don't need persistence.
2.) Create a broker plugin that destroys any queues that matches /queue/responses.* when the consumer unsubscribes. This is the better long-term solution, and it's essentially mimicking temporary queue behaviour.
Hope that helps,
JLuna
> --
> View this message in context:
> http://www.nabble.com/Implement-request-response-with-JMS-over-Stomp-tp24914033p24919423.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.