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 <[email protected]> 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 <[email protected]> wrote: > >> Hi >> >> Can you try with >> targetMock.assertIsSatisfied(1000); >> >> >> On Sat, Apr 10, 2010 at 11:43 AM, Pavel <[email protected]> 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
