[JBoss JIRA] (JBTM-937) TxBridge demo app fails with ServiceConstructionException: Could not find portType named {http://client.demo.txbridge.jbossts.jboss.org/}Restaurant when run with JTA parent tx option
by Ivo Studensky (Created) (JIRA)
TxBridge demo app fails with ServiceConstructionException: Could not find portType named {http://client.demo.txbridge.jbossts.jboss.org/}Restaurant when run with JTA parent tx option
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBTM-937
URL: https://issues.jboss.org/browse/JBTM-937
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Demonstrator
Affects Versions: 4.15.3
Reporter: Ivo Studensky
Assignee: Jonathan Halliday
With the latest AS7 (7.1.0.Alpha2-SNAPSHOT) the txbridge demo app fails due 'ServiceConstructionException: Could not find portType named {http://client.demo.txbridge.jbossts.jboss.org/}Restaurant' when run with JTA parent tx option. See the stacktrace:
{noformat}
12:22:32,368 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Could not find portType named {http://client.demo.txbridge.jbossts.jboss.org/}Restaurant
12:22:32,368 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:313)
12:22:32,369 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:306)
12:22:32,369 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at javax.xml.ws.Service.getPort(Service.java:168)
12:22:32,369 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.jboss.jbossts.txbridge.demo.client.BasicClient.testJTATransaction(BasicClient.java:221)
12:22:32,369 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.jboss.jbossts.txbridge.demo.client.BasicClient.doGet(BasicClient.java:122)
12:22:32,369 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
12:22:32,369 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
12:22:32,369 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
12:22:32,370 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
12:22:32,370 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
12:22:32,370 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
12:22:32,370 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:155)
12:22:32,370 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
12:22:32,370 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
12:22:32,370 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
12:22:32,371 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
12:22:32,371 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
12:22:32,371 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:670)
12:22:32,371 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
12:22:32,371 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at java.lang.Thread.run(Thread.java:662)
12:22:32,371 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Could not find portType named {http://client.demo.txbridge.jbossts.jboss.org/}Restaurant
12:22:32,372 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.getInterfaceInfo(ReflectionServiceFactoryBean.java:611)
12:22:32,372 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeWSDLOperations(ReflectionServiceFactoryBean.java:619)
12:22:32,372 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOperations(JaxWsServiceFactoryBean.java:289)
12:22:32,372 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:392)
12:22:32,372 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:499)
12:22:32,372 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:241)
12:22:32,373 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:202)
12:22:32,373 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:438)
12:22:32,373 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:311)
12:22:32,373 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) ... 19 more
{noformat}
After my change which is:
{noformat}
$ svn diff
Index: src/org/jboss/jbossts/txbridge/demo/client/BasicClient.java
===================================================================
--- src/org/jboss/jbossts/txbridge/demo/client/BasicClient.java (revision 37673)
+++ src/org/jboss/jbossts/txbridge/demo/client/BasicClient.java (working copy)
@@ -218,7 +218,8 @@
Service service = Service.create(wsdlLocation, serviceName);
// use a modified client interface with @HandlerChain configured on it.
- Restaurant restaurant = service.getPort(Restaurant.class);
+ QName portName = new QName("http://www.jboss.com/jbosstm/xts/demo/Restaurant", "RestaurantServiceAT");
+ Restaurant restaurant = service.getPort(portName, Restaurant.class);
System.out.println("CLIENT: calling business Web Services...");
{noformat}
..the demo app passes, but according to the server log the tx is not propagated to the web service (which could, however, be caused by my modification). Moreover, the demo app cannot identify such failure since the exception is eaten (and not further propagated) on the 'Restaurant' web service side. See the server log snippet:
{noformat}
12:31:04,840 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (http-thinkpax.localdomain-127.0.0.1-8080-1) Creating Service {http://bistro.demo.txbridge.jbossts.jboss.org/}BistroImplService from WSDL: http://localhost:8080/txbridge-demo-service/BistroImpl?wsdl
12:31:04,861 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) CLIENT: Obtaining userTransaction...
12:31:04,862 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) CLIENT: starting the transaction...
12:31:04,864 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) CLIENT: transaction ID= Transaction: TransactionImple < ac, BasicAction: 0:ffff7f000001:-3f25763a:4eaa83e2:17 status: ActionStatus.RUNNING >
12:31:04,874 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (http-thinkpax.localdomain-127.0.0.1-8080-1) Creating Service {http://www.jboss.com/jbosstm/xts/demo/Restaurant}RestaurantServiceATService from WSDL: http://localhost:8080/xtsdemowebservices/RestaurantServiceAT?wsdl
12:31:04,878 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) CLIENT: calling business Web Services...
12:31:05,356 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-2) RestaurantServiceAT transaction id =Unknown
12:31:05,368 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-2) RestaurantServiceAT - enrolling...
12:31:05,404 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) bookSeats: Participant enrolment failed
12:31:05,404 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) com.arjuna.wst.UnknownTransactionException
12:31:05,404 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at com.arjuna.mwlabs.wst11.at.remote.TransactionManagerImple.enlistForDurableTwoPhase(TransactionManagerImple.java:56)
12:31:05,404 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at com.jboss.jbosstm.xts.demo.services.restaurant.RestaurantServiceAT.bookSeats(RestaurantServiceAT.java:98)
12:31:05,404 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
12:31:05,405 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
12:31:05,405 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
12:31:05,405 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at java.lang.reflect.Method.invoke(Method.java:597)
12:31:05,405 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.ws.common.invocation.AbstractInvocationHandlerJSE.invoke(AbstractInvocationHandlerJSE.java:111)
12:31:05,405 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.wsf.stack.cxf.JBossWSInvoker._invokeInternal(JBossWSInvoker.java:169)
12:31:05,405 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:117)
12:31:05,406 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
12:31:05,406 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
12:31:05,406 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
12:31:05,406 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at java.util.concurrent.FutureTask.run(FutureTask.java:138)
12:31:05,406 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
12:31:05,406 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
12:31:05,407 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
12:31:05,407 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
12:31:05,407 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:206)
12:31:05,407 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
12:31:05,407 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:174)
12:31:05,408 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
12:31:05,408 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
12:31:05,408 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:107)
12:31:05,408 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
12:31:05,408 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
12:31:05,408 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
12:31:05,409 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
12:31:05,409 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
12:31:05,409 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
12:31:05,409 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
12:31:05,409 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
12:31:05,409 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:155)
12:31:05,410 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
12:31:05,411 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
12:31:05,411 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
12:31:05,411 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
12:31:05,412 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
12:31:05,412 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:670)
12:31:05,412 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952)
12:31:05,416 ERROR [stderr] (http-thinkpax.localdomain-127.0.0.1-8080-2) at java.lang.Thread.run(Thread.java:662)
12:31:05,425 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) CLIENT: calling commit on the transaciton...
12:31:05,426 INFO [stdout] (http-thinkpax.localdomain-127.0.0.1-8080-1) done
{noformat}
So there seems to be two issues actually. First, the txbridge demo app does not work with JTA parent tx type option. Second, the demo app does not fail when the transaction is not propagated to the web service.
--
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
11 years, 6 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
11 years, 6 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
11 years, 6 months
[JBoss JIRA] (JBTM-1186) Transactional FileIO demo fail on window due to special charactor in filename
by Amos Feng (JIRA)
Amos Feng created JBTM-1186:
-------------------------------
Summary: Transactional FileIO demo fail on window due to special charactor in filename
Key: JBTM-1186
URL: https://issues.jboss.org/browse/JBTM-1186
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Demonstrator
Affects Versions: 5.0.0.M1
Reporter: Amos Feng
Assignee: Amos Feng
Fix For: 5.0.0.Final
{code}
org.jboss.jbossts.fileio.xalib.txdirs.dir.XADirFile(SEVERE:Saving status information to 'C:\hudson\workspace\btny-quickstarts\businesstxdir/txDir_work/txDir-C:\hudson\workspace\btny-quickstarts\businesstxdir_txDir_work_64!5401921662186675/transaction.log' failed! Could not create filejavax.transaction.xa.XAException: txDir-C:\hudson\workspace\btny-quickstarts\businesstxdir_txDir_work_64!5401921662186675: Saving status information to 'C:\hudson\workspace\btny-quickstarts\businesstxdir/txDir_work/txDir-C:\hudson\workspace\btny-quickstarts\businesstxdir_txDir_work_64!5401921662186675/transaction.log' failed! Could not create file (ERR_SYSTEM)
Caused by: java.io.FileNotFoundException: C:\hudson\workspace\btny-quickstarts\businesstxdir\txDir_work\txDir-C:\hudson\workspace\btny-quickstarts\businesstxdir_txDir_work_64!5401921662186675\transaction.log (The filename, directory name, or volume label syntax is incorrect)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
at org.apache.commons.transaction.file.FileResourceManager$TransactionContext.saveState(FileResourceManager.java:1521)
{code}
--
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
11 years, 6 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
11 years, 6 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
11 years, 6 months
[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
11 years, 6 months