We are actually storing state in the Exchange. Our routes are boilerplate code that end up invoking a beanref. This beanref class has no knowledge of Camel - it just has our injected Bean. Our developers can work on their business logic without having to know anything about Camel. They can access information from, or set information on the injected Bean and the injected Bean will retrieve or store the information in its thread's Exchange's properties or headers.
I understand that you think this isn't a good design - and I most certainly respect your point of view, but we aren't doing any asynchronous routing in our boiler plate route - it's pretty simple. We don't see any problem if one or two simultaneous requests initiate this route. The issue occurs when three or more simultaneous requests initiate the route. I'd like to go back to my team with a little more information on why this is a bad design. Can I tell them that Camel is managing the threads, and it's not a good idea to rely on one particular thread being used throughout the lifespan of a single synchronous route? -- View this message in context: http://camel.465427.n5.nabble.com/EventNotifierSupport-and-Threads-tp5780279p5780331.html Sent from the Camel - Users mailing list archive at Nabble.com.
