Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Message-ID: <31696173.1157662163487.JavaMail.jira@brutus>
Date: Thu, 7 Sep 2006 13:49:23 -0700 (PDT)
From: "Vadim Pesochinskiy (JIRA)" <jira@apache.org>
To: activemq-dev@geronimo.apache.org
Subject: [jira] Updated: (AMQ-855) Add support for prefetchSize = 0
In-Reply-To: <21112865.1154453363111.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

     [ https://issues.apache.org/activemq/browse/AMQ-855?page=3Dall ]

Vadim Pesochinskiy updated AMQ-855:
-----------------------------------

    Attachment: PrefetchSubscription.java.patch2

Almost resolved :-). There 2 minor but significant changes.=20

1.=09pullMessage(). Changed:

prefetchExtension++ to prefetchExtension=3D1  The problem with increment is=
 that when message is rolled back by client, consumer will call receive*() =
again and that will make prefetchExtension 2 and the window will be open pe=
rmanently again, i.e. goes back to push instead of pull. In case of roll ba=
ck client does not really need to pull, but there is not much harm in it.

2.=09acknowledge(ConnectionContext, MessageAck). Changed as follows:
  =20
     line 191:
     ++ if (getPrefetchSize() !=3D 0) {
           prefetchExtension=3DMath.max(prefetchExtension,index+1);
     ++ }

What happens here is when standard ack is received window is         extend=
ed to push more messages, which we do not need in pulling client situation.

> Add support for prefetchSize =3D 0
> --------------------------------
>
>                 Key: AMQ-855
>                 URL: https://issues.apache.org/activemq/browse/AMQ-855
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 4.0, 4.0.1, 4.0.2
>         Environment: any
>            Reporter: Vadim Pesochinskiy
>         Assigned To: Hiram Chirino
>            Priority: Critical
>             Fix For: 4.1
>
>         Attachments: ActiveMQMessageConsumer.patch, ActiveMQMessageConsum=
er.patch2, PrefetchSubscription.java.patch2, PrefetchSubscription.patch, re=
gion.QueueSubscription.java.patch, ZeroPrefetchConsumerTest.java.patch
>
>
> This feature would enable to support following test case:
> 2 servers are processing 3 submitted jobs with following processing times=
 10 min, 1 min, 1 min. This sequence should finish in 10 minutes as one ser=
vice will pick up the 10 minutes job, meanwhile the other one should manage=
 the two 1 minute jobs. Since I cannot set prefetchSize=3D0, one of the 1 m=
inute jobs is sitting in prefetch buffer and the jobs are processed in 11 m=
inutes instead of 10.
> This is simplification of the real scenario where I have about 30 consume=
rs submitting jobs to 20 consumers through AMQ 4.0.1. I have following prob=
lems:
> =95 Messages are sitting in prefetch buffer are not available to processo=
rs, which results in a lot of idle time.
> =95 Order of processing is random. For some reason Job # 20 is processed =
after Job # 1500. Since senders are synchronously blocked this can result i=
n time-outs.
> =95 Some requests are real-time, i.e. there is a user waiting, so the sys=
tem cannot wait, so AMQ-850 does not fix this issue.

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
ps://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira