Bug 1033008 - Generic JMS RA is not consistent with the EE spec - it does *not* ignore the parameters when session is created in the transaction context
Generic JMS RA is not consistent with the EE spec - it does *not* ignore the ...
Status: CLOSED WONTFIX
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JMS (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity high
: GA
: EAP 6.4.0
Assigned To: Jeff Mesnil
Ondrej Chaloupka
Russell Dickenson
:
Depends On: 1080668 1082617 1090769
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-21 07:01 EST by Ondrej Chaloupka
Modified: 2015-03-31 08:54 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
This release of JBoss EAP 6 carries the following issue in the JMS component. When a session is created in a transaction's context and parameters are passed to the generic JMS resource adapter, a `NullPointerException` (NPE) occurs. The issue occurs because the processing of parameters is attempted, when the Java EE specification states that they are *not* to be processed. The root cause of the issue is under investigation, but until then a workaround is to set the session to be transacted, as per the following example. With this workaround, the NPE will not occur. ---- connection.createSession(true, Session.SESSION_TRANSACTED); ----
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-29 09:48:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
server.log from reproducer (71.48 KB, text/x-log)
2014-05-06 07:26 EDT, Ondrej Chaloupka
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-3159 Major Resolved upgrade Generic JMS RA to 1.0.3.Final 2017-08-24 03:26 EDT

  None (edit)
Description Ondrej Chaloupka 2013-11-21 07:01:26 EST
When you try to set transaction timeout and not used the default one you will get NullPointer exception [1].
In my case I used the jboss @TransactionTimeout annotation to do so.

This problem cames with EAP 6.2.0.CR1. The bug was not involved in the 6.2.0.ER7 release.

[1]
ERROR [stderr] (http-/127.0.0.1:8080-1) java.lang.NullPointerException
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.setTransactionTimeout(XAResourceWrapperImpl.java:194)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:611)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:647)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:305)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.resource.adapter.jms.JmsSessionFactoryImpl.allocateConnection(JmsSessionFactoryImpl.java:345)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.resource.adapter.jms.JmsSessionFactoryImpl.createSession(JmsSessionFactoryImpl.java:327)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.qa.test.nottransactional.JMSTXBean.consumeMesage(JMSTXBean.java:92)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at java.lang.reflect.Method.invoke(Method.java:606)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:272)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.qa.test.nottransactional.JMSTXBean$$$view2.consumeMesage(Unknown Source)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.qa.test.nottransactional.JMSServlet.doGet(JMSServlet.java:57)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920)
ERROR [stderr] (http-/127.0.0.1:8080-1)  at java.lang.Thread.run(Thread.java:744)
Comment 2 Jeff Mesnil 2013-11-29 09:46:04 EST
Does the NPE occurs if you create the session in JMSTXBean with:

Session session = connection.createSession(true, Session.TRANSACTED);

From Managing Distributed Transactions in JavaEE6 tutorial[1]:

> When you create a session in an enterprise bean, the container ignores the arguments
> you specify, because it manages all transactional properties for enterprise beans. It
> is still a good idea to specify arguments of true and 0 to the createSession method
> to make this situation clear:
> 
> session = connection.createSession(true, 0);
> When you use container-managed transactions, you normally use the Required
> transaction attribute (the default) for your enterprise bean’s business methods.

The generic JMS RA does *not* ignore the parameters (while it should).

[1] http://docs.oracle.com/javaee/6/tutorial/doc/bncgl.html
Comment 3 Ondrej Chaloupka 2013-11-29 10:27:27 EST
Hi Jeff,

yes, you're right. In all my tests I haven't set the session for being transacted and I counted with the EE spec. That was a bit pity and I didn't realized this option. I've tested this problem in three different scenarios and in all of them the session was created as non-transcacted from different reasons.

I'm going to fix the name of the issue and change the doc text to be consistent with your comment above.

Thanks
Ondra
Comment 4 Jeff Mesnil 2013-11-29 10:55:45 EST
The NPE was introduced with https://bugzilla.redhat.com/show_bug.cgi?id=1002518 to allow non-transacted consumers to work with XA connection factories.

If we want to support this use case, we have to be ready to take into account the createSession() parameters.

