[
https://issues.apache.org/jira/browse/CXF-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694336#action_12694336
]
William Tam edited comment on CXF-2145 at 3/31/09 7:41 PM:
-----------------------------------------------------------
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 12.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
DispatchMDBInvoker.releaseServiceObject() method should've been overridden to
do nothing.)
was (Author: wtam):
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 12.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.
> 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.
