[jboss-jira] [JBoss JIRA] (WFLY-3338) @Inject'ed JMSContext is not thread-safe
Ricardo Ramirez (JIRA)
issues at jboss.org
Wed Aug 5 10:34:04 EDT 2015
[ https://issues.jboss.org/browse/WFLY-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095799#comment-13095799 ]
Ricardo Ramirez commented on WFLY-3338:
---------------------------------------
I have the same issue but using Wildfly 9.0.1. Here is my log:
10:19:05,142 WARN [org.hornetq.core.client] (default task-63) HQ212051: Invalid concurrent session usage. Sessions are not supposed to be used by more than one thread concurrently.: java.lang.Exception: trace
at org.hornetq.core.client.impl.ClientSessionImpl.startCall(ClientSessionImpl.java:1397)
at org.hornetq.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:2137)
at org.hornetq.core.client.impl.ClientSessionImpl.createTemporaryQueue(ClientSessionImpl.java:371)
at org.hornetq.core.client.impl.DelegatingSession.createTemporaryQueue(DelegatingSession.java:323)
at org.hornetq.jms.client.HornetQSession.createTemporaryQueue(HornetQSession.java:932)
at org.hornetq.ra.HornetQRASession.createTemporaryQueue(HornetQRASession.java:1043)
at org.hornetq.jms.client.HornetQJMSContext.createTemporaryQueue(HornetQJMSContext.java:677)
at org.jboss.as.messaging.deployment.JMSContextProducer$JMSContextWrapper.createTemporaryQueue(JMSContextProducer.java:456)
at py.gov.senatics.sii.controller.IdentificacionesBC.processMessage(IdentificacionesBC.java:64)
at py.gov.senatics.sii.controller.IdentificacionesBC.findPersonaByCedula(IdentificacionesBC.java:44)
at py.gov.senatics.sii.controller.IdentificacionesBC$Proxy$_$$_WeldClientProxy.findPersonaByCedula(Unknown Source)
at py.gov.senatics.sii.ws.PersonaWS.obtenerPersonaPorCedula(PersonaWS.java:30)
at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:634)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:135)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:185)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:97)
at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:69)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:151)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:111)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:136)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:212)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
It's appears when i create a temporary queue.
> @Inject'ed JMSContext is not thread-safe
> ----------------------------------------
>
> Key: WFLY-3338
> URL: https://issues.jboss.org/browse/WFLY-3338
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Alpha1
>
>
> Section 12.4.4 of the JMS 2.0 spec says:
> {quote}
> If a method is called on an injected JMSContext when there is a JTA
> transaction (either bean-managed or container-managed), the scope of
> the JMSContext will be @TransactionScoped.
> {quote}
> This is not currently true in WildFly. As a test case, suppose you have the following two beans:
> {code}
> import javax.annotation.Resource;
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.inject.Instance;
> import javax.inject.Inject;
> import javax.jms.JMSContext;
> import javax.jms.Topic;
> import javax.transaction.Transactional;
> @ApplicationScoped
> @Transactional
> public class AppScopedBean {
>
> @Inject
> private JMSContext jmsCtx;
> //private Instance<JMSContext> jmsCtx;
> @Resource(lookup = "jms/topic/test")
> private Topic topic;
>
> public void sendMessage() {
> jmsCtx.createProducer().setDisableMessageID(true).setDisableMessageTimestamp(true).send(topic, "a message");
> //jmsCtx.get().createProducer().setDisableMessageID(true).setDisableMessageTimestamp(true).send(topic, "a message");
> }
> }
> {code}
> {code}
> import javax.annotation.Resource;
> import javax.enterprise.concurrent.ManagedThreadFactory;
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.context.Dependent;
> import javax.enterprise.context.Initialized;
> import javax.enterprise.event.Observes;
> import javax.inject.Inject;
> @Dependent
> public class ThreadLauncher {
> @Resource
> private ManagedThreadFactory threadFactory;
> @Inject
> private AppScopedBean bean;
>
> void start(@Observes @Initialized(ApplicationScoped.class) Object event) {
> System.out.println("starting threads");
> for (int i = 0; i < 5; i++) {
> threadFactory.newThread(new SendRunnable()).start();
> }
> System.out.println("start finished");
> }
>
> private class SendRunnable implements Runnable {
> public void run() {
> System.out.println("starting to send");
> for (int i = 0; i < 100; i++) {
> bean.sendMessage();
> }
> System.out.println("done sending");
> }
>
> }
>
> }
> {code}
> If you deploy and run the above code, you will see a lot of this:
> {quote}
> 2014-05-12 16:46:02,936 WARN [org.hornetq.core.client] (EE-ManagedThreadFactory-default-Thread-4) HQ212051: Invalid concurrent session usage. Sessions are not supposed to be used by more than one thread concurrently.: java.lang.Exception: trace
> {quote}
> That should not be happening if the JMSContext is really @TransactionScoped. The problem appears to be in org.jboss.as.messaging.deployment.JMSContextProducer, specifically the JMSContextWrapper.getDelegate() method. If two threads call it at the same time, the first will create a delegate but the second will receive the same delegate as the first, because the delegate doesn't get nulled until the transaction in the first thread completes.
> This means that both threads are using the same session at the same time, which is not allowed. I don't know how HornetQ detects concurrent use, but depending on how that works, it's also possible that messages will end up being part of the wrong transaction.
> A workaround is to inject Instance<JMSContext> instead of JMSContext directly (the two commented out lines of code). Since the JMSContext producer is @Dependent, each Instance.get() call will return a new instance, and only one thread will ever use any given instance.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
More information about the jboss-jira
mailing list