camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashwin Karpe (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CAMEL-3349) Race condition found in CxfRsEndpoint while getting the endpoint binding under load and performing sync and async invocation
Date Fri, 19 Nov 2010 22:37:24 GMT

     [ https://issues.apache.org/activemq/browse/CAMEL-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ashwin Karpe updated CAMEL-3349:
--------------------------------

          Component/s: camel-cxf
             Priority: Critical  (was: Major)
    Affects Version/s: 2.2.0
                       2.3.0
                       2.4.0
                       2.5.0
        Fix Version/s: 2.6.0

> 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.


Mime
View raw message