Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <32747172.409931285536695126.JavaMail.jira@thor>
Date: Sun, 26 Sep 2010 17:31:35 -0400 (EDT)
From: "Sergey Beryozkin (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Commented: (CXF-2997) CXF JAX-RS not thread safe when
 accessing multiple destinations concurrently
In-Reply-To: <9671129.231771284653158565.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915044#action_12915044 ] 

Sergey Beryozkin commented on CXF-2997:
---------------------------------------

This is the initial attempt to fix it :

http://svn.apache.org/viewvc?rev=1001520&view=rev 

If one has many servlets 'binding' to the same destination then one has to set either "disable-address-updates" servlet parameter on each servlet to true or call setDisableAddressUpdates on CXFServlet/CXFNonSpringServlet.

Perhaps, another and better solution is to introduce a thread local storage and associate it with Destination and completely disable the address overwrites but I thought that with the CXF 2.3 release coming close this change would be a bit unsafe - we'd just not know what we'd break.

Any other ideas and comments are welcome. 
Please verify if this commit fixes the problem. We can get a proper fix once we evaluate what side-effects are possible...  

> CXF JAX-RS not thread safe when accessing multiple destinations concurrently 
> -----------------------------------------------------------------------------
>
>                 Key: CXF-2997
>                 URL: https://issues.apache.org/jira/browse/CXF-2997
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS, Transports
>    Affects Versions: 2.2.10
>            Reporter: Ate Douma
>            Priority: Blocker
>             Fix For: 2.3, 2.2.11
>
>         Attachments: cxf-rest-test.tar.gz
>
>
> If a (single) JAX-RS service is invoked concurrently for different destinations, the CXF ServletController and ServletTransportFactory implementations override the current Destination state between these invocations.
> I have created a simple test web application using Spring to expose this problem.
> My example ServiceImpl.java looks like:
> @Path("/myservice/")
> @Produces("application/xml")
> public class ServiceImpl {
>   volatile boolean locked;
>   @GET
>   @Path("/uris")
>   @Produces("text/plain")
>   public String getUris(@Context UriInfo uriInfo) {
>     StringBuilder uris = new StringBuilder("BaseUri on entry: "+uriInfo.getBaseUri().toString()).append("\n");
>     try {
>       while (locked) {
>         Thread.sleep(1000);
>       }
>     }  
>     catch (Exception x) {}
>     return uris.append("BaseUri on exit : " + uriInfo.getBaseUri().toString()).append("\n").toString();
>   }
>     
>   @GET
>   @Path("/lock")
>   @Produces("text/plain")
>   public String lock() {
>     locked = true;
>     return "locked";
>   }
>   @GET
>   @Path("/unlock")
>   @Produces("text/plain")
>   public String unlock() {
>     locked = false;
>     return "unlocked";
>   }
> And in my web.xml I defined two CXFServlet mappings as follows:
>     <servlet-mapping>
>         <servlet-name>CXFServlet</servlet-name>
>         <url-pattern>/one/*</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>CXFServlet</servlet-name>
>         <url-pattern>/two/*</url-pattern>
>     </servlet-mapping>
> Finally, in Spring ApplicationContext.xml I setup the jaxrs server like this:
>     <jaxrs:server id="myService" address="/">
>         <jaxrs:serviceBeans>
>             <ref bean="serviceImpl" />
>         </jaxrs:serviceBeans>
>         <jaxrs:extensionMappings>
>             <entry key="xml" value="application/xml" />
>         </jaxrs:extensionMappings>
>     </jaxrs:server>
>     <bean id="serviceImpl" class="service.ServiceImpl" />
> As can be seen from the ServicesImpl.java, I used a trick to temporarily "lock" and "unlock" a call to /myservice/uris from another request using /myservice/lock and /myservice/unlock.
> Without locking, a call to http://localhost:8085/one/myservice/uris produces the expected following result:
>   BaseUri on entry: http://localhost:8085/one/
>   BaseUri on exit : http://localhost:8085/two/
> However, if I first call http://localhost:8085/one/myservice/lock, then http://localhost:8085/one/myservice/uris (blocked), and finally http://127.0.0.1:8085/two/myservice/unlock (note the different hostname 127.0.0.1 and servletPath /two) I get the following result:
>   BaseUri on entry: http://localhost:8085/one/
>   BaseUri on exit : http://127.0.0.1:8085/two/
> Clearly, UriInfo.getBaseURI() isn't thread safe as is shown above.
> After debugging a bit the current (CXF 2.2.10) implementation of the ServletController and ServletTransportFactory, it looks like the ServletController.updateDests(HttpServletRequest) method and the ServletTransportFactory as a whole don't maintain resolved Destination state isolated per request.
> Our CXF (JAX-RS) application exposes the same REST service to be called from many different addresses (hosts) as well as upfront unknown servlet paths, this really is a blocking issue.
> To be more concrete, we have to use a request wrapper to dynamically "mount" the same rest service for different urls (its a front end for a unlimited hierarchical resources repository). 
> Is there an easy way to protect JAX-RS service interactions from concurrent invocations, e.g. by using special configurations, or is this indeed a serious bug which will have to be fixed first? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.