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

Dominic Schmoigl edited comment on CXF-7784 at 7/16/18 7:02 AM:
----------------------------------------------------------------

{quote}I afraid that we may fix this one but (many?) other may pop up. So yeah, 
could be challenging ...
{quote}
That's one of the reasons why I opened this ticket ;) The more bugs we find 
(and are able to fix) the better.
{quote}Do you have a workaround for the time being? (like create client per 
thread f.e.) Thanks!
{quote}
As described above, it seems a valid approach to "synchronized" around it like
{code:java}
synchronized (webTarget) {
   webTarget.request();
}
{code}
 

We have done so for now, and so far (for more than one week) we did not 
encounter the same issue again. Fortunately, the impact is not too severe for 
us. 
 We are currently also looking into your alternative approach ("create client 
per thread"), but fortunately our level of suffering is not too high ;) ... as 
we have the workaround already in place. That's also why I only created the 
ticket here with priority "minor" - we simply would like to give you (all) the 
chance to look into it and - perhaps - improve the quality in this regard.


was (Author: dschmoigl):
{quote}I afraid that we may fix this one but (many?) other may pop up. So yeah, 
could be challenging ...
{quote}
That's one of the reasons why I opened this ticket ;) The more bugs we find 
(and are able to fix) the better.
{quote}Do you have a workaround for the time being? (like create client per 
thread f.e.) Thanks!
{quote}
As described above, it seems a valid approach to "synchronized" around it like
{code:java}
synchronized (webTarget) {
   webTarget.request();
}
{code}
 

We have done so for now, and so far (for more than one week) we did not 
encounter the same issue again. Fortunately, the impact is not too severe for 
us. 
 We are currently also looking into your alternative approach ("create client 
per thread"), but fortunately our level of suffering is not too big ;) ... as 
we have the workaround already in place. That's also why I only created the 
ticket here with priority "minor" - we simply would like to give you (all) the 
chance to look into it and - perhaps - improve the quality in this regard.

> 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)

Reply via email to