cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Liu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-3800) ClientImpl reuse ResponseContext cause ConcurrentModificationException
Date Tue, 13 Sep 2011 00:57:08 GMT

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

David Liu commented on CXF-3800:
--------------------------------

Hi Dan,
  currently, I am using CXF 2.2.10, so I encounter this issue.
  
  I think I will move to CXF 2.4.x soon, but for the moment, do you think if I create a new
Hashmp for ResponseContext can resolve the issue? 
 e.g. 
{code}
  Map<String, Object> resp = new Map<String, Object>();
{code}

David

> ClientImpl reuse ResponseContext cause ConcurrentModificationException
> ----------------------------------------------------------------------
>
>                 Key: CXF-3800
>                 URL: https://issues.apache.org/jira/browse/CXF-3800
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>            Reporter: David Liu
>            Assignee: Daniel Kulp
>            Priority: Critical
>             Fix For: NeedMoreInfo
>
>
> In org.apache.cxf.endpoint.ClientImpl.invoke() method, it reuses the existing ResponseContext
of current thread from its WeakHashMap. It can cause the ConcurrentModificationException if
the proxy client use an Executor to execute an asyc request.
> Thread 1. We call the async request method of generated proxy client, it will call JaxWsClientProxy.invokeAsync(),
and it will get the previous ResponseContext of current thread and clear it and reuse it in
ClientImpl.
> {code}
> ClientImpl:
>   if (context == null) {
>      context = new HashMap<String, Object>();
>      Map<String, Object> resp = getResponseContext();
>      resp.clear();
> {code}
> Thread 2, When CXF got the response from the server, it will use a background thread
to process the response, and also it will get the ResponseContext and process the response
in ClientImpl
> {code}
> ClientImpl.onMessage(){
>  message.getExchange().setInMessage(message);
>  Map<String, Object> resCtx = CastUtils.cast((Map<?, ?>)message.getExchange().getOutMessage().get(Message.INVOCATION_CONTEXT));
>      // *** Get Response context which could be clean by Thread1 ***
>       resCtx = CastUtils.cast((Map<?, ?>)resCtx.get(RESPONSE_CONTEXT)); 
>       try {
>         Object obj[] = processResult(message, message.getExchange(),null, resCtx);
> }
> {code}
> Since the ResponseContext in Thread 2 could be clean by the Thread 1 during processing
the response message, so it could cause ConcurrentModificationException, or it can cause data
error.
>   Could you please fix it by creating a new ResponseContext for the new request? thanks.
> David

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message