Dan Salt created CXF-7135:
-----------------------------

             Summary: ConcurrentModificationException 
                 Key: CXF-7135
                 URL: https://issues.apache.org/jira/browse/CXF-7135
             Project: CXF
          Issue Type: Bug
          Components: JMS
    Affects Versions: 3.0.11
         Environment: Mac OSX 10.11.6. 
Java JDK 1.8.0_71 (64 bit Server)
            Reporter: Dan Salt
         Attachments: cxf-rsjms-testcase.zip

Our platform allows the user to switch transports for a particular proxy based 
on configuration. We currently allow HTTP and JMS as possible options.

During recent performance testing, we've hit a bug which causes JAXRS Clients 
over JMS to fail with a ConcurrentModificationException:

A test case is attached that reproduces our problem.

Our test executes requests across multiple concurrent threads, switching 
between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case, 
executing JAXWS over JMS works fine, both in single and multi-threaded tests. 
JAXRS works fine across single and multi-threaded tests over HTTP with the 
'ThreadSafe' flag set on the Client Factory. But when the transport is switched 
to JMS two problems occur:

1) The ConnectionFactoryFeature fails to properly set the JMS Conduit and 
results in an error because no Connection Factory is set. This is because in 
JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a 
ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either 
of it's methods. 

We have worked around this in our code by sub-classing and overriding the 
method:
public void initialize(InterceptorProvider interceptorProvider, Bus bus)

.. and adding code similar to that in the ConnectionFactory feature. This 
resolves the missing ConnectionFactory problem.

2) Under multi-threaded conditions, the JAXRS Clients fail with the following 
exception:

javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, 
class java.lang.String, ContentType: text/plain.
        at 
org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438)
        at 
org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378)
        at 
org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521)
        at 
org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817)
        at 
org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760)
        at 
org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)
        at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source)
        at 
com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.ConcurrentModificationException
        at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
        at java.util.HashMap$EntryIterator.next(HashMap.java:1463)
        at java.util.HashMap$EntryIterator.next(HashMap.java:1461)
        at java.util.HashMap.putMapEntries(HashMap.java:511)
        at java.util.HashMap.putAll(HashMap.java:784)
        at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188)
        at 
org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213)
        at 
org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174)
        at 
org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172)
        at 
org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345)
        at 
org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369)
        ... 7 more

This occurs even though the 'ThreadSafe' property is set via:

rsClientFactory.setThreadSafe(true);

I've done quite a large amount of digging through the code to try and narrow 
down the scope of the problem, and the results above is as far as I could get, 
unfortunately.

Finally, one important factor is that this error only happens on the latest 
3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT occur. 
Not sure if this equates to a fix not being back-ported, or a fundamental 
difference in functionality. Sadly, we're not able to yet move to 3.1.x, 
because of running inside the Karaf container, and our dependencies on Camel 
and Spring 3.x.

Thanks. Please let me know if you need any other information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to