January 2012 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-891) Port XTS interop tests to JBoss AS 7.x

by Paul Robinson (JIRA)

Port XTS interop tests to JBoss AS 7.x -------------------------------------- Key: JBTM-891 URL: https://issues.jboss.org/browse/JBTM-891 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: XTS Reporter: Paul Robinson Assignee: Paul Robinson Priority: Minor Fix For: 5.0.0.M2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-840) AsynchStore.addWork() never leaves overlfow lock loop

by Tom Waterhouse (JIRA)

AsynchStore.addWork() never leaves overlfow lock loop ----------------------------------------------------- Key: JBTM-840 URL: https://issues.jboss.org/browse/JBTM-840 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.14.0 Environment: Ubuntu 10/Java 1.6/MySQL 5.5/JBoss JTS 4.14.0/Spring 3.0/Hibernate 3.6 Reporter: Tom Waterhouse It looks like somehow when using CacheStore with JBoss JTA it is possible to get into an endless loop. On the server our app is deployed one cpu is pegged at 100% usage. A thread dump revealed that a thread is executing AsyncStore.addWork() and never leaves (thread dump shows line 330, _overflowLock.wait()). Our cache size is set to 200k. Here is from the thread dump: "aggregation-1-14" prio=10 tid=0x00007f0508d0e800 nid=0x46e0 in Object.wait() [0x00007f050c8eb000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at com.arjuna.ats.internal.arjuna.objectstore.AsyncStore.addWork(CacheStore.java:330) - locked <0x00000007822a75f8> (a java.lang.Object) at com.arjuna.ats.internal.arjuna.objectstore.CacheStore.write_state(CacheStore.java:116) at com.arjuna.ats.internal.arjuna.objectstore.FileSystemStore.write_committed(FileSystemStore.java:134) at com.arjuna.ats.arjuna.coordinator.BasicAction.prepare(BasicAction.java:2218) - locked <0x0000000789f8f530> (a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1458) - locked <0x0000000789f8f530> (a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:159) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1158) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:119) at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1009) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:754) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723) at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:393) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:120) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy187.execute(Unknown Source) at com.attensa.core.executor.AggregationCallableImpl.call(AggregationCallableImpl.java:106) at com.attensa.core.executor.AggregationCallableImpl.call(AggregationCallableImpl.java:25) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (JBTM-527) Adding PMD to build system

by Romain PELISSE (JIRA)

Adding PMD to build system --------------------------- Key: JBTM-527 URL: https://jira.jboss.org/jira/browse/JBTM-527 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Build System Affects Versions: future Reporter: Romain PELISSE Priority: Trivial Attachments: adding-pmd-as-qa-tools.patch I have a small patch that offers an integration of PMD (http://pmd.sourceforge.net/) into the current build system of JBoss Transaction. Obviously, this is not an highly important feature request, having PMD checking java code is just nice to have. Anyway, as your project is not likely to integrate this patch quickly, I also published the result of a PMD run on the current source code: http://belaran.eu/jbosstm-pmd.html (this way you can already check what PMD find out without setting up the tool itself) I integrated PMD into the qa/ directory which seems the most appropriate directory at first glance... An other strategy would have been to define a "pmd" task inside some common build file ( maybe common/build.xml but it does not look like it), and then have each module call for this anttask with the appropriate java source folder... If you fell this approach is better, please let me know, i'll adapt my patch. All "violation" detected by PMD are not relevant, a pmd report is just a set of hints of something that may be a bad idea or could be improved. PMD rulesets (what kind of violation is looking for) are defined in the qa/pmd.xml. In this file you can easily include/exclude rules, and you can use it to configure the PMD Eclipse Plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
8
0 / 0

[JBoss JIRA] (JBTM-989) Consider using a common code style throughout Narayana

by Paul Robinson (Created) (JIRA)

