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 >
