Closed glassfishrobot closed 15 years ago
@glassfishrobot Commented 1xpert said: Created an attachment (id=2961) sdk build 9.1 (build b58g-fcs)
@glassfishrobot Commented 1xpert said: Created an attachment (id=2962) glassfish v3 (build 53)
@glassfishrobot Commented mvatkina said: Is this issue resolved? I see lookup errors in the log. Please reassign it back to me if there are errors in transaction behavior.
@glassfishrobot Commented 1xpert said: Created an attachment (id=3050) log using 8/3/09 appserver build
@glassfishrobot Commented 1xpert said: reopen issue-- please see current log datestamp 8/3/09 in bug attachment
@glassfishrobot Commented mvatkina said: Requesting jms team to check these errors in the 8/3/09 server.log: [#|2009-08-03T16:00:00.149-0700|SEVERE|glassfish|null|_ThreadID=21;_ThreadName=Thread-2;|com.sun.messaging.jms.JMSException: MQRA:DCF:allocation failure:createConnection:Error in allocating a connection. Cause: MQRA:MC:getConnection-auth failed for Subject-null-subject|#]
[#|2009-08-03T16:00:00.149-0700|SEVERE|glassfish|null|_ThreadID=21;_ThreadName=Thread-2;| at com.sun.messaging.jms.ra.DirectConnectionFactory._allocateConnection(DirectConnectionFactory.java:574)|#]
[#|2009-08-03T16:00:00.150-0700|SEVERE|glassfish|null|_ThreadID=21;_ThreadName=Thread-2;| at com.sun.messaging.jms.ra.DirectConnectionFactory.createQueueConnection(DirectConnectionFactory.java:320)|#]
[#|2009-08-03T16:00:00.150-0700|SEVERE|glassfish|null|_ThreadID=21;_ThreadName=Thread-2;| at transaction.usertransaction.ejb.Util.getQueueConnection(Util.java:164)|#]
@glassfishrobot Commented sats said: I ran these tests on V3 build 68. I don't see any MQ related errors in my logs. [GF and MQ logs attached]
Reassigning back the JTS team...
@glassfishrobot Commented sats said: Created an attachment (id=3514) GF server.log
@glassfishrobot Commented sats said: Created an attachment (id=3515) MQ logs
@glassfishrobot Commented mvatkina said: Did you test the run target? I do not see any test debug messages in the attached log. But I still see these errors: SEVERE: com.sun.messaging.jms.JMSException: MQRA:DCF:allocation failure:createConnection:Error in allocating a connection. Cause: MQRA:MC:getConnection-auth failed for Subject-null-subject at com.sun.messaging.jms.ra.DirectConnectionFactory._allocateConnection(DirectConnectionFactory.java:574) at com.sun.messaging.jms.ra.DirectConnectionFactory.createQueueConnection(DirectConnectionFactory.java:320) at transaction.usertransaction.ejb.Util.getQueueConnection(Util.java:164) at transaction.usertransaction.ejb.Util.sendMessage(Util.java:89) at transaction.usertransaction.ejb.Util.sendMessage(Util.java:54) at transaction.usertransaction.ejb.TestThread.run(TestThread.java:58) Caused by: javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: MQRA:MC:getConnection-auth failed for Subject-null-subject at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:277) at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:175) at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:148) at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:143) at com.sun.messaging.jms.ra.DirectConnectionFactory._allocateConnection(DirectConnectionFactory.java:569) ... 5 more Caused by: com.sun.appserv.connectors.internal.api.PoolingException: MQRA:MC:getConnection-auth failed for Subject-null-subject at com.sun.enterprise.resource.allocator.ConnectorAllocator.fillInResourceObjects(ConnectorAllocator.java:173) at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:416) at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:227) at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:151) at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:306) at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:271) ... 9 more
@glassfishrobot Commented mvatkina said: Created an attachment (id=3558) server.log with connection access errors
@glassfishrobot Commented sats said: I tried running the tests in GF V3 build 71
I had to remove the following line from build.xml for this to work: CS file: /m/jws/appserver-sqe/pe/transaction/usertransaction/build.xml,v retrieving revision 1.7 diff -r1.7 build.xml 111d110 < <env key="APPCPATH" path="$
{s1astest.classpath}
"/>
without which it fails at runappclient-local with the following exception:
[exec] Exception in thread "main" java.lang.reflect.InvocationTargetException [exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [exec] at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) [exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) [exec] at java.lang.reflect.Method.invoke(Method.java:597) [exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent (InstrumentationImpl.java:323) [exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain (InstrumentationImpl.java:338) [exec] Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found [exec] at javax.xml.parsers.SAXParserFactory.newInstance (SAXParserFactory.java:134)
Final test results from the run (post this change): [exec] ----------------------------------------- [exec] - EJB-rollback: PASS - [exec] - Servlet-commit: PASS - [exec] - lifecycle-rollback: PASS - [exec] - Servlet-rollback: PASS - [exec] - appclient-rollback: PASS - [exec] - appclient-commit: PASS - [exec] - lifecycle-commit: PASS - [exec] - EJB-commit: PASS - [exec] ----------------------------------------- [exec] Total PASS: 8 [exec] Total FAIL: 0 [exec] Total DNR: 0 [exec] -----------------------------------------
[java] ----------------------------------------- [java] - standalone-commit: PASS - [java] - interop-tx-supports:setrollbackonly: PASS - [java] - interop-tx-required:commit: FAIL - [java] - standalone-rollback: FAIL - [java] - interop-tx-required:setrollbackonly: PASS - [java] - interop-tx-required:rollback: PASS - [java] - interop-tx-supports:commit: FAIL - [java] - interop-tx-supports:rollback: PASS - [java] ----------------------------------------- [java] Total PASS: 5 [java] Total FAIL: 3 [java] Total DNR: 0 [java] -----------------------------------------
Since interop-tx-required:commit and interop-tx-supports:commit have failed in GF 9.1 as well, the only new test failure is - standalone-rollback.
I don't see any JMS related errors in either the server.log or in mq log. Server.log and test logs are attached.
Reassiging back to Marina...
@glassfishrobot Commented sats said: Created an attachment (id=3732) GF server.log
@glassfishrobot Commented sats said: Created an attachment (id=3733) Test log
@glassfishrobot Commented mvatkina said: Jagadish,
please take a look. I really don't understand how did it work in v2 - it's a stand-alone (non-ACC) client that uses Utx. There are no resource enlistment calls (current inv is null), and if I just try to do in my own test case DS lookup, getConnection, insert, and utx.rollback, the insert succeeds. But with this test it doesn't and after rollback the row isn't found.
@glassfishrobot Commented @h2002044 said: The issue seems to be due to transactionManager not returning a transaction when there is a call to "tm.getTransaction()" even after the standalone client has started the user-transaction.
Please refer : connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/rm/SystemResourceManager#enlistResource() : Line 95
which returns null for tm.getTransaction().
In v2, this returns a transaction and hence resources are enlisted.
Currently, there is a bug in connector runtime which uses ResourceManager instead of SystemResourceManager. I shall provide a patch via email for you to test it once you have the fix for tm.getTransaction() returning null.
Also, in v2 :
There is a piece of code that initializes transaction-manager
Switch sw = Switch.getSwitch(); if (sw.getContainerType() == ConnectorConstants.NON_ACC_CLIENT) { //Invocation from a non-ACC client try { // Initialize Transaction service. By now the ORB must have // been created during the new InitialContext() call using // the ORBManager PEORBConfigurator.initTransactionService(null, new Properties() );
if (sw.getTransactionManager() == null)
{ sw.setTransactionManager(new J2EETransactionManagerOpt()); }
// There wont be any invocation manager. So, treat this as a system // resource. jndiName = ResourceInstaller.getPMJndiName(jndiName); } catch(Exception e)
{ throw (ConnectorRuntimeException) new ConnectorRuntimeException(e.getMessage()).initCause(e); }
I do not expect this need to be done by connector container for v3 as it is possible to inject TransactionManager in standalone client mode, Switch class is not available any more and PEORBConfigurator does not have "initTransactionService" any more.
I would expect this to be an initialization issue for transaction-manager. Transerring to Marina for investigation.
@glassfishrobot Commented @h2002044 said: Provided the fix w.r.t connector-runtime so that the behavior is same as v2. ie., use SystemResourceManager when the runtime is "non-acc"
https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=16331
svn log -v -r 33799
@glassfishrobot Commented mvatkina said: Nothing is actually wrong with the transaction code - the error is caused by issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=10822 which creates 2 different TM instances - one for the user (with transactions) and another one for the connector (without).
I verified that all 8 tests pass (all 8 pass for me on v2.1.1 as well) when I tweaked the StaticModuleRegistry, to return the same habitat from the createHabitat().
marking this bug as fixed. Please reopen if the test still fails when 10822 is fixed
@glassfishrobot Commented 1xpert said: Tests start failing again in glassfish promoted build 73
@glassfishrobot Commented 1xpert said: Sorry updating wrong issue. Please help change it to RESOLVED status.
@glassfishrobot Commented 1xpert said: reassign to myself to close it
@glassfishrobot Commented mvatkina said: ...
@glassfishrobot Commented File: glassfish_usertx.log Attached By: 1xpert
@glassfishrobot Commented File: log.txt Attached By: sats
@glassfishrobot Commented File: sdk_usertx.log Attached By: 1xpert
@glassfishrobot Commented File: server.log Attached By: sats
@glassfishrobot Commented File: server.log Attached By: mvatkina
@glassfishrobot Commented File: server.log Attached By: sats
@glassfishrobot Commented File: server.log Attached By: 1xpert
@glassfishrobot Commented File: test3.txt Attached By: sats
Using glassfish v3 build b53 . Tests failed in glassfish are Servlet-commit: FAIL Servlet-rollback: FAIL interop-tx-required:commit: FAIL standalone-rollback: FAIL interop-tx-supports:commit: FAIL
The above tests passed in sdk build 9.1 b58g except for interop-tx-required:commit: FAIL interop-tx-supports:commit: FAIL
Test Case details:
Test description:
test commit , rollback, setRollbackonly operation involving jdbc XA resoure and jms resource
Test location:appserver-sqe/pe/transaction/usertransaction
Test logs: see glassfish_usertx.log, sdk_usertx.log
Environment
Operating System: All Platform: Sun
Affected Versions
[V3]