Note that if the user follow the Java EE recommendations to use createSession(true, Session.TRANSACTED) in a EE container, the NPE will not occur as the session will effectively be transacted and the XAResource created.
Comment 5 Ondrej Chaloupka 2013-11-29 11:06:13 EST
Ok, I see. Thank you for the explanation. This issues is here mainly for the problem being documented in the release notes.
Comment 6 Ondrej Chaloupka 2014-03-18 10:49:27 EDT
Hi Jeff,

can I ask what is current status of this issue for EAP 6.3.0?

Thank you
Ondra
Comment 7 Jeff Mesnil 2014-03-18 13:39:57 EDT
This issue is in direct conflict with https://bugzilla.redhat.com/show_bug.cgi?id=1002518 that was introduced to be able to use a RA's connection factory from an external client in the TCK6.

We have either to fix this issue and change the way our TCK6 setup is done or keep it as it is.

Given that the EE spec recommends to use createSession(true, 0), I'd keep it the code that way as the bug would only be exposed if the user does not conform to the EE spec recommendation.
Comment 8 Miroslav Novak 2014-03-19 10:05:21 EDT
Hi Jeff,

I found some reading [1] which explains how craeteSession(..,...) should behave in Java EE in transaction or in unspecified transaction context. What's important from [1]:

a) In a Java EE transaction there are no options: the session is part of a transaction managed by the container and the application has no choice on the matter.

b) In a Java EE unspecified transaction context there are two options:
        non-transacted session with auto-acknowledgement
        non-transacted session with dups-ok-acknowledgement

The a) thing is specified in EJB 3.1 Specification, section 13.3.5 "use of JMS APIs in Transactions":
"Because the container manages the transactional enlistment of JMS sessions on behalf of a bean, the parameters of the createSession(boolean transacted, int acknowledgeMode) method createQueueSession... are ignored."

Base on this we should fix this bz. Probably the only way how to find out that call createSession is inside transaction is to check that managed connection is associated with XAResource and someone called start() on this XAResource.

What do you think?

Mirek

[1] https://java.net/jira/browse/JMS_SPEC-45
Comment 11 Ondrej Chaloupka 2014-04-17 07:07:11 EDT
Verification is blocked by inconsistency in JCA (generic adapter is not starting at all): https://bugzilla.redhat.com/show_bug.cgi?id=1085243
Moving verification to ER2 where the problem should be fixed.
Comment 12 Miroslav Novak 2014-04-28 04:08:55 EDT
This issue cannot be verified in EAP 6.3.0.ER2. Verification is blocked by bz#1090769.
Comment 13 Ondrej Chaloupka 2014-05-06 07:26:12 EDT
Created attachment 892846 [details]
server.log from reproducer
Comment 14 Ondrej Chaloupka 2014-05-06 07:28:34 EDT
Hi Jeff,

I've tried the EAP 6.3.0.ER3 and when I set the session in way:
Session session = connection.createSession(false, 2);

I still get the mentioned NPE. I've added the server.log for you to see the whole stack trace.

As the trouble still exists I'm returning the bz back to you.

Ondra
Comment 15 Jeff Mesnil 2014-05-07 04:29:59 EDT
The behavior of createSession parameters were clarified in JMS 2.0 (and Java EE7).

However, the Generic JMS RA is using JMS 1.1 and is tested against the TCK for Java EE6.
We reverted this fix to make sure the TCK was passing *and* be able to use XA connection for non-transacted sessions.
This means that the generic JMS RA could throw a NPE if the parameters to createSession() conflicts with the transacted status.

At this point, I'm not sure this specific issue can be properly fixed. I'd advise to make sure that in the tests the createSession parameters correspond to the transacted status.

In any case, that'd be likely an error to use both @Transacted and specify non-transacted JMS session with createSession(false, ...).
Comment 17 Ondrej Chaloupka 2014-10-29 09:48:38 EDT
I'm closing this bz as won't fix.

This is based on Jeff's comment #15.
User should follow Java EE7 recommendation. The behaviour of generic RA will be documented in release notes (as it was in 6.3) for 6.4 as special doc bz.

Note You need to log in before you can comment on or make changes to this bug.