[JBoss JIRA] Created: (JBTM-900) Some of XTS unit test EARs contain no longer supported namespace in META-INF/jboss-beans.xml
by Ivo Studensky (JIRA)
Some of XTS unit test EARs contain no longer supported namespace in META-INF/jboss-beans.xml
--------------------------------------------------------------------------------------------
Key: JBTM-900
URL: https://issues.jboss.org/browse/JBTM-900
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Testing, XTS
Affects Versions: 4.15.3
Reporter: Ivo Studensky
Some of the XTS unit test EARs contain no longer supported namespace in META-INF/jboss-beans.xml and so they cannot be deployed to AS7. See [1] for the current namespace used in XTS unit test EARs and [2] for the valid namespace that should be used in AS7. A bit weird is that those EARs can be successfully deployed by command line copy and by web admin console, but only deploying by Arquillian uncovered the issue. I've already filed a jira for that - AS7-1927.
Please could you take a look at that and fix the namespace?
Here is a list of the affected EARs:
ws-c-tests.ear
ws-t-tests.ear
wstx-tests.ear
[1]
<deployment xmlns="urn:jboss:bean-deployer:2.0">
[2]
<deployment xmlns="urn:jboss:pojo:7.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:pojo:7.0 jboss-pojo_7_0.xsd">
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBTM-867) Create an ultra high performance distributed transaction coordinator to handle infinispan, JMS, websevice(with compensation logic), file system resources and database transactions.
by Magnus Magnus (JIRA)
Create an ultra high performance distributed transaction coordinator to handle infinispan, JMS, websevice(with compensation logic), file system resources and database transactions.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBTM-867
URL: https://issues.jboss.org/browse/JBTM-867
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JTS
Reporter: Magnus Magnus
Fix For: 5.0.0.M2
Create an ultra high performance distributed transaction coordinator to handle infinispan, JMS, websevice(with compensation logic), file system resources and database transactions. Current XA implementations cause high performace degradation.
Transaction logs should be stored in massively parallelized sql/file backing stores(Use an infinispan write through cache region to store tx logs?) on the nodes.
Transaction manager should be able to work only with a webcontainer lie Tomcat (without a real application server).
Transaction coordinator should use blocking free(As much as possible. Use profiler like JProfiler or others heavily to detect locking/blocking issues) architecture in the source code to allow ultra high transaction counts (thousands/sec per server). It is necessary for new distributed cache architectures.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBTM-314) JDBCStore.getJDBCClass does not work for some JDBC drivers
by Jeremy Stone (JIRA)
JDBCStore.getJDBCClass does not work for some JDBC drivers
----------------------------------------------------------
Key: JBTM-314
URL: http://jira.jboss.com/jira/browse/JBTM-314
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transaction Core
Reporter: Jeremy Stone
Implementation of com.arjuna.ats.internal.arjuna.objectstore.JDBCStore getJDBCClass(Connection) breaks if JDBC driver DatabaseMetaData getDriverName() is not consistent between driver releases or driver implementations (e.g. SQLServer), and tries to load illegally named classes if first word of reported driver name contains illegal characters (e.g. MySql).
Maybe a pluggable strategy for determination of the class should be used instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[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, 2 months
[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, 2 months