April 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1619) HeuristicTest (and some others) hang

by jaikiran pai (JIRA)

jaikiran pai created JBTM-1619: ---------------------------------- Summary: 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: 5.0.0.M2, 4.17.3 Reporter: jaikiran pai Assignee: Tom Jenkinson 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1495) Merge in BlackTie

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1495?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1495: -------------------------------- Priority: Critical (was: Major) > Merge in BlackTie > ----------------- > > Key: JBTM-1495 > URL: https://issues.jboss.org/browse/JBTM-1495 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.0.0.M3 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Docs, code, forums, chat room (motd), Jira, web pages -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1618) Git pull requests: retest this please!

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-1618: ----------------------------------- Summary: Git pull requests: retest this please! Key: JBTM-1618 URL: https://issues.jboss.org/browse/JBTM-1618 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Build System Reporter: Tom Jenkinson Assignee: Paul Robinson Priority: Critical Fix For: 5.0.0.M3 If someone comments on a pull requesting a retest it would be nice that a job got scheduled. I don't really know how easy it is to do that, maybe the build bot needs to respond to emails? -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1617) When testing pull requests do a rebase to the merge point

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-1617: ----------------------------------- Summary: When testing pull requests do a rebase to the merge point Key: JBTM-1617 URL: https://issues.jboss.org/browse/JBTM-1617 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Build System Reporter: Tom Jenkinson Assignee: Gytis Trikleris Fix For: 5.0.0.M3 These instructions can go in the pull job config rather than narayana.sh I think as they do a full clean and that would be dangerous on a dev box # Clean up the local repo git rebase --abort rm -rf .git/rebase-apply git clean -f -d -x # Work out the branch point git branch -D 4.17 git branch 4.17 origin/4.17 git branch -D master git branch master origin/master myRev=`git rev-parse HEAD` ancestor417=`git merge-base $myRev 4.17` ancestorMaster=`git merge-base $myRev master` distanceFromMaster=`git log $ancestorMaster..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '` distanceFrom417=`git log $ancestor417..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '` if [ "$distanceFromMaster" -lt "$distanceFrom417" ] then export BRANCHPOINT=master else export BRANCHPOINT=4.17 fi # Update the pull to head git pull --rebase --ff-only origin $BRANCHPOINT # if this fails ($? -ne 0) fail the build and tell the committer (commentOnPull) that they need to rebase -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1616) BlackTie Integration Test Framework hang

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1616?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1616: ----------------------------------- Summary: BlackTie Integration Test Framework hang (was: REST recovery failed for blacktie) > BlackTie Integration Test Framework hang > ----------------------------------------- > > Key: JBTM-1616 > URL: https://issues.jboss.org/browse/JBTM-1616 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1465 -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1616) REST recovery failed for blacktie

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1616?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-1616: ---------------------------------------- That's expected if the test hung since periodic recovery is the only other activity that will be happening. The last line of the log shows that the server monitor process (CSControl.TestProcess) is about to exit but there is no entry in the log to indicate that the client was about to start, nor is there any C output indicating that the C executable (cs.c) is running - maybe the C exe is wedged in serverinit(). The test certainly never got as far as successfully starting the C client. I would definitely either debug it on a laptop or add some debug statements to indicate what the monitor process (TestProcess) read back from the launched process (it probably got end of stream on the first read but it would be handy to verify that). I would also add some debug to run_server in cs.cxx to see if it progressed passed serverinit. This extra debug is going to make the log noisy so I would be judicious in what logging I add when committing any fix. > REST recovery failed for blacktie > --------------------------------- > > Key: JBTM-1616 > URL: https://issues.jboss.org/browse/JBTM-1616 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1465 -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1616) REST recovery failed for blacktie

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1616?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1616: ------------------------------------- Not sure myself, all I saw is: 2013-04-03 01:58:09,422 [main] INFO (xatmi.CSControl :93 ) - start server process: 211 [0m01:58:17,557 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a1364946697%3a890071/ter... With that second line repeated constantly until we get a build time out > REST recovery failed for blacktie > --------------------------------- > > Key: JBTM-1616 > URL: https://issues.jboss.org/browse/JBTM-1616 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1465 -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1616) REST recovery failed for blacktie

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1616?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-1616: ---------------------------------------- I don't see how this relates to recovery. From what I can see the test is testing that XsdValidator is thread safe and launches two threads which simultaneously read the environment (cs.cxx bug211()) which is the very first test in this group (see CSTest.java). There is insufficient log output to determine where the test in hanging - I assume the test works on our laptops (if not then put a debugger on the test) otherwise I would advise introducing some extra debug output. > REST recovery failed for blacktie > --------------------------------- > > Key: JBTM-1616 > URL: https://issues.jboss.org/browse/JBTM-1616 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.0.M3 > > > http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1465 -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1600) narayana.sh continually attempts to rebase despite non in progress

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1600?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1600: -------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/jbosstm/narayana/pull/261 > narayana.sh continually attempts to rebase despite non in progress > ------------------------------------------------------------------ > > Key: JBTM-1600 > URL: https://issues.jboss.org/browse/JBTM-1600 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.M3 > > > See "No rebase in progress?" lines in: > http://172.17.131.2/job/btny-pulls-narayana/417/ > I think this can happen if you merge the last commit. The rebase is then complete, so "rebase --continue" fails, causing the script to continue it's loop. This is from memory, not had chance to check properly. > Also, it could be due to an upgrade in the CI nodes bringing a new version of git. -- 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

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1600) narayana.sh continually attempts to rebase despite non in progress

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1600?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-1600: --------------------------------- > narayana.sh continually attempts to rebase despite non in progress > ------------------------------------------------------------------ > > Key: JBTM-1600 > URL: https://issues.jboss.org/browse/JBTM-1600 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.M3 > > > See "No rebase in progress?" lines in: > http://172.17.131.2/job/btny-pulls-narayana/417/ > I think this can happen if you merge the last commit. The rebase is then complete, so "rebase --continue" fails, causing the script to continue it's loop. This is from memory, not had chance to check properly. > Also, it could be due to an upgrade in the CI nodes bringing a new version of git. -- 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

11 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2013