[JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script
by Mark Little (JIRA)
Mark Little created JBTM-2262:
---------------------------------
Summary: ORB JTS classes not added to classpath in setup script
Key: JBTM-2262
URL: https://issues.jboss.org/browse/JBTM-2262
Project: JBoss Transaction Manager
Issue Type: Task
Components: JTS
Affects Versions: 5.0.3
Reporter: Mark Little
Assignee: Tom Jenkinson
Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2261) start services scripts missing execute flag
by Mark Little (JIRA)
Mark Little created JBTM-2261:
---------------------------------
Summary: start services scripts missing execute flag
Key: JBTM-2261
URL: https://issues.jboss.org/browse/JBTM-2261
Project: JBoss Transaction Manager
Issue Type: Task
Components: JTS
Affects Versions: 5.0.3
Reporter: Mark Little
Assignee: Tom Jenkinson
Priority: Minor
Unix start transaction manager and recovery service scripts in bin directory are missing the execute bit.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2259:
-----------------------------------
OK, but this is not compliant with the standards and therefore if some other transaction engine is used it will break. The reason ordering of resources and synchronisations isn't supported in the standards is because it becomes very hard to manage global ordering in a heterogenous environment. Are we really happy to add something which basically ties IronJacamar and Narayana together? I'm no so sure. While it's nice to add something like resource ordering, as we do with AbstractRecords, it should be done cautiously, in situations where no other option is possible, or as an optimisation, i.e., so without it the system still works, but may be slower, less efficient etc.
> Allow the ordering of some synchronizations to be configurable
> ---------------------------------------------------------------
>
> Key: JBTM-2259
> URL: https://issues.jboss.org/browse/JBTM-2259
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
>
> IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA).
> The request is to add a configuration option to control the order in which certain synchronizations are called.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2260:
-----------------------------------
Summary: BlackTie does not build on CentOS 7
Key: JBTM-2260
URL: https://issues.jboss.org/browse/JBTM-2260
Project: JBoss Transaction Manager
Issue Type: Bug
Components: BlackTie
Reporter: Tom Jenkinson
Assignee: Amos Feng
Fix For: 5.0.4
[hudson@sansa ~]$ uname -a
Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/D...
{quote}
test-compile:
[mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes
[copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes
[cc] 11 total files to be compiled.
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ‘virtual void TestAtmiBrokerXml::tearDown()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION_DIR=.");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION=");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ‘void TestAtmiBrokerXml::test_env()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION=xmltest");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ‘void TestAtmiBrokerXml::test_define_adminservice()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ‘void TestAtmiBrokerXml::test_same_service()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ‘void TestAtmiBrokerXml::test_invalid_xml()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ‘void TestAtmiBrokerXml::test_no_config()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ‘virtual void TestSymbolLoader::setUp()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION=linux");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ‘virtual void TestSymbolLoader::tearDown()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
[cc] putenv("BLACKTIE_CONFIGURATION=");
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ‘void* activateWaiter(apr_thread_t*, void*)’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ‘ret’ [-Wunused-variable]
[cc] int ret = waiter->svc();
[cc] ^
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ‘virtual void TestSynchronizableObject::setUp()’:
[cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ‘argc’ [-Wunused-variable]
[cc] int argc = 0;
[cc] ^
[cc] Starting link
[cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register'
[cc] collect2: error: ld returned 1 exit status
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2259:
-------------------------------------
The case that is discussed on the forum is where two synchronizations both registered as interposed need to have ordering imposed between them. The two Synchronizations are from IronJacamar and a JPA persistence provider. When the JCA one runs, it closes the underlying connection and so if it happens to have been registered first it will close the connection before JPA flushes.
> Allow the ordering of some synchronizations to be configurable
> ---------------------------------------------------------------
>
> Key: JBTM-2259
> URL: https://issues.jboss.org/browse/JBTM-2259
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
>
> IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA).
> The request is to add a configuration option to control the order in which certain synchronizations are called.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-2255:
----------------------------------
Fix Version/s: 5.0.4
> Do not return StatusCommiting, if transaction was commited by the original transaction manager
> ----------------------------------------------------------------------------------------------
>
> Key: JBTM-2255
> URL: https://issues.jboss.org/browse/JBTM-2255
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 4.17.23, 5.0.4
>
>
> We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing.
> However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-2259:
-----------------------------------
One of the reasons we haven't done this to date is that it's not standards compliant. Why isn't the ordering that JTA allowed in the interposed option sufficient?
> Allow the ordering of some synchronizations to be configurable
> ---------------------------------------------------------------
>
> Key: JBTM-2259
> URL: https://issues.jboss.org/browse/JBTM-2259
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA
> Affects Versions: 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
>
> IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA).
> The request is to add a configuration option to control the order in which certain synchronizations are called.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (JBTM-2216) Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2216?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2216:
--------------------------------
Fix Version/s: 4.17.23
> Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2216
> URL: https://issues.jboss.org/browse/JBTM-2216
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 4.17.20, 4.17.21, 5.0.2
> Environment: JBoss EAP 6.3
> Reporter: Tom Ross
> Assignee: Tom Jenkinson
> Fix For: 4.17.23, 5.0.4
>
>
> When using AMQ failover protocol, the Narayana recovery process generates the following exception:
> {noformat}
> 10:19:36,053 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true
> 10:21:46,139 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true
> 10:21:46,139 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Failover transport not connected: unconnected
> at org.apache.activemq.TransactionContext.recover(TransactionContext.java:656)
> at org.apache.activemq.ra.LocalAndXATransaction.recover(LocalAndXATransaction.java:135)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.recover(XAResourceWrapperImpl.java:177)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:548) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:187) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> 10:21:56,165 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:619) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1]
> {noformat}
> Although the first message may be expected if the resource manager throws an exception in XAResource::recover(), the second message does not add any further assistance in resolving the issue and should be removed as noise.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months