[
https://issues.apache.org/jira/browse/CXF-7784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16544469#comment-16544469
]
Dominic Schmoigl edited comment on CXF-7784 at 7/15/18 8:33 AM:
----------------------------------------------------------------
Hi Andriy,
thanks for pointer - well, it helps partially :)
I do agree and understand that thread-safety is not ensured by the
specification in general. However, on the page you gave the link for it is
stated:
{quote}A single client doing multiple invocations without changing the current
URI or headers is thread-safe.
{quote}
To my mind this is exactly what we are doing:
# On the main thread, we are creating a new client using
{code:java}
client = ClientBuilder.newClient()
{code}
# Still on the main thread, we then configure a corresponding WebTarget out of
it. There is no proxy configuration involved.
# That WebTarget then gets distributed to the threads.
# The threads then do a
{code:java}
webTarget.request()
{code}
which is the call which fails here in this case.
NB: We even don't get to the point where we would be able to access the
headers of that request (the exception is thrown already earlier).
It might be worth to mention that there may be multiple "main threads" in
parallel. Could this have some possible side effect?
Thanks!
Best regards,
Dominic
was (Author: dschmoigl):
Hi Andriy,
thanks for pointer - well, it helps partially :)
I do agree and understand that there thread-safety is not ensured by the
specification. However, on the page you gave the link for it is stated:
{quote}A single client doing multiple invocations without changing the current
URI or headers is thread-safe.
{quote}
To my mind this is exactly what we are doing:
# On the main thread, we are creating a new client using
{code:java}
client = ClientBuilder.newClient()
{code}
# Still on the main thread, we then configure a corresponding WebTarget out of
it. There is no proxy configuration involved.
# That WebTarget then gets distributed to the threads.
# The threads then do a
{code:java}
webTarget.request()
{code}
which is the call which fails here in this case.
NB: We even don't get to the point where we would be able to access the headers
of that request (the exception is thrown already earlier).
It might be worth to mention that there may be multiple "main threads" in
parallel. Could this have some possible side effect?
Thanks!
Best regards,
Dominic
> 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)
