You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "William Tam (JIRA)" <ji...@apache.org> on 2009/04/01 03:01:51 UTC

[jira] Commented: (CXF-2145) Proxy in JCA connector throws exception due to concurrency issues

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

William Tam commented on CXF-2145:
----------------------------------

I was wondering whether recycling MessageEndpoint instance is a good idea or not. I went back to the JCA spec. Then, I came to the conclusion that it is NOT a good thing. 

First, Chapter 1.5 Message Delivery in the JCA spec confirms the root problem. "The same endpoint instance may be used again to deliver subsequent messages serially, but it must not use the
same endpoint instance concurrently."

However, it is unnecessary for the resource adapter to pool endpoint instances. It says in the same chapter, "The resource adapter may call the release method on the proxy endpoint instance to indicate that it no longer needs the proxy instance. This hint may be used by the application server for proxy endpoint pooling decisions. This method call frees the state of the proxy instance. The released proxy instance may be reused for further proxy endpoint requests from the same resource adapter." That means, the application server may already maintain a pool of endpoint instances per resource adapter. We should just call the release() method on the endpoint instance and call createEndpoint() when it is needed again. I guess the biggest issue of our pooling is XA transaction support (in the future). Each endpoint could be attached to a different XAResource at creation time.

I think a fix would be to have the MDBInvoker() holding on to a MessageEndpointFactory instead of a MessageEndpoint instance. In the getServiceObject(), it calls createEndpoint() and release() when it is done.

(BTW, it looks like a bug in the patch that the MDBInvoker.getServiceObject() is not recycling endpoint instance.) 

> Proxy in JCA connector throws exception due to concurrency issues
> -----------------------------------------------------------------
>
>                 Key: CXF-2145
>                 URL: https://issues.apache.org/jira/browse/CXF-2145
>             Project: CXF
>          Issue Type: Bug
>          Components: Integration
>    Affects Versions: 2.1, 2.0.6, 2.2
>            Reporter: Seumas Soltysik
>         Attachments: patch.txt
>
>
> A customer is having a problem with concurrent access to a JCA endpoint that is deployed in WebSphere. The stacktrace is below.
> They are running a 2.0.x version of CXF with WebSphere 6.1.0.19, HP/UX version B.11.23, Java 1.5.0.13 .
> The problem is that the JCA connector uses a single MDB/EJB proxy for all threads which is causing the exception to be thrown. The solution is to create a pool of proxies which can be accessed so that the proxy is used by no more than 1 thread at a time.
> [3/10/09 15:55:19:685 EDT] 0000042f DispatchMDBIn E Failed to obtain service object java:comp/env/GreeterWithWsdlLocalHome 
>                                  java.lang.IllegalStateException: Multiple threads can not use same MessageEndpoint proxy instance concurrently 
>             at com.ibm.ejs.container.MessageEndpointHandler.throwIllegalStateException(MessageEndpointHandler.java:599) 
>             at com.ibm.ejs.container.MessageEndpointHandler.checkState(MessageEndpointHandler.java:433) 
>             at com.ibm.ejs.container.MessageEndpointHandler.invokeMdbMethod(MessageEndpointHandler.java:889) 
>             at com.ibm.ejs.container.MessageEndpointHandler.invoke(MessageEndpointHandler.java:747) 
>             at $Proxy50.lookupTargetObject(Unknown Source) 
>             at org.apache.cxf.jca.inbound.DispatchMDBInvoker.getServiceObject(DispatchMDBInvoker.java:57) 
>             at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:51) 
>             at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56) 
>             at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) 
>             at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92) 
>             at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221) 
>             at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:77) 
>             at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:280) 
>             at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:254) 
>             at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) 
>             at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) 
>             at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) 
>             at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) 
>             at org.mortbay.jetty.Server.handle(Server.java:324) 
>             at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) 
>             at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842) 
>             at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648) 
>             at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) 
>             at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) 
>             at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) 
>             at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.