On Fri, Apr 8, 2011 at 7:24 AM, Willem.Jiang wrote:
> As Camel has a async process module, you can't know if the processors are
> called in a single thread.
> If you are using the thread local to store the states, it may be massed up.
>
> My suggestion is store the states information into the Exch
As Camel has a async process module, you can't know if the processors are
called in a single thread.
If you are using the thread local to store the states, it may be massed up.
My suggestion is store the states information into the Exchange, and Camel
will make sure it is processed rightly.
Will
Using ThreadLocal to store the state perhaps ?
On 4/7/11 4:44 PM, "pminearo" wrote:
>So, essentially you MUST create the Processor to be Thread Safe. Is there
>any way to create a New Instance of the Processor per Thread?
>
>--
>View this message in context:
>http://camel.465427.n5.nabble.com/B
So, essentially you MUST create the Processor to be Thread Safe. Is there
any way to create a New Instance of the Processor per Thread?
--
View this message in context:
http://camel.465427.n5.nabble.com/Best-Practice-fro-Thread-Safe-processor-tp4288973p4289705.html
Sent from the Camel - Users
Processors are singletons.
Typically we don't hold any state in them.
If you want to hold state in Processor, you can do it. In that case, of
course, you have to think of concurrency. There are many ways to that as
you can find in Java Concurrency in Practice. It's all up to you.
On 4/7/11 1:40
Just to clarify a bit because maybe the Processor doesn't show it well nor my
question: Java Concurrency in Practice states that "Stateless objects are
always thread-safe". But what happens when you do have state? What is
everyone finding works best for Threading?
--
View this message in conte
