From users-return-10492-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Tue Sep 04 06:43:37 2007 Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 80164 invoked from network); 4 Sep 2007 06:43:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Sep 2007 06:43:36 -0000 Received: (qmail 65805 invoked by uid 500); 4 Sep 2007 06:43:30 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 65762 invoked by uid 500); 4 Sep 2007 06:43:30 -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 65746 invoked by uid 99); 4 Sep 2007 06:43:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Sep 2007 23:43:30 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com designates 66.249.82.233 as permitted sender) Received: from [66.249.82.233] (HELO wx-out-0506.google.com) (66.249.82.233) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Sep 2007 06:43:26 +0000 Received: by wx-out-0506.google.com with SMTP id i30so1788298wxd for ; Mon, 03 Sep 2007 23:43:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UiS7Ub1w70S1Bc33iraYVehpXWfDOBcd9ABC7yt8GUV9lph6bd2QHrjpn7gjAfsqWkX2hldqWTxmmguhCBw8y+g1nTpPyfwIJtglBoSQ8aE8M42+ipsZ9lbMz6JSO2kFdAFhhfUs/S+a3iw7NQVOnUaJnjykduCO4qC3D88Fol0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oTDcsLq9YopmPXuBt1A4fA5awC9czj+MqlnKONTm7MiOQkH09a2mIakptG7Y1MGe/HnAvfJaQFE+WogmrZMXAsHufyZMUF6s3hJ7w3xH1qnbqID1OlCES6Hg58FTaD2ykbdRk3wZPDBREQMT5/0twjA6IriaFQLPgZdRxn419/Y= Received: by 10.90.75.10 with SMTP id x10mr2335066aga.1188888185735; Mon, 03 Sep 2007 23:43:05 -0700 (PDT) Received: by 10.90.105.10 with HTTP; Mon, 3 Sep 2007 23:43:05 -0700 (PDT) Message-ID: Date: Tue, 4 Sep 2007 07:43:05 +0100 From: "James Strachan" To: users@activemq.apache.org Subject: Re: Temp queue vs topic via message selector? In-Reply-To: <12434486.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <12434486.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org On 8/31/07, TOPPER_HARLEY wrote: > > Hi all, > We are currently using temp queues for dispatching data to a number of > clients. In this way each client gets only his own data, request response > style. However we are having lots of trouble with the temp queues and the > broker blocking. Could you describe what this problem is & how to reproduce? What version are you using? Are you hitting RAM exhaustion? http://activemq.apache.org/my-producer-blocks.html > We also have topics to dispatch updates to all clients, > which are working well. Instead of a temp quueue for each client, we are > considering using just one permanent topic onto which we would send all > client response data, with each client using a unique message selector to > only get his data. What do ye think of this approach, does it make any > sense? If clients come and go and their messages are meant to be discarded when a client disappears then temporary queues are really exactly what you need. Also lots of clients on a single topic with selectors is much less efficient than using temporary queues. But either should work in theory. > We are worried that the throughput could drop off with all data being > published onto the one destination rather than distributed across many(would > each clients interfere its each others throughput), but we are hoping our > blocking issues would be solved. > > Any opinions or pointer would be appreciated I'd recommend getting temporary queues to work; as it scales better & offers the big feature, that client-specific messages are trashed as soon as clients disconnect. There could maybe be performance issues with the single-topic approach with 'slow consumers'; particularly if its the same producer sending to all the clients. (e.g. 1 client being slow could potentially block messages for other clients using the single topic option). -- James ------- http://macstrac.blogspot.com/