[
https://issues.apache.org/jira/browse/CXF-7784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545921#comment-16545921
]
Andriy Redko commented on CXF-7784:
-----------------------------------
Hey Dominic,
Good and bad news at the same time. On the good side, surely, I was able to
reproduce the issue in the simple test case, thanks to your detailed
description. On the bad side, it turned out that the `Client` reuses the same
`ClientProviderFactory` instance on each `request()` invocation. And the latter
was not designed to be thread-safe, from top to bottom. For sure, we could have
added `synchronized` everywhere but this is more like monkey patching rather
than acceptable solution.
But, one more thing on a good side. It seems like you could go one step further
and safely share the `Invocation.Builder` instance, for example:
{code:java}
Invocation.Builder builder = webTarget.request();{code}
It also qualifies under this statement pretty well as all invocation calls are
available
{quote}A single client doing multiple invocations without changing the current
URI or headers is thread-safe.
{quote}
And I was not able to spot any concurrent modification exceptions or alike
while using `builder` from many threads. I am wondering if this solution would
fit to your use case (it should be, right?). Thanks.
Best Regards,
Andriy Redko
> 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
> Assignee: Andriy Redko
> 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)
