Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 23 May 2012 02:24:40 +0000 (UTC)
From: "Hiram Chirino (JIRA)" <jira@apache.org>
To: commits@activemq.apache.org
Message-ID: <1865783293.10342.1337739880930.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1598098538.1933.1337553701334.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Updated] (APLO-206) Load balance of job queues when
 'credit:1,0' is used on the consumer.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/APLO-206?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Hiram Chirino updated APLO-206:
-------------------------------

    Summary: Load balance of job queues when 'credit:1,0' is used on the co=
nsumer.  (was: Load balance of job queues)
   =20
> Load balance of job queues when 'credit:1,0' is used on the consumer.
> ---------------------------------------------------------------------
>
>                 Key: APLO-206
>                 URL: https://issues.apache.org/jira/browse/APLO-206
>             Project: ActiveMQ Apollo
>          Issue Type: Improvement
>          Components: apollo-broker, apollo-openwire, apollo-stomp
>    Affects Versions: 1.3
>            Reporter: Jos=C3=A9 Mic=C3=B3
>             Fix For: 1.4
>
>
> I wish to have load balanced job queues, like in ActiveMQ (copied and pas=
ted):
> "A queue implements load balancer semantics. A single message will be rec=
eived by exactly one consumer. If there are no consumers available at the t=
ime the message is sent it will be kept until a consumer is available that =
can process the message. If a consumer receives a message and does not ackn=
owledge it before closing then the message will be redelivered to another c=
onsumer. A queue can have many consumers with messages load balanced across=
 the available consumers."
> For example, suppose that I send tree jobs (j1, j2, j3) to a queue with 2=
 consumers (c1,c2).
> The first job takes 10 seconds to complete, jobs 2 and 3 takes only 1 sec=
ond.
> Consumers are using 'client' ack, with credit:1,0 in order to receive onl=
y one job at the time.
> The desired behaviour of consumers is:
> [ 21:30:00 ][ c1 ] Got job 1
> [ 21:30:00 ][ c2 ] Got job 2
> [ 21:30:01 ][ c2 ] Ack job 2, now idle
> [ 21:30:01 ][ c2 ] Got job 3
> [ 21:30:02 ][ c2 ] Ack job 3, now idle
> [ 21:30:10 ][ c1 ] Ack job 1, now idle
> But currently, Apollo does:
> [ 21:30:00 ][ c1 ] Got job 1
> [ 21:30:00 ][ c2 ] Got job 2
> [ 21:30:01 ][ c2 ] Ack job 2, now idle   (!) c2 is idle but does not gets=
 job 3=20
> [ 21:30:10 ][ c1 ] Ack job 1, now idle
> [ 21:30:10 ][ c1 ] Got job 3
> [ 21:30:11 ][ c1 ] Ack job 3, now idle
> Seems that jobs are assigned in a round-robin fashion at the moment of be=
ing received by the broker.
> If in this example I send 9 jobs of 1 second (instead of 2), consumer #1 =
gets 5 and consumer #2 gets the remaining 5, when the optimum would be to s=
end the 9 fast jobs to consumer #2 while consumer #1 is processing the slow=
 one. I know that using 'client' ack with credit:1,0 is suboptimal from bro=
ker perspective, but is the optimal way to balance jobs between workers.
> Besides the underutilization of resources, the main problem is that if a =
consumer takes too much time to process a job (say, due to a DB lock) it ma=
y block the processing of a bunch of jobs already assigned to it.
> ...
> BTW, impressive piece of work!!! I really impressed by the completeness o=
f features, and how well Apollo behaved when I overloaded it with stress te=
sts :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira