Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: neutral (nike.apache.org: 216.139.236.26 is neither permitted
 nor denied by domain of camel.user.ch@gmail.com)
Date: Mon, 17 Dec 2012 01:14:31 -0800 (PST)
From: "camel.user2.ch" <camel.user.ch@gmail.com>
To: users@camel.apache.org
Message-ID: 
 <CAOOSxxmbMqqfkDPrD4tmU8s=z9DnWac+CPuVRqOEvQWkymwV2w@mail.gmail.com>
In-Reply-To: <CCEFBC5A.334F%babak.vahdat@swissonline.ch>
References: <1355318623364-5723952.post@n5.nabble.com>
 <CCEE5AE4.32E1%babak.vahdat@swissonline.ch>
 <CCEE9623.32F7%babak.vahdat@swissonline.ch>
 <1355403106152-5724031.post@n5.nabble.com>
 <CCEFBC5A.334F%babak.vahdat@swissonline.ch>
Subject: Re: mock.expectedMessageCount(0) resulting in a false positive
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_44834_4622143.1355735671264"

------=_Part_44834_4622143.1355735671264
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Babak,

Thanks for your reply, I stand corrected :-) I was actually looking in the
testing section of the book (chpt. 6) and hadn't got down as far as chpt.
9, but it does indeed imply there is a race condition between the route and
the main test thread, thanks for pointing me in the right direction.

I was thinking of using a CountDownLatch in a similar fashion as the
MockEndpoints until you pointed me in the direction of the NotifyBuilder.
This seems to be working really nicely so I'm going to stick with that for
now.

Thanks again for your help, very much appreciated.

Regards,
John


On Thu, Dec 13, 2012 at 5:32 PM, Babak Vahdat [via Camel] <
ml-node+s465427n5724047h99@n5.nabble.com> wrote:

>
>
> Am 13.12.12 13:51 schrieb "camel.user2.ch" unter <[hidden email]<http://user/SendEmail.jtp?type=node&node=5724047&i=0>>:
>
>
> >Hi Babak,
> >
> >Thanks a lot for your reply, it confirms what I suspected from looking
> >through the source. I can see that when you setExpectedMessageCount(0),
> >there is no countdown latch, resulting in the mock being asserted on
> >pretty
> >much straight away.
>
> That's correct.
>
> >
> >I don't really like the MockEndpoint.setSleepForEmptyTest() idea as it's
> >pretty much analogous to sticking an arbitrary Thread.sleep() into the
> >code.
>
> This is just a matter of personal taste.
>
> >
> >The NotifyBuilder example seems to work a lot nicer however, thanks a lot
> >for your suggestion. I now have:
> >
> >       // wait for the message to pass through the route before running
> >the
> >assertions.
> >        // JMS msgs are processed asynchronously creating a race
> condition
> >for the test.
> >        NotifyBuilder notify = new
> >NotifyBuilder(context).whenDone(1).create();
> >        notify.matches(500, TimeUnit.MILLISECONDS);
> >
> >        sftpMockEndpoint.assertIsSatisfied();
> >
> >And this is working as expected.
> >
> >I'm a little surprised that there is not much mention of this potential
> >race
> >condition when using the Camel testing framework - neither within the
> >online
> >documentation nor within the Camel in Action book. It seems to be a
> pretty
> >big omission within what is otherwise an excellent and well documented
> >framework.
>
> Check the page 295 with an example where it says:
>
> QUOTE_BEGIN
>
>    "Then you sleep a bit to let the routing complete."
>
> QUOTE_END
>
> In general count with this whenever you make use of a polling consumer:
>
>
>    http://camel.apache.org/polling-consumer.html
>
> Also another way of doing this is the usage of a
>
>    java.util.concurrent.CountDownLatch
>
> through which you can make sure that you do assert on something *after*
> some
> conditions have been already fulfilled for sure. If you look at the
> Camel's
> own unit tests you will find pretty much of this pattern as well.
>
> Greetings from the domain "ch" as well... :-)
>
> Babak
>
>
>
>
> >
> >Thanks for your help.
> >John
> >
> >
> >
> >--
> >View this message in context:
> >
> http://camel.465427.n5.nabble.com/mock-expectedMessageCount-0-resulting-in
> >-a-false-positive-tp5723952p5724031.html
> >Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/mock-expectedMessageCount-0-resulting-in-a-false-positive-tp5723952p5724047.html
>  To unsubscribe from mock.expectedMessageCount(0) resulting in a false
> positive, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5723952&code=Y2FtZWwudXNlci5jaEBnbWFpbC5jb218NTcyMzk1Mnw1OTQ2Nzk5OTU=>
> .
> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://camel.465427.n5.nabble.com/mock-expectedMessageCount-0-resulting-in-a-false-positive-tp5723952p5724215.html
Sent from the Camel - Users mailing list archive at Nabble.com.
------=_Part_44834_4622143.1355735671264--