Consider using a common code style throughout Narayana ------------------------------------------------------ Key: JBTM-989 URL: https://issues.jboss.org/browse/JBTM-989 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 5.0.0.M1 Reporter: Paul Robinson Assignee: Tom Jenkinson Fix For: 5.0.0.M2 I think we should consider using a common code style throughout the TS project. The benefits of doing this are as follows: # You can automate code formatting. This is a real productivity boost as you can type away, thinking about your code, rather than the style. When you hit save, or trigger it directly, the code is formatted. ## This is not possible without a project wide code style as you too frequently re-format code that needs to stay in someone else's personal style. You can't commit this changed code as; a) it may annoy the "owner" and b) it results in a change that can't be diffed (every line may be changed). # We get consistency over the whole project, making it easier to read code written by others. # We have to do this anyway for code we maintain inside the JBossAS project as the project refuses to build if it doesn't adhere to their style. Personally, I like the style I've used for the last 10 years. I find it harder to read code that is not in this style. Hence I can understand why people may object to changing their style. However, this is the very reason why a common style is beneficial. You can get used to a new style and once you do, the entire project will be styled in the way that you are used to. Providing the style is sensible, I would much rather use a style consistent across the projects I work on. I'm happy for that style to be different to my current style. As I stated above JBossAS mandates a style at build time. I don't particularly like the style (braces should occupy their own line, IMO) but I'm happy to go with this one if it becomes the Narayana standard style. I think we should also break the build for violations. This should prevent mistakes making their way into SVN. -- 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

6
17
0 / 0

[JBoss JIRA] (JBTM-1029) Run XTS unit, interop, and recovery tests during CI (NCL huson server)

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1029: ----------------------------------- Summary: Run XTS unit, interop, and recovery tests during CI (NCL huson server) Key: JBTM-1029 URL: https://issues.jboss.org/browse/JBTM-1029 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M3 -- 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

2
9
0 / 0

[JBoss JIRA] (JBTM-1013) BASubordinateCrashDuringComplete.txt kills the server too early

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1013: ----------------------------------- Summary: BASubordinateCrashDuringComplete.txt kills the server too early Key: JBTM-1013 URL: https://issues.jboss.org/browse/JBTM-1013 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 4.16.x, 5.0.0.M1 The rule 'RULE trace delete participant and exit JVM' fires before 'trace remove committed state' which prevents assertion that the transaction is removed. -- 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

2
11
0 / 0

[JBoss JIRA] (JBTM-961) Oracle database (dtfdb5) from the default jdbc profile in qa tests is unresponsive

by Ivo Studensky (Created) (JIRA)

Oracle database (dtfdb5) from the default jdbc profile in qa tests is unresponsive ---------------------------------------------------------------------------------- Key: JBTM-961 URL: https://issues.jboss.org/browse/JBTM-961 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.15.3 Reporter: Ivo Studensky Assignee: Ivo Studensky Fix For: 4.15.4 The Oracle database from the default jdbc profile in qa tests seems to be unresponsive, at least it is not possible to log in it with dtf11 and dtf12 accounts which is the reason why qa tests fail. The full hostname of that database is dtfdb5.mw.lab.eng.bos.redhat.com and although it is located in the middleware domain name, the eng-ops-mw guys know nothing about it and do not administrate it. -- 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

5
6
0 / 0

[JBoss JIRA] Created: (JBTM-866) Document XTS standalone configuration

by Tom Jenkinson (JIRA)

Document XTS standalone configuration ------------------------------------- Key: JBTM-866 URL: https://issues.jboss.org/browse/JBTM-866 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.0.M2 Remove the note in the narayana-full/readme.txt which points at a thread and replace with a link to the XTS documentation - which needs to be written :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
5
0 / 0

[JBoss JIRA] (JBTM-949) Automate the verification of trace output from the XTS crash recovery tests

by Paul Robinson (Created) (JIRA)

Automate the verification of trace output from the XTS crash recovery tests --------------------------------------------------------------------------- Key: JBTM-949 URL: https://issues.jboss.org/browse/JBTM-949 Project: JBoss Transaction Manager Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.Final Currently it is very difficult to verify the trace output from the XTS crash recovery tests. With the current code it is infeasible to run multiple servers as the trace output will span many files making it difficult to establish the correct order in which events occurred. I think, the following changes will make the test verification automatic and the tests scalable to many participants: # Carry out assertions in Byteman as the test progresses. Assertions at Runtime should be more flexible as more info is available. # Each participant is concerned only with the correctness of their own participation. This is key to scalability to many participants. # Anything that can't be solved by the above is dumped to one trace file per server and is hopefuly simple enough for scriptable post-verification. I think my idea needs prototyping first to check that it is feasible in practice. -- 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

4
6
0 / 0

[JBoss JIRA] Created: (JBTM-682) add emma code coverage to build

by Jonathan Halliday (JIRA)

add emma code coverage to build ------------------------------- Key: JBTM-682 URL: https://jira.jboss.org/jira/browse/JBTM-682 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Build System, Tooling Affects Versions: 4.9.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.10.0 Wire emma to the build system so we can start tracking unit test coverage. http://emma.sourceforge.net/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

7
25
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2012