Now raised as:
https://issues.apache.org/activemq/browse/CAMEL-1510
--
View this message in context:
http://www.nabble.com/BatchProcessor-interrupt-side-effects-tp22819960p22836192.html
Sent from the Camel - Development (activemq) mailing list archive at Nabble.com.
Hi Gert,
Thanks for your email. Given your acknowledgement of the issue I shall raise
a JIRA and provide a suggested patch. I'll look at the latch idea too.
Kind regards,
Christopher
--
View this message in context:
http://www.nabble.com/BatchProcessor-interrupt-side-ef
he condition is going into a sleep state (nothing enqueued
> that hasn't had its predicate tested), and when it comes out of sleep (if it
> has been), what must then be done. Either exchanges have been enqueued or it
> is time to process exchanges. Even if exchanges have been enqueued th
still drop down into sending exchanges if the batch thresholds have been
reached i.e. as before.
I also make a point of unlocking the runLock prior to calling out to
dependent code.
Thoughts?
--
View this message in context:
http://www.nabble.com/BatchProcessor-interrupt-side-effects-tp22819960p228
