[JBoss JIRA] (JBTM-1799) Move javadoc configuration to "release" profile, and remove extra install plugin config
by Paul Gier (JIRA)
[ https://issues.jboss.org/browse/JBTM-1799?page=com.atlassian.jira.plugin.... ]
Paul Gier commented on JBTM-1799:
---------------------------------
Updated the PR based on some discussion about the commits.
> Move javadoc configuration to "release" profile, and remove extra install plugin config
> ---------------------------------------------------------------------------------------
>
> Key: JBTM-1799
> URL: https://issues.jboss.org/browse/JBTM-1799
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Gier
> Assignee: Paul Gier
> Fix For: 5.0.0.M4
>
>
> Several modules generate javadocs using the maven-javadoc-plugin. This is not needed for every build, just for releases, so it could be moved to a "release" profile.
> The narayana-full module depends on the generated javadoc, so this module will also need to be moved to the release profile.
> -Also, there is currently extra configuration of the install plugin in several modules which doesn't appear to have any function.-
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (JBTM-1799) Move javadoc configuration to "release" profile, and remove extra install plugin config
by Paul Gier (JIRA)
[ https://issues.jboss.org/browse/JBTM-1799?page=com.atlassian.jira.plugin.... ]
Paul Gier updated JBTM-1799:
----------------------------
Description:
Several modules generate javadocs using the maven-javadoc-plugin. This is not needed for every build, just for releases, so it could be moved to a "release" profile.
The narayana-full module depends on the generated javadoc, so this module will also need to be moved to the release profile.
-Also, there is currently extra configuration of the install plugin in several modules which doesn't appear to have any function.-
was:
Several modules generate javadocs using the maven-javadoc-plugin. This is not needed for every build, just for releases, so it could be moved to a "release" profile.
Also, there is currently extra configuration of the install plugin in several modules which doesn't appear to have any function.
> Move javadoc configuration to "release" profile, and remove extra install plugin config
> ---------------------------------------------------------------------------------------
>
> Key: JBTM-1799
> URL: https://issues.jboss.org/browse/JBTM-1799
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Gier
> Assignee: Paul Gier
> Fix For: 5.0.0.M4
>
>
> Several modules generate javadocs using the maven-javadoc-plugin. This is not needed for every build, just for releases, so it could be moved to a "release" profile.
> The narayana-full module depends on the generated javadoc, so this module will also need to be moved to the release profile.
> -Also, there is currently extra configuration of the install plugin in several modules which doesn't appear to have any function.-
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (JBTM-1568) Install the StompConnect component of BlackTie as an WildFly subsystem module
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1568?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1568:
--------------------------------
Summary: Install the StompConnect component of BlackTie as an WildFly subsystem module (was: Install BlackTie as an WildFly subsystem module)
> Install the StompConnect component of BlackTie as an WildFly subsystem module
> -----------------------------------------------------------------------------
>
> Key: JBTM-1568
> URL: https://issues.jboss.org/browse/JBTM-1568
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 weeks
> Time Spent: 1 week, 1 day
> Remaining Estimate: 4 days
>
> Apparently there is a way to deploy a war as a module coming soon, wait till this is available possibly. Though, in the meantime, you could merge the stompconnect ear and blacktie-admin-servers ear into a single ear.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (JBTM-1568) Install BlackTie as an WildFly subsystem module
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1568?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1568:
-------------------------------------
Hi Amos,
I think that the stompconnect service should be quite easy to change to a subsystem even without the ability to wrap it in an ear/war as actually the ear/war packaging was just used to get it to deploy into AS5 :)
In terms of the MDB, as Wolf says in your linked forum posting it looks like the MDB may have to remain as an MDB for now.
I will re position this Jira as "Install StompConnect as.." rather than the MDB.
Tom
> Install BlackTie as an WildFly subsystem module
> -----------------------------------------------
>
> Key: JBTM-1568
> URL: https://issues.jboss.org/browse/JBTM-1568
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 weeks
> Time Spent: 1 week, 1 day
> Remaining Estimate: 4 days
>
> Apparently there is a way to deploy a war as a module coming soon, wait till this is available possibly. Though, in the meantime, you could merge the stompconnect ear and blacktie-admin-servers ear into a single ear.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (JBTM-1619) HeuristicTest (and some others) hang
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1619?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1619:
-------------------------------------
Could @jaikiran possibly have a dodgy jacorb.properties in his home directory? (Does Jacorb read properties from a home directory?)
> HeuristicTest (and some others) hang
> ------------------------------------
>
> Key: JBTM-1619
> URL: https://issues.jboss.org/browse/JBTM-1619
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 4.17.3, 5.0.0.M2
> Reporter: jaikiran pai
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.M4
>
> Time Spent: 1 hour, 30 minutes
> Remaining Estimate: 0 minutes
>
> Running the com.hp.mwtests.ts.jts.local.heuristics.HeuristicTest (and some other tests in that module) hang on my system. All of them hang at the point where the POA is being destroyed. Here's the jstack output of the hanging tests:
> {code}
> 2013-04-05 18:53:53
> Full thread dump Java HotSpot(TM) Server VM (20.1-b02 mixed mode):
> "Attach Listener" daemon prio=10 tid=0x6e503c00 nid=0x55dc waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "POADestructor" prio=10 tid=0x6dd6f800 nid=0x559c in Object.wait() [0x6d7fe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0c0558> (a org.jacorb.poa.RequestController)
> at java.lang.Object.wait(Object.java:485)
> at org.jacorb.poa.RequestController.waitForShutdown(Unknown Source)
> - locked <0x9f0c0558> (a org.jacorb.poa.RequestController)
> at org.jacorb.poa.POA$1.run(Unknown Source)
> "Transaction Reaper Worker 0" daemon prio=10 tid=0x6dd13800 nid=0x5599 in Object.wait() [0x6dbfe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9e18c450> (a java.util.LinkedList)
> at java.lang.Object.wait(Object.java:485)
> at com.arjuna.ats.arjuna.coordinator.TransactionReaper.waitForCancellations(TransactionReaper.java:321)
> - locked <0x9e18c450> (a java.util.LinkedList)
> at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:65)
> "Transaction Reaper" daemon prio=10 tid=0x6dd5d000 nid=0x5598 in Object.wait() [0x6de5c000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9e184ae0> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
> at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:90)
> - locked <0x9e184ae0> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
> "Listener:55978" daemon prio=10 tid=0x6dd2ac00 nid=0x5597 runnable [0x6dead000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
> - locked <0x9f0c0140> (a java.net.SocksSocketImpl)
> at java.net.ServerSocket.implAccept(ServerSocket.java:462)
> at java.net.ServerSocket.accept(ServerSocket.java:430)
> at com.arjuna.ats.internal.arjuna.recovery.Listener.run(Listener.java:122)
> "ClientMessageReceptor0" daemon prio=10 tid=0x6dd22400 nid=0x5596 in Object.wait() [0x6defe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0c02d0> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:485)
> at org.jacorb.orb.giop.GIOPConnection.waitUntilConnected(Unknown Source)
> - locked <0x9f0c02d0> (a java.lang.Object)
> at org.jacorb.orb.giop.GIOPConnection.getMessage(Unknown Source)
> at org.jacorb.orb.giop.GIOPConnection.receiveMessages(Unknown Source)
> at org.jacorb.orb.giop.MessageReceptor.doWork(Unknown Source)
> at org.jacorb.util.threadpool.ConsumerTie.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:662)
> "ServerSocketListener" daemon prio=10 tid=0x6df7e000 nid=0x5594 runnable [0x6e196000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
> - locked <0x9f0c0400> (a java.net.SocksSocketImpl)
> at java.net.ServerSocket.implAccept(ServerSocket.java:462)
> at java.net.ServerSocket.accept(ServerSocket.java:430)
> at org.jacorb.orb.iiop.IIOPListener$Acceptor.run(Unknown Source)
> "RequestController-1" daemon prio=10 tid=0x6dd2c800 nid=0x5593 in Object.wait() [0x6e1fc000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0c0600> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:485)
> at org.jacorb.poa.RequestController.waitForQueue(Unknown Source)
> - locked <0x9f0c0600> (a java.lang.Object)
> at org.jacorb.poa.RequestController.run(Unknown Source)
> "Low Memory Detector" daemon prio=10 tid=0xb67bcc00 nid=0x5591 runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" daemon prio=10 tid=0xb67bb000 nid=0x5590 waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" daemon prio=10 tid=0xb67b9000 nid=0x558f waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0xb67b7800 nid=0x558e runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=10 tid=0xb67a9400 nid=0x558d in Object.wait() [0x6f165000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0f5fb8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
> - locked <0x9f0f5fb8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> "Reference Handler" daemon prio=10 tid=0xb67a7c00 nid=0x558c in Object.wait() [0x6e8b1000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0f6088> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:485)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
> - locked <0x9f0f6088> (a java.lang.ref.Reference$Lock)
> "main" prio=10 tid=0xb6705400 nid=0x5586 in Object.wait() [0xb68af000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9e2d8010> (a org.jacorb.poa.POA$1)
> at java.lang.Thread.join(Thread.java:1186)
> - locked <0x9e2d8010> (a org.jacorb.poa.POA$1)
> at java.lang.Thread.join(Thread.java:1239)
> at org.jacorb.poa.POA.destroy(Unknown Source)
> at com.arjuna.orbportability.internal.orbspecific.oa.implementations.POABase.destroyRootPOA(POABase.java:68)
> at com.arjuna.orbportability.oa.core.OA.destroyRootPOA(OA.java:97)
> at com.arjuna.orbportability.RootOA.destroy(RootOA.java:91)
> - locked <0x9f1098f0> (a com.arjuna.orbportability.RootOA)
> at com.hp.mwtests.ts.jts.local.heuristics.HeuristicTest.test(HeuristicTest.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:78)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
> "VM Thread" prio=10 tid=0xb67a4000 nid=0x558b runnable
> "GC task thread#0 (ParallelGC)" prio=10 tid=0xb670c800 nid=0x5587 runnable
> "GC task thread#1 (ParallelGC)" prio=10 tid=0xb670e000 nid=0x5588 runnable
> "GC task thread#2 (ParallelGC)" prio=10 tid=0xb670f800 nid=0x5589 runnable
> "GC task thread#3 (ParallelGC)" prio=10 tid=0xb6710c00 nid=0x558a runnable
> "VM Periodic Task Thread" prio=10 tid=0xb67be800 nid=0x5592 waiting on condition
> JNI global references: 1330
> {code}
> My environment is Ubuntu 11.x, Java version:
> {code}
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
> {code}
> mvn version:
> {code}
> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 19:21:28+0530)
> {code}
> This happens on master as well as 4.17 branch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (JBTM-1619) HeuristicTest (and some others) hang
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1619?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1619:
-------------------------------------
[~jaikiran], please can you try again with the latest master or 4.17? As Gytis and Mark mention (and myself and regular CI builds can add anecdotally) none of us can replicate this one.
> HeuristicTest (and some others) hang
> ------------------------------------
>
> Key: JBTM-1619
> URL: https://issues.jboss.org/browse/JBTM-1619
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 4.17.3, 5.0.0.M2
> Reporter: jaikiran pai
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.M4
>
> Time Spent: 1 hour, 30 minutes
> Remaining Estimate: 0 minutes
>
> Running the com.hp.mwtests.ts.jts.local.heuristics.HeuristicTest (and some other tests in that module) hang on my system. All of them hang at the point where the POA is being destroyed. Here's the jstack output of the hanging tests:
> {code}
> 2013-04-05 18:53:53
> Full thread dump Java HotSpot(TM) Server VM (20.1-b02 mixed mode):
> "Attach Listener" daemon prio=10 tid=0x6e503c00 nid=0x55dc waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "POADestructor" prio=10 tid=0x6dd6f800 nid=0x559c in Object.wait() [0x6d7fe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0c0558> (a org.jacorb.poa.RequestController)
> at java.lang.Object.wait(Object.java:485)
> at org.jacorb.poa.RequestController.waitForShutdown(Unknown Source)
> - locked <0x9f0c0558> (a org.jacorb.poa.RequestController)
> at org.jacorb.poa.POA$1.run(Unknown Source)
> "Transaction Reaper Worker 0" daemon prio=10 tid=0x6dd13800 nid=0x5599 in Object.wait() [0x6dbfe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9e18c450> (a java.util.LinkedList)
> at java.lang.Object.wait(Object.java:485)
> at com.arjuna.ats.arjuna.coordinator.TransactionReaper.waitForCancellations(TransactionReaper.java:321)
> - locked <0x9e18c450> (a java.util.LinkedList)
> at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:65)
> "Transaction Reaper" daemon prio=10 tid=0x6dd5d000 nid=0x5598 in Object.wait() [0x6de5c000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9e184ae0> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
> at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:90)
> - locked <0x9e184ae0> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
> "Listener:55978" daemon prio=10 tid=0x6dd2ac00 nid=0x5597 runnable [0x6dead000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
> - locked <0x9f0c0140> (a java.net.SocksSocketImpl)
> at java.net.ServerSocket.implAccept(ServerSocket.java:462)
> at java.net.ServerSocket.accept(ServerSocket.java:430)
> at com.arjuna.ats.internal.arjuna.recovery.Listener.run(Listener.java:122)
> "ClientMessageReceptor0" daemon prio=10 tid=0x6dd22400 nid=0x5596 in Object.wait() [0x6defe000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0c02d0> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:485)
> at org.jacorb.orb.giop.GIOPConnection.waitUntilConnected(Unknown Source)
> - locked <0x9f0c02d0> (a java.lang.Object)
> at org.jacorb.orb.giop.GIOPConnection.getMessage(Unknown Source)
> at org.jacorb.orb.giop.GIOPConnection.receiveMessages(Unknown Source)
> at org.jacorb.orb.giop.MessageReceptor.doWork(Unknown Source)
> at org.jacorb.util.threadpool.ConsumerTie.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:662)
> "ServerSocketListener" daemon prio=10 tid=0x6df7e000 nid=0x5594 runnable [0x6e196000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
> - locked <0x9f0c0400> (a java.net.SocksSocketImpl)
> at java.net.ServerSocket.implAccept(ServerSocket.java:462)
> at java.net.ServerSocket.accept(ServerSocket.java:430)
> at org.jacorb.orb.iiop.IIOPListener$Acceptor.run(Unknown Source)
> "RequestController-1" daemon prio=10 tid=0x6dd2c800 nid=0x5593 in Object.wait() [0x6e1fc000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0c0600> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:485)
> at org.jacorb.poa.RequestController.waitForQueue(Unknown Source)
> - locked <0x9f0c0600> (a java.lang.Object)
> at org.jacorb.poa.RequestController.run(Unknown Source)
> "Low Memory Detector" daemon prio=10 tid=0xb67bcc00 nid=0x5591 runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" daemon prio=10 tid=0xb67bb000 nid=0x5590 waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" daemon prio=10 tid=0xb67b9000 nid=0x558f waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0xb67b7800 nid=0x558e runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=10 tid=0xb67a9400 nid=0x558d in Object.wait() [0x6f165000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0f5fb8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
> - locked <0x9f0f5fb8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> "Reference Handler" daemon prio=10 tid=0xb67a7c00 nid=0x558c in Object.wait() [0x6e8b1000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9f0f6088> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:485)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
> - locked <0x9f0f6088> (a java.lang.ref.Reference$Lock)
> "main" prio=10 tid=0xb6705400 nid=0x5586 in Object.wait() [0xb68af000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9e2d8010> (a org.jacorb.poa.POA$1)
> at java.lang.Thread.join(Thread.java:1186)
> - locked <0x9e2d8010> (a org.jacorb.poa.POA$1)
> at java.lang.Thread.join(Thread.java:1239)
> at org.jacorb.poa.POA.destroy(Unknown Source)
> at com.arjuna.orbportability.internal.orbspecific.oa.implementations.POABase.destroyRootPOA(POABase.java:68)
> at com.arjuna.orbportability.oa.core.OA.destroyRootPOA(OA.java:97)
> at com.arjuna.orbportability.RootOA.destroy(RootOA.java:91)
> - locked <0x9f1098f0> (a com.arjuna.orbportability.RootOA)
> at com.hp.mwtests.ts.jts.local.heuristics.HeuristicTest.test(HeuristicTest.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:78)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
> "VM Thread" prio=10 tid=0xb67a4000 nid=0x558b runnable
> "GC task thread#0 (ParallelGC)" prio=10 tid=0xb670c800 nid=0x5587 runnable
> "GC task thread#1 (ParallelGC)" prio=10 tid=0xb670e000 nid=0x5588 runnable
> "GC task thread#2 (ParallelGC)" prio=10 tid=0xb670f800 nid=0x5589 runnable
> "GC task thread#3 (ParallelGC)" prio=10 tid=0xb6710c00 nid=0x558a runnable
> "VM Periodic Task Thread" prio=10 tid=0xb67be800 nid=0x5592 waiting on condition
> JNI global references: 1330
> {code}
> My environment is Ubuntu 11.x, Java version:
> {code}
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
> {code}
> mvn version:
> {code}
> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 19:21:28+0530)
> {code}
> This happens on master as well as 4.17 branch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Mark Little commented on JBTM-846:
----------------------------------
Further to previous comment ... for instance what do we (or customers) expect from the statistics gathering routines in this new environment? Should it be measuring all transactions created and terminated in the JVM, or on a per transaction manager basis?
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months