camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Throttler & mock endpoint question
Date Sun, 11 Apr 2010 07:27:39 GMT
Hi

You could just let it route to the mock endpoint.
And then afterwards check at what time they arrived at the mock
endpoint, to see if there is at most 7 within a second.

And btw I think we should add a header to the mock endpoint which
records the arrival time. For now you have to do that yourself.
For example using targetMock.whenAnyExchange(new Processor() {
// set time for arrival
}



On Sat, Apr 10, 2010 at 8:35 PM, Pavel <pagrus@gmail.com> wrote:
> 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
>>
>



-- 
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

Mime
View raw message