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 <pag...@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.ib...@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 <pag...@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.ib...@gmail.com>
>> wrote:
>> >
>> >> Hi
>> >>
>> >> Can you try with
>> >> targetMock.assertIsSatisfied(1000);
>> >>
>> >>
>> >> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <pag...@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
