[
https://issues.apache.org/activemq/browse/CAMEL-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63426#action_63426
]
Ashwin Karpe edited comment on CAMEL-3349 at 11/20/10 8:19 AM:
---------------------------------------------------------------
Hi Claus,
Yes, I completely agree. I was hesitating to do this since I have not studied
this camel-cxf component code closely and was worried about side-effects and
multiple rounds of testing since it is a heavily used component.
BTW, I found this at a customer site and I have given them an identical patch
for camel version 2.2.
I will make this change in the coming weeks.
Cheers,
Ashwin...
was (Author: akarpe):
Hi Claus,
Yes, I completely agree. I was hesitating to do this since I have not studied
this camel-cxf component code closely and was worried about side-effects and
multiple rounds of testing since it is a heavily used component.
I will make this change in the coming weeks.
Cheers,
Ashwin...
> Race condition found in CxfRsEndpoint while getting the endpoint binding
> under load and performing sync and async invocation
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-3349
> URL: https://issues.apache.org/activemq/browse/CAMEL-3349
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-cxf
> Affects Versions: 2.2.0, 2.3.0, 2.4.0, 2.5.0
> Reporter: Ashwin Karpe
> Assignee: Ashwin Karpe
> Priority: Critical
> Fix For: 2.6.0
>
> Attachments: camel-cxf-race-condition.patch
>
>
> The CxfRsEndpoint's getBinding method is not thread safe. At a customer site,
> I ran into an issue at startup if 2 threads raced to perform sync and async
> invocation, the code for getBinding (given below) would react in the
> following way.
> - Thread 1 would proceed to create a binding object
> - Thread 2 would mean while still find the binding to be null and
> proceed to create a new binding
> - Meanwhile thread one would have its binding and set the Atomic
> boolean for binding initialized and proceed to set the HeaderStrategy.
> - Thread 2 meanwhile would overwrite the original binding object and
> find that Atomic boolean already set and would have no way to associate a
> HeaderFilterStrategy object since the flag is up.
> - In the absence of a HeaderFilterStrategy, copying of ProtocolHeaders
> etc will throw exceptions on every following request/invocation.
> --------------------------------------------------
> public CxfRsBinding getBinding() {
> if (binding == null) {
> binding = new DefaultCxfRsBinding();
> if (LOG.isDebugEnabled()) {
> LOG.debug("Create default CXF Binding " + binding);
> }
> }
>
> if (!bindingInitialized.getAndSet(true) && binding instanceof
> HeaderFilterStrategyAware) {
>
> ((HeaderFilterStrategyAware)binding).setHeaderFilterStrategy(getHeaderFilterStrategy());
> }
>
> return binding;
> }
> ------------------------------------------------
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
