Neil Drummond commented on CAMEL-12638:

We just ran into this on a project I am currently working on.

Looking at the {{DefaultFluentProducerTemplate}} class, it looks like it 
mutates it's internal state in it's implementation of the methods of the 
{{FluentProducerTemplate}} interface. Because the builder isn't immutable, it 
would appear that any two threads using the same 
{{DefaultFluentProducerTemplate}} instance (as in the example in the 
description) would allow for any state changes from one thread to leak into the 

In my case, it looks like the body is often getting swapped out with one from 
another thread, but it looks like any of the internal state could get mixed up 
since this class isn't immutable.  I'm not sure what the performance 
implications of making this class immutable would be, but that would definitely 
appear to be one way to solve the problem.

> DefaultFluentProducerTemplate is not thread safe
> ------------------------------------------------
>                 Key: CAMEL-12638
>                 URL: https://issues.apache.org/jira/browse/CAMEL-12638
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.20.2
>            Reporter: Lukasz
>            Priority: Major
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets 
> replaced with a body of proceeding request, in our case we use *request()* 
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
> {code:java}
> @Service
> public class UseCamelService {
>    private FluentProducerTemplate producer;
>    @Autowired
>    public UseCamelService(FluentProducerTemplate producer) {
>       this.producer = producer;
>    }
>    public String getValueFromCamel(String body) {
>       return producer.to("route").withBody(body).request(String.class);
>    }
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different 
> threads it is possible for the latter one to override the body of the first 
> one.

This message was sent by Atlassian JIRA

Reply via email to