It depends what happens during routing as asynchronouns non blocking routing can kick in and there can be different threads processing the exchange along the way.
Your design with using thread local is not a good design. If you need to store some state then you can store that as properties on Camel Exchange that is carried along for the entire lifecycle of that exchange. On Sat, Apr 2, 2016 at 8:29 AM, edhansen42 <e...@vsp.com> wrote: > Camel 2.15.2 > We are having a bit of a problem with EventNotifierSupport events and > threads. > Our goal is to isolate our business logic code from frameworks as much as > possible. To do so, we inject a bean into the business logic code that > provides proxy methods to access information stored in the Exchange. > The Bean class has a thread local that stores Exchanges. > When an ExchangeCreatedEvent occurs, we invoke a method on the bean that > stores the passed in Exchange in the thread local for that thread. > When an ExchangeCompletedEvent occurs, we invoke a method on the bean to > clear out its thread local for that thread. > The problem we're seeing is that the thread on which the > ExchangeCompletedEvent occurs doesn't match the thread on which the > ExchangeCreatedEvent occurs. So when we clear out the thread local for the > ExchangeCompletedEvent thread, we remove the wrong Exchange. > > Is what we're doing just plain wrong? Is Camel managing threads in a way > that makes what we intended impossible? > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/EventNotifierSupport-and-Threads-tp5780279.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
