[JBoss JIRA] (JBTM-1695) Change the 'common' module to use the normal maven convention for source layout.
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1695?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1695:
-------------------------------------
The problem is that it isn't just the 'common' module, so it will be quite an invasive change to the build structure. For now, I think it best to defer (rather than reject) this if you don't object:
[tom@localhost narayana](JBTM-1702) $ find . -name \tests | grep -v "target\|jboss-as\|src/test\|build\|classes"
./ArjunaJTA/jta/tests
./ArjunaJTA/jdbc/tests
./common/tests
./common/tests/com/arjuna/common/tests
./qa/tests
./ArjunaCore/arjuna/tests
./ArjunaCore/txoj/tests
./ArjunaJTS/jts/tests
./ArjunaJTS/orbportability/tests
./ArjunaJTS/jtax/tests
> Change the 'common' module to use the normal maven convention for source layout.
> --------------------------------------------------------------------------------
>
> Key: JBTM-1695
> URL: https://issues.jboss.org/browse/JBTM-1695
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 4.17.4
> Reporter: Weinan Li
> Assignee: Weinan Li
> Priority: Minor
>
> The common module doesn't use the normal maven convention for source layout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBTM-1683) btadmin tests on windows failed with "Could not start the server"
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1683?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1683:
--------------------------------
Fix Version/s: 5.0.0.Final
(was: 5.0.0.M3)
> btadmin tests on windows failed with "Could not start the server"
> -----------------------------------------------------------------
>
> Key: JBTM-1683
> URL: https://issues.jboss.org/browse/JBTM-1683
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
>
> http://172.17.131.2/job/blacktie-windows2008-taconic/272
> {code}
> Failed tests:
> testResumeResumeDomain(org.jboss.narayana.blacktie.btadmin.ResumeDomainTest): Command was not successful
> testResumeDomainWithArg(org.jboss.narayana.blacktie.btadmin.ResumeDomainTest): Could not start the server
> testShutdownWithId(org.jboss.narayana.blacktie.btadmin.ShutdownTest): Could not start the server
> testShutdownWithoutId(org.jboss.narayana.blacktie.btadmin.ShutdownTest): Could not start the server
> testShutdownWithInvalidId(org.jboss.narayana.blacktie.btadmin.ShutdownTest): Could not start the server
> testStartup(org.jboss.narayana.blacktie.btadmin.StartupTest): Command was unsuccessful
> testUnadvertiseWithoutServer(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testUnadvertiseNoArgs(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testAdvertiseNotAdvertised(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testUnadvertise(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> testUnadvertiseWithoutService(org.jboss.narayana.blacktie.btadmin.UnadvertiseTest): Could not start the server
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBTM-1482) If a naughty afterCompletion sync throws an exception, log the exception call stack
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1482?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1482:
----------------------------------
Fix Version/s: 5.0.0.M4
(was: 5.0.0.M3)
> If a naughty afterCompletion sync throws an exception, log the exception call stack
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1482
> URL: https://issues.jboss.org/browse/JBTM-1482
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Scott Marlow
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> Currently, when this happens with AS, I see:
> {quote}
> 2013-02-18 16:24:43,837|WARN |[com.arjuna.ats.jta]|(ThreadId: Transaction Reaper Worker 221)|ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.jboss.as.jpa.transaction.TransactionUtil$SessionSynchronization@634ef5a7 with exception: java.lang.NullPointerException
> {quote}
> From a related email conversation:
> {quote}
> Here's our Logger code:
> @Message(id = 16029, value = "SynchronizationImple.afterCompletion - failed for {0} with exception", format = MESSAGE_FORMAT)
> @LogMessage(level = WARN)
> public void warn_resources_arjunacore_SynchronizationImple(String arg0, @Cause() Throwable arg1);
> Here is where we call our logger:
> jtaLogger.i18NLogger.warn_resources_arjunacore_SynchronizationImple(_theSynch.toString(), e);
> Maybe the message should have the {1} in it, i.e. it change it like so:
> "SynchronizationImple.afterCompletion - failed for {0} with exception {1}"
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBTM-1505) WS-BA transaction context not propagated if JTA transaction present.
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1505?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1505:
----------------------------------
Original Estimate: 2 hours (was: 1 day)
Remaining Estimate: 2 hours (was: 1 day)
> WS-BA transaction context not propagated if JTA transaction present.
> --------------------------------------------------------------------
>
> Key: JBTM-1505
> URL: https://issues.jboss.org/browse/JBTM-1505
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TxBridge, XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> With default-context-propagation enabled:
> What happens if the Client is running in a JTA transaction, then begins a WS-BA transaction before calling a WS-BA enabled service? I suspect, as it stands, we would start a WS-AT transaction as well. This will cause the JaxBaseHeaderContextProcessor to default to WS-AT as it appears first in the if-then-elseif block:
> {code}
> final CoordinationContextType coordinationContext ;
> if (atContext != null)
> {
> coordinationContext = atContext.getCoordinationContext() ;
> }
> else if (baContext != null)
> {
> coordinationContext = baContext.getCoordinationContext() ;
> }
> {code}
> I'm not yet sure how we handle this case. We certainly need a test for it though.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1479:
----------------------------------
Fix Version/s: 5.0.0.M4
(was: 5.0.0.M3)
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M4
>
> Attachments: test-ds.xml, transaction.xml
>
> Original Estimate: 3 days
> Time Spent: 1 week, 1 day, 3 hours, 20 minutes
> Remaining Estimate: 0 minutes
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Christian von Kutzleben (JIRA)
Christian von Kutzleben created JBTM-1702:
---------------------------------------------
Summary: one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
Key: JBTM-1702
URL: https://issues.jboss.org/browse/JBTM-1702
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transaction Core
Affects Versions: 5.0.0.M2
Reporter: Christian von Kutzleben
Assignee: Tom Jenkinson
We provide our own XAResource implementation for our database product,
in our unit testsuite we do also test common error conditions.
The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
This error occurs if and only if the one-phase optimization is used, i.e. if
exactly one XAResource instance is enlisted with the TransactionManager.
If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
The broken logic is contained in here (also see a complete stack trace below):
com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months
[JBoss JIRA] (JBTM-1697) AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1697?page=com.atlassian.jira.plugin.... ]
Amos Feng updated JBTM-1697:
----------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> AdvertiseUnadvertiseTest failed with could not deploy queue of .testsui1
> -------------------------------------------------------------------------
>
> Key: JBTM-1697
> URL: https://issues.jboss.org/browse/JBTM-1697
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.0.0.M3
>
>
> http://172.17.131.2/job/blacktie-linux64-el5/1528/
> {noformat}
> 06:38:31,520 INFO [AdvertiseUnadvertiseTest] (default task-2) Got the exception
> 06:38:31,872 ERROR [org.jboss.remoting.remote.connection] (Remoting "beacon:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856
> 06:38:32,400 INFO [org.hornetq.ra] (default-threads - 1) HQ151001: Attempting to reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@2c717166 destination=queue/BTR_BTStompAdmin destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)
> 06:38:36,876 ERROR [org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService] (default task-2) Could not deploy queue of .testsui1: java.io.IOException: java.net.ConnectException:
> JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 12 months