[
https://issues.apache.org/jira/browse/CXF-7784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Schmoigl updated CXF-7784:
----------------------------------
Description:
By chance we stumbled over a case, where calling
{code:java}
webTarget.request(){code}
sometimes may lead to a {{java.util.ConcurrentModificationException}}, if the
{{webTarget}} is created in one thread, but the call to {{.request()}} is
performed in multiple concurrent threads afterwards. In our environment it was
possible to provoke the exception with probability of ~10%, if run with 4
threads in parallel.
The callstack, which we could isolate, was:
{code:java}
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.injectContextProxies(ProviderFactory.java:638)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.setCommonProviders(ProviderFactory.java:600)
at
org.apache.cxf.jaxrs.client.ClientProviderFactory.setProviders(ClientProviderFactory.java:74)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:791)
at
org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl.request(ClientImpl.java:282)
at <<custom-coding-which-calls-webTarget.request()>>
{code}
We currently have a workaround with
{code:java}
synchronized (webTarget) {
webTarget.request();
}
{code}
which isn't perfect, but good enough for our case.
Is this case known to you? We did not try to reproduce the issue in isolation,
yet (as it was hard enough to find it in our application already). If we should
give it a try, please notify us.
was:
By chance we stumbled over a case, where calling
{code:java}
webTarget.request(){code}
sometimes may lead to a {{java.util.ConcurrentModificationException}}, if the
{{webTarget}} is created in one thread, but the call to {{.request()}} is
performed in multiple concurrent threads afterwards. In our environment it was
possible provoke the exception with probability of ~10% if run with 4 threads
in parallel.
The callstack which we could isolate was:
{code:java}
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
at java.util.ArrayList$Itr.next(ArrayList.java:859)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.injectContextProxies(ProviderFactory.java:638)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.setCommonProviders(ProviderFactory.java:600)
at
org.apache.cxf.jaxrs.client.ClientProviderFactory.setProviders(ClientProviderFactory.java:74)
at
org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:791)
at
org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl.request(ClientImpl.java:282)
at <<custom-coding-which-calls-webTarget.request()>>
{code}
We currently have a workaround with
{code:java}
synchronized (webTarget) {
webTarget.request();
}
{code}
which isn't perfect, but good enough in our case.
Is this case known to you? We did not try to reproduce the issue in isolation,
yet (as it was hard enough to find it in our application already). If we should
give it a try, please notify us.
> java.util.ConcurrentModificationException on WebTarget.request()
> ----------------------------------------------------------------
>
> Key: CXF-7784
> URL: https://issues.apache.org/jira/browse/CXF-7784
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.1.14
> Environment: * Hystrix 1.5.9
> * Spring-Boot 1.5.14
> * JAXRS 3.1.14
> Reporter: Dominic Schmoigl
> Priority: Minor
> Labels: cxf-rt-frontend-jaxrs
>
> By chance we stumbled over a case, where calling
> {code:java}
> webTarget.request(){code}
> sometimes may lead to a {{java.util.ConcurrentModificationException}}, if the
> {{webTarget}} is created in one thread, but the call to {{.request()}} is
> performed in multiple concurrent threads afterwards. In our environment it
> was possible to provoke the exception with probability of ~10%, if run with 4
> threads in parallel.
> The callstack, which we could isolate, was:
> {code:java}
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> at java.util.ArrayList$Itr.next(ArrayList.java:859)
> at
> org.apache.cxf.jaxrs.provider.ProviderFactory.injectContextProxies(ProviderFactory.java:638)
> at
> org.apache.cxf.jaxrs.provider.ProviderFactory.setCommonProviders(ProviderFactory.java:600)
> at
> org.apache.cxf.jaxrs.client.ClientProviderFactory.setProviders(ClientProviderFactory.java:74)
> at
> org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:791)
> at
> org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl.request(ClientImpl.java:282)
> at <<custom-coding-which-calls-webTarget.request()>>
> {code}
> We currently have a workaround with
> {code:java}
> synchronized (webTarget) {
> webTarget.request();
> }
> {code}
> which isn't perfect, but good enough for our case.
>
> Is this case known to you? We did not try to reproduce the issue in
> isolation, yet (as it was hard enough to find it in our application already).
> If we should give it a try, please notify us.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
