You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Pavel <pa...@gmail.com> on 2010/04/10 11:43:10 UTC
Throttler & mock endpoint question
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
Re: Throttler & mock endpoint question
Posted by Claus Ibsen <cl...@gmail.com>.
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 <pa...@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 <cl...@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 <pa...@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 <cl...@gmail.com>
>> wrote:
>> >
>> >> Hi
>> >>
>> >> Can you try with
>> >> targetMock.assertIsSatisfied(1000);
>> >>
>> >>
>> >> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pa...@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
Re: Throttler & mock endpoint question
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I have created ticket
https://issues.apache.org/activemq/browse/CAMEL-2630
You can comment any ideas you may have to improve the mock to better
support your use case
On Sat, Apr 10, 2010 at 8:35 PM, Pavel <pa...@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 <cl...@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 <pa...@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 <cl...@gmail.com>
>> wrote:
>> >
>> >> Hi
>> >>
>> >> Can you try with
>> >> targetMock.assertIsSatisfied(1000);
>> >>
>> >>
>> >> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pa...@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
Re: Throttler & mock endpoint question
Posted by Pavel <pa...@gmail.com>.
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 <cl...@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 <pa...@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 <cl...@gmail.com>
> wrote:
> >
> >> Hi
> >>
> >> Can you try with
> >> targetMock.assertIsSatisfied(1000);
> >>
> >>
> >> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pa...@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
>
Re: Throttler & mock endpoint question
Posted by Claus Ibsen <cl...@gmail.com>.
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 <pa...@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 <cl...@gmail.com> wrote:
>
>> Hi
>>
>> Can you try with
>> targetMock.assertIsSatisfied(1000);
>>
>>
>> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pa...@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
Re: Throttler & mock endpoint question
Posted by Pavel <pa...@gmail.com>.
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 <cl...@gmail.com> wrote:
> Hi
>
> Can you try with
> targetMock.assertIsSatisfied(1000);
>
>
> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pa...@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
>
Re: Throttler & mock endpoint question
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Can you try with
targetMock.assertIsSatisfied(1000);
On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pa...@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