[JBoss JIRA] (JBTM-960) Change "ARJUNA12140: Adding multiple last resources is disallowed" warning and show underlying resource instead of LastResourceRecord
by Scott Marlow (Created) (JIRA)
Change "ARJUNA12140: Adding multiple last resources is disallowed" warning and show underlying resource instead of LastResourceRecord
-------------------------------------------------------------------------------------------------------------------------------------
Key: JBTM-960
URL: https://issues.jboss.org/browse/JBTM-960
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: 4.15.3
Reporter: Scott Marlow
Assignee: Jonathan Halliday
As discussed on IRC, change the ARJUNA12140 warning from the current:
"
ARJUNA12140: Adding multiple last resources is disallowed. Current resource is com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord@xxxxx
"
To:
"
Enlisting multiple non-XA resources into transaction is not allowed. Tried to enlist resource %s when resource %s is already enlisted.
"
Instead of showing the LastResourceRecord, it would help reduce the time it takes to locate the root cause, if we showed the underlying resources in the warning message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBTM-924) recovery leaks xaresources
by Jonathan Halliday (Created) (JIRA)
recovery leaks xaresources
--------------------------
Key: JBTM-924
URL: https://issues.jboss.org/browse/JBTM-924
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Recovery
Affects Versions: 5.0.0.M1, 4.15.3, 4.6.1.CP12
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.6.1.CP13, 4.15.4, 5.0.0.M2
XARecoveryModule._xidScans may grow without limit in cases where an xa recovery plugin is both a) returning new XAResources rather than validiating and reusing the previous one and b) the isSameRM implementation provided by the driver is unable to recognize the equivalence of two such XAResources.
To prevent such leakage we should remove any scan entries that have not been updated recently, thus ensuring expiration of entries that are not refreshed by the refreshXidScansForEquivalentXAResourceImpl correlation mechanism.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBTM-918) TXBridge Demo: SynchronizationImple.afterCompletion failed due to IllegalStateException
by Paul Robinson (Created) (JIRA)
TXBridge Demo: SynchronizationImple.afterCompletion failed due to IllegalStateException
---------------------------------------------------------------------------------------
Key: JBTM-918
URL: https://issues.jboss.org/browse/JBTM-918
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.15.3
Environment: AS 7 master @ 2011-10-06 15:00:00
Reporter: Paul Robinson
Fix For: 4.15.4, 5.0.0.M2
To reproduce:
1. Deploy TXBridge demo client and service
2. Visit: http://localhost:8080/txbridge-demo-client/
3. Click "Submit Booking"
Observe:
{code}
14:58:12,899 WARN [com.arjuna.ats.jta] (TaskWorker-3) ARJUNA16029: SynchronizationImple.afterCompletion - failed for org.jboss.as.jpa.transaction.TransactionUtil$SessionSynchronization@259f1b1d with exception: java.lang.IllegalStateException
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple.getTransactionImple(TransactionSynchronizationRegistryImple.java:225) [jbossjts-4.15.3.Final.jar:]
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple.putResource(TransactionSynchronizationRegistryImple.java:103) [jbossjts-4.15.3.Final.jar:]
at org.jboss.as.jpa.transaction.TransactionUtil.putEntityManagerInTransactionRegistry(TransactionUtil.java:195)
at org.jboss.as.jpa.transaction.TransactionUtil.access$100(TransactionUtil.java:48)
at org.jboss.as.jpa.transaction.TransactionUtil$SessionSynchronization.afterCompletion(TransactionUtil.java:220)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:117) [jbossjts-4.15.3.Final.jar:]
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:403) [jbossjts-4.15.3.Final.jar:]
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:335) [jbossjts-4.15.3.Final.jar:]
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.SubordinateAtomicAction.doCommit(SubordinateAtomicAction.java:176) [jbossjts-4.15.3.Final.jar:]
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple.doCommit(TransactionImple.java:158) [jbossjts-4.15.3.Final.jar:]
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:87) [jbossjts-4.15.3.Final.jar:]
at org.jboss.jbossts.txbridge.inbound.BridgeDurableParticipant.commit(BridgeDurableParticipant.java:204) [jbosstxbridge-4.15.3.Final.jar:]
at com.arjuna.wst11.messaging.engines.ParticipantEngine.executeCommit(ParticipantEngine.java:577) [jbossxts-4.15.3.Final.jar:]
at com.arjuna.wst11.messaging.engines.ParticipantEngine.commit(ParticipantEngine.java:149) [jbossxts-4.15.3.Final.jar:]
at com.arjuna.wst11.messaging.ParticipantProcessorImpl.commit(ParticipantProcessorImpl.java:99) [jbossxts-4.15.3.Final.jar:]
at com.arjuna.webservices11.wsat.sei.ParticipantPortTypeImpl$2.executeTask(ParticipantPortTypeImpl.java:84) [jbossxts-4.15.3.Final.jar:]
at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:63) [jbossxts-4.15.3.Final.jar:]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]
{code}
Full server.log is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBTM-920) remove PropertyPrefix requirement for EnvironmentBean classes
by Jonathan Halliday (Created) (JIRA)
remove PropertyPrefix requirement for EnvironmentBean classes
-------------------------------------------------------------
Key: JBTM-920
URL: https://issues.jboss.org/browse/JBTM-920
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Common, Configuration
Affects Versions: 5.0.0.M1, 4.15.3
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.15.4, 5.0.0.M2
BeanPopulator enforces the requirement that EnvironmentBean classes have a PropertyPrefix annotation, in order to ensure that all properties existing prior to beanification still function using their legacy representation post-beanification. However, this requirement is too stringent - new properties added in the post-beanification era neither have, nor should be required to have, a legacy representation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBTM-770) incorrect cleanup registration causes memory leak
by Jonathan Halliday (JIRA)
incorrect cleanup registration causes memory leak
-------------------------------------------------
Key: JBTM-770
URL: https://jira.jboss.org/browse/JBTM-770
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTS
Affects Versions: 4.6.1.CP06, 4.12.0
Reporter: Jonathan Halliday
Assignee: Mark Little
Fix For: 4.13.0, 4.6.1.CP08
jts.TransactionImple constructors attempt to optimize the cleanup callback needed to remove entries from _transactions, bypassing the ORB for interposition scenarios:
theTx = (TwoPhaseCoordinator) BasicAction.Current();
if (theTx != null) {
theTx.addSynchronization(new LocalCleanupSynchronization(this));
} else {
registerSynchronization(new CleanupSynchronization(this));
}
Unfortunately this does not work and leads to memory leaks on _transactions in certain cases. Specifically, where theTx is a ServerTransaction (i.e. extends ArjunaTransactionImple, which extends TwoPhaseCoordinator), the callbacks run (by ArjunaTransactionImple.do[Before|After]Completion()) are those in ArjunaTransactionImple._syncs, not the masked ones in TwoPhaseCoordinator._syncs. Thus using TwoPhaseCoordinator.addSynchronization registers a callback which is never invoked.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBTM-852) Setting SettingVolatile store still creates an ObjectStore directory on the disk
by Mircea Markus (JIRA)
Setting SettingVolatile store still creates an ObjectStore directory on the disk
---------------------------------------------------------------------------------
Key: JBTM-852
URL: https://issues.jboss.org/browse/JBTM-852
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.15.0
Reporter: Mircea Markus
Priority: Minor
Even when configuring {code:java} arjPropertyManager.getObjectStoreEnvironmentBean().setObjectStoreType(VolatileStore.class.getName()) {code} an "ObjectStore" directory is created on the disk. After discussing with JTM team this doesn't cause any real problem in the sense that nothing is written to the disk, but this is annoying and might create confusion between the users.
A workaround would be to add the following configuration together with the previously mentioned one:
{code:java} BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "communicationStore").setObjectStoreType(VolatileStore.class.getName()) {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBTM-847) Look into how AssumedComplete works for ArjunaJTA (and jtax)
by Mark Little (JIRA)
Look into how AssumedComplete works for ArjunaJTA (and jtax)
------------------------------------------------------------
Key: JBTM-847
URL: https://issues.jboss.org/browse/JBTM-847
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: JTA
Reporter: Mark Little
Assignee: Tom Jenkinson
When a transaction cannot be completed over a long period of time, a scanner is supposed to kick in and move the log elsewhere. Those scanners exist in ArjunaCore and ArjunaJTS, but do not appear to be there in ArjunaJTA. It should be straightforward to add them by using the base class in ArjunaCore, but investigate whether they are present already and just not obvious.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month