Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of pagrus@gmail.com designates
 74.125.82.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=awqpJBN9ilw/8vVVddbw5a8mqHAbstlIQByoKyI03JpuvdycImsQJrHRrYwQfPsrQ/
         TnT1Fg5m97c9q78b9M9tU8+4lcpJj6kCnNpLVuCI3CYwFoy3AIOg8qydX1NKpXA2eqIV
         7g0iP+g54rNlhHBH3PDMbfAeazP1yWBZaO0do=
MIME-Version: 1.0
In-Reply-To: <m2g5380c69c1004100904g788b1899sde34279f6c35af76@mail.gmail.com>
References: <l2if2ace7ab1004100243j60468bf5j66265898f9dd365@mail.gmail.com>
	 <t2p5380c69c1004100431x7c23cbc6oaeccdd8c41ac34f3@mail.gmail.com>
	 <l2tf2ace7ab1004100827r77b36f2bs8be3d5f13873553d@mail.gmail.com>
	 <m2g5380c69c1004100904g788b1899sde34279f6c35af76@mail.gmail.com>
Date: Sat, 10 Apr 2010 21:35:25 +0300
Message-ID: <k2xf2ace7ab1004101135y460b7e3aud9eda29fe638c071@mail.gmail.com>
Subject: Re: Throttler & mock endpoint question
From: Pavel <pagrus@gmail.com>
To: users@camel.apache.org
Content-Type: multipart/alternative; boundary=001636417155de23dd0483e62cbe

--001636417155de23dd0483e62cbe
Content-Type: text/plain; charset=UTF-8

Hi,

I'm fine with +/- 10%, but perhaps with my massive examples I shifted the
focus away from the original issue:
Route throttler is configured for 7 messages per second, but mock endpoint
will match message count of 7, or 14, or anything in between.

Thus the closest test I can do to verify intended limit of 7/second is
        targetMock.expectedMinimumMessageCount(15);
        targetMock.setResultWaitTime(1000);
        ...
        targetMock.assertIsNotSatisfied();

... which is +/- 114%, and value of such test is questionable.
And I'm trying to figure out which of the following is the case

1. My code or test is incorrect
2. There is an issue with throttler
3. There is an issue with mock endpoint
4. Mock endpoint by design is not the right tool for the job

If #3 or #4, I'll need different approach to testing. Otherwise
implementation needs to be changed.

Thanks,
Pavel

On Sat, Apr 10, 2010 at 7:04 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> Hi
>
> You can newer trust 100% on System time millis as its not accurate. So
> make assertions on a given +/- delta.
>
>
>
> On Sat, Apr 10, 2010 at 5:27 PM, Pavel <pagrus@gmail.com> wrote:
> > Tried that, and noticed a few differences. maximumRequestsPerPeriod is 7.
> >
> > * Expected message count <7 consistently fails with "Expected <X>, but
> was
> > <7>"
> > * Expected message count 7-11 passes
> > * Expected message count 12,13 seems racy: sometimes test would fail with
> > "Expected <X>, but was <X+1>"
> > * Expected message count 14,15 passes (or I simply did not catch races).
> > * Expected message count 16-18 is racy again, e.g. "Expected <17>, but
> was
> > <19>"
> > * Expected message count 30 is racy, e.g. "Expected: <30> but was: <32>"
> >
> > That is not 100% precise, as I was giving limited number of tries for
> each
> > case.
> >
> > BTW, camel 2.2.0, activemq-camel 5.3.1.
> >
> > Thanks,
> > Pavel
> >
> > On Sat, Apr 10, 2010 at 2:31 PM, Claus Ibsen <claus.ibsen@gmail.com>
> wrote:
> >
> >> Hi
> >>
> >> Can you try with
> >> targetMock.assertIsSatisfied(1000);
> >>
> >>
> >> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pagrus@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > I'm facing strange behaviour of throttler + mock endpoint when route
> >> under
> >> > test is this:
> >> >
> >> >    <camel:route>
> >> >      <camel:from uri="activemq:A"/>
> >> >      <camel:transacted/>
> >> >      <camel:throttle timePeriodMillis="1000"
> >> maximumRequestsPerPeriod="7">
> >> >        <camel:to uri="activemq:B" />
> >> >      </camel:throttle>
> >> >    </camel:route>
> >> >
> >> > test itself defines producer for "direct -> activemq:A" route, as well
> as
> >> > "activemq:B -> targetMock" route, and then does this:
> >> >
> >> >        targetMock.expectedMessageCount(7);
> >> >        targetMock.setResultWaitTime(1000);
> >> >        for(int i=0; i<40; i++)
> >> >        {
> >> >            producer.sendBody("Message " + i);
> >> >        }
> >> >        targetMock.assertIsSatisfied();
> >> >
> >> > This passes.
> >> > *BUT* if I change targetMock.expectedMessageCount(7); to e.g.
> >> > targetMock.expectedMessageCount(11); it passes as well!
> >> >
> >> > Looks like test would pass if expectedMessageCount is anything between
> >> > [maximumRequestsPerPeriod, 2* maximumRequestsPerPeriod].
> >> >
> >> > I tested various expected message counts against
> >> > maximumRequestsPerPeriod="7"
> >> >
> >> > 3: Expected: <3> but was: <7>
> >> > 4: Expected: <4> but was: <7>
> >> > 5: Expected: <5> but was: <7>
> >> > 6: Expected: <6> but was: <7>
> >> > 7: passed
> >> > 8: passed
> >> > 9: passed
> >> > 10: passed
> >> > 11: passed
> >> > 12: passed
> >> > 13: passed
> >> > 14: passed
> >> > 15: Expected: <15> but was: <14>
> >> > 16: Expected: <16> but was: <14>
> >> > 17: Expected: <17> but was: <14>
> >> > 18: Expected: <18> but was: <14>
> >> > 19: Expected: <19> but was: <14>
> >> > 20: Expected: <20> but was: <14>
> >> >
> >> > ... and against maximumRequestsPerPeriod="3"
> >> >
> >> > 2: Expected: <2> but was: <3>
> >> > 3: passed
> >> > 4: passed
> >> > 5: passed
> >> > 6: passed
> >> > 7: Expected: <7> but was: <6>
> >> > 8: Expected: <8> but was: <6>
> >> > 9: Expected: <9> but was: <6>
> >> > 10: Expected: <10> but was: <6>
> >> >
> >> > Can you please explain that? Is it some sort of mock endpoint
> specifics?
> >> > I'd like my test to be fairly strict, as the goal is to verify that
> route
> >> > meets SLA...
> >> >
> >> > Thanks,
> >> > Pavel
> >> >
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> Apache Camel Committer
> >>
> >> Author of Camel in Action: http://www.manning.com/ibsen/
> >> Open Source Integration: http://fusesource.com
> >> Blog: http://davsclaus.blogspot.com/
> >> Twitter: http://twitter.com/davsclaus
> >>
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>

--001636417155de23dd0483e62cbe--