Return-Path: X-Original-To: apmail-activemq-users-archive@www.apache.org Delivered-To: apmail-activemq-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 09CBA11437 for ; Wed, 16 Jul 2014 01:27:44 +0000 (UTC) Received: (qmail 69214 invoked by uid 500); 16 Jul 2014 01:27:42 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 69174 invoked by uid 500); 16 Jul 2014 01:27:42 -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 69162 invoked by uid 99); 16 Jul 2014 01:27:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jul 2014 01:27:42 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of nhrdls@gmail.com designates 209.85.220.43 as permitted sender) Received: from [209.85.220.43] (HELO mail-pa0-f43.google.com) (209.85.220.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jul 2014 01:27:38 +0000 Received: by mail-pa0-f43.google.com with SMTP id lf10so300772pab.30 for ; Tue, 15 Jul 2014 18:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=BMDcDA89qlm3QJNyAY1PqD3C4vXs4r4Q+6UtoFHl+tg=; b=yzE1oyOOULt6p3052tB/JJ14WHw8M6n1CBSZI+E1z0yPYpFlMMQVBXOQ61d09L/e4p 8XkwU1nOR3lSJpkMGtcEEl7+tzt3X+zyny/+akWyoCbA5IC2LTIruyH0uVpP5GEDqrSk 4LV2S/OYRHLzL5mMqa2ze/bEhibqMfgwQSaqXB66mAGq3gBgCFqIMpCOz9NfIkTwjU3P bNgg/vU3XcDZfAdZ094j5ApigB1uP4wPPcT58ZLLyaIYOMT9hQZLL8qScvb6io799pWN xQYpgNmeRP5AQdrhqtt8vVzWuwFCWKIIB0n7b5LRQHqFtFD/eFzEX+2ZfL5s6HrR810e x1jA== X-Received: by 10.70.131.134 with SMTP id om6mr26218565pdb.95.1405474033129; Tue, 15 Jul 2014 18:27:13 -0700 (PDT) Received: from [10.0.0.204] (173-164-138-60-SFBA.hfc.comcastbusiness.net. [173.164.138.60]) by mx.google.com with ESMTPSA id k7sm5577445pdo.30.2014.07.15.18.27.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 18:27:12 -0700 (PDT) Message-ID: <53C5D4EE.8060402@gmail.com> Date: Tue, 15 Jul 2014 18:27:10 -0700 From: Niranjan Rao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: users@activemq.apache.org Subject: How to optimize performance of multiple producers and consumers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Greetings, We are on version 5.10 - recently migrated, but don't think my problem is version specific. In short, it boils down to can I evaluate the selector information on producer side? I need to make decision whether this is a good time to place the job or not. I have multiple producers and consumers using same queue. Producers can be broadly categorized as live and batch consumers. Between the time producer sends the message and consumer responds back with results, the entity in question gets in "locked" state. Since the consumers have finite capacity as message processing takes lot of time (more than 5 minutes usually), I am trying to avoid locking of entities. Our consumers already publish heartbeat on a topic which has lot of useful data including number of jobs they are running and capacity they are configured with. So I have some idea whether I can place the job or not. The part I can not get around is selectors on the consumers. Consumers prioritize messages from live users as long as number of concurrently processed messages don't exceed the capacity defined. Batch jobs which produce many more messages, however get lower priority. Given the selector, can I some how evaluate the selector on producer side to check if consumer will process the the job quickly enough? The consumer capacity is dynamic as operations team can disable some consumers or the traffic pattern changes. So asking consumers via hear beat seems to be best solution. I don't want consumers to sit idle, nor I want to load up the messages and lock my entities for long time. I am open to other ideas also Regards, Niranjan