[JBoss JIRA] Created: (JBTM-837) Transaction deadlock when NoSuchElementException is thrown from AsyncStore.doWork()
by Tom Waterhouse (JIRA)
Transaction deadlock when NoSuchElementException is thrown from AsyncStore.doWork()
-----------------------------------------------------------------------------------
Key: JBTM-837
URL: https://issues.jboss.org/browse/JBTM-837
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.14.0
Environment: Ubuntu 64-bit Linux/JBoss JTA 4.14.0/Hibernate 3.6.1/Infinispan 3.4.0.CR2/Spring 3.0.5/MySQL 5.1
Reporter: Tom Waterhouse
Attachments: arjuna-deadlock-trace.txt, default-jbossts-properties.xml
Our product has a scheduled job that runs every 30 minutes. Callable instances are added to an ExecutorService instance which is currently configured for 16 threads.
Our JBoss JTA implementation is using CacheStore as the object store (default-jbossts-properties.xml attached).
After some time a NoSuchElementException is thrown from AsyncStore.doWork(). That exception is somehow blocking other transaction thread's execution.
The Java thread dump is attached as well.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBTM-1020) Consider usings a tool for finding common bugs
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1020:
-----------------------------------
Summary: Consider usings a tool for finding common bugs
Key: JBTM-1020
URL: https://issues.jboss.org/browse/JBTM-1020
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Fix For: 5.0.0.M2
A recent bug in XTS recovery was found to be caused by the use of == rather than .equals() for String comparison. This type of bug can go unnoticed for a long period of time as == will usually return true for Strings with identical contents. However, it is not guaranteed.
I think it would be handy to run some tool every now and then to look for these types of bugs. I'm not sure how feasible this would be as it may return too many false positives.
--
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, 4 months
[JBoss JIRA] (JBTM-1027) Create a script to simplify XTS crash-recovery logs
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1027:
-----------------------------------
Summary: Create a script to simplify XTS crash-recovery logs
Key: JBTM-1027
URL: https://issues.jboss.org/browse/JBTM-1027
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
Currently the crash-recovery logs are very cumbersome to check. I propose we create a post-processing script that:
* Replaces transaction and participant IDs with uniq integers.
* Remove duplicate messages, keeping the last occurance
* Spilt log into clear before and after crash sections
* Add a title to log file, stating the name of the test
* Add a link to the original log file
--
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, 4 months