April 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1552) CI jobs that build the AS, should not skip tests.

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1552?page=com.atlassian.jira.plugin.... ] Paul Robinson reopened JBTM-1552: --------------------------------- > CI jobs that build the AS, should not skip tests. > ------------------------------------------------- > > Key: JBTM-1552 > URL: https://issues.jboss.org/browse/JBTM-1552 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Paul Robinson > Assignee: Paul Robinson > Priority: Minor > Fix For: 5.0.0.M3 > > Original Estimate: 30 minutes > Time Spent: 5 minutes > Remaining Estimate: 0 minutes > > Running these tests would have caught an issue at the PR stage, that ended up making it through to the release. > These tests only take about 10-15mins so it's not a massive overhead. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1359) Proxy Recovery Manager

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1359?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1359: ----------------------------------- Forum Reference: https://community.jboss.org/thread/223451 > Proxy Recovery Manager > ---------------------- > > Key: JBTM-1359 > URL: https://issues.jboss.org/browse/JBTM-1359 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA, JTS, Recovery, XTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.0.0.M3 > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > JTA should work, but must consider JTS and XTS too (encoded IP addresses in log records) -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1623) Connection refused in XATMI Implementation test

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1623?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-1623: --------------------------------- Thanks Tom to take a look at it. I checked the consoleText.txt 1. the build downloads jboss-as from http://172.17.131.2/job/narayana/lastSuccessfulBuild/artifact/jboss-as/bu... and it has deploy the many narayana test wars such as xtstest, txbridge. 2. the blacktie-linux.sh start jboss-as with default jvm args "-Xms64m -Xmx512m -XX:MaxPermSize=256m" so it might be the problem. The quickfix looks like to increase the memory but I just wonder it is possible to get a clean jboss-as build only with rest-at.war Amos > Connection refused in XATMI Implementation test > ----------------------------------------------- > > Key: JBTM-1623 > URL: https://issues.jboss.org/browse/JBTM-1623 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.0.0.M3 > > Attachments: consoleText.txt > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1466 -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1623) Connection refused in XATMI Implementation test

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1623?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-1623: ------------------------------------- Hi Amos, That is the OOMKiller. It is because the sum total of all processes at that time left the node no option but to nuke a process. The run is on beacon: {quote} [hudson@beacon ~]$ dmesg ... Out of memory: Killed process 10297, UID 502, (java). {quote} Can you check the build processes (AS, maven) has the "correct" (i.e. minimum it can cope with) memory allocations before I escalate to [~jhalliday] to take a look at what we can do nodeside. Tom > Connection refused in XATMI Implementation test > ----------------------------------------------- > > Key: JBTM-1623 > URL: https://issues.jboss.org/browse/JBTM-1623 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.0.0.M3 > > Attachments: consoleText.txt > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1466 -- 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, 7 months

1
0
0 / 0

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

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1616?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on JBTM-1616: --------------------------------------- http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1468 > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1623) Connection refused in XATMI Implementation test

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1623?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-1623: --------------------------------- It looks like the jboss-as was killed. {noformat} /home/hudson/workspace/blacktie-linux64/jboss-as//bin/standalone.sh: line 243: 10297 Killed "/usr/local/jdk1.7.0_17/bin/java" -D"[Standalone]" -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE "-Dorg.jboss.boot.log.file=/home/hudson/workspace/blacktie-linux64/jboss-as//standalone/log/server.log" "-Dlogging.configuration=file:/home/hudson/workspace/blacktie-linux64/jboss-as//standalone/configuration/logging.properties" -jar "/home/hudson/workspace/blacktie-linux64/jboss-as//jboss-modules.jar" -mp "/home/hudson/workspace/blacktie-linux64/jboss-as//modules" org.jboss.as.standalone -Djboss.home.dir="/home/hudson/workspace/blacktie-linux64/jboss-as/" -Djboss.server.base.dir="/home/hudson/workspace/blacktie-linux64/jboss-as//standalone" "-c" "standalone-full.xml" "-Djboss.bind.address=localhost" "-Djboss.bind.address.unsecure=localhost" {noformat} > Connection refused in XATMI Implementation test > ----------------------------------------------- > > Key: JBTM-1623 > URL: https://issues.jboss.org/browse/JBTM-1623 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.0.0.M3 > > Attachments: consoleText.txt > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1466 -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1623) Connection refused in XATMI Implementation test

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1623?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1623: ---------------------------------- Attachment: consoleText.txt > Connection refused in XATMI Implementation test > ----------------------------------------------- > > Key: JBTM-1623 > URL: https://issues.jboss.org/browse/JBTM-1623 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.0.0.M3 > > Attachments: consoleText.txt > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1466 -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1623) Connection refused in XATMI Implementation test

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-1623: ------------------------------------- Summary: Connection refused in XATMI Implementation test Key: JBTM-1623 URL: https://issues.jboss.org/browse/JBTM-1623 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: BlackTie Reporter: Gytis Trikleris Assignee: Amos Feng Priority: Minor Fix For: 5.0.0.M3 See: http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1466 -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ] Paul Robinson commented on JBTM-1522: ------------------------------------- I think all the failures are due to Undertow being merged (replacement for JBoss Web). I'm going to look into it as my highest priority. > "no XTS application recovery module found" during XTS Recovery Tests > -------------------------------------------------------------------- > > Key: JBTM-1522 > URL: https://issues.jboss.org/browse/JBTM-1522 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, XTS > Reporter: Paul Robinson > Assignee: Amos Feng > Priority: Critical > Fix For: 5.0.0.M3 > > Attachments: 2013-04-01_jbtm-1522_outputs.zip, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output.txt, com.arjuna.qa.junit.TestBACrashDuringCommit.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit.txt > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/... > Notice the following log is displayed repeatedly until the test gives up waiting for recovery: > {code} > WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 > {code} > This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular: > {code} > if (!found) { > // we failed to find a helper to convert a participant record so log a warning > // but leave it in the table for next time > RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId()); > } > {code} > It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry? > This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan... > h4.Cunning Plan > We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take: > # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it. > # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above. > # Configure the job to run @hourly until it fails with this problem. > # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build. > # Boot the AS and confirm that the issue is reproduced. > # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue. > # Attach a debugger to find out what the problem is. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ] Amos Feng commented on JBTM-1522: --------------------------------- OK, I get it. Hope [~paul.robinson] will resolve it soon. > "no XTS application recovery module found" during XTS Recovery Tests > -------------------------------------------------------------------- > > Key: JBTM-1522 > URL: https://issues.jboss.org/browse/JBTM-1522 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, XTS > Reporter: Paul Robinson > Assignee: Amos Feng > Priority: Critical > Fix For: 5.0.0.M3 > > Attachments: 2013-04-01_jbtm-1522_outputs.zip, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output.txt, com.arjuna.qa.junit.TestBACrashDuringCommit.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit.txt > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/... > Notice the following log is displayed repeatedly until the test gives up waiting for recovery: > {code} > WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 > {code} > This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular: > {code} > if (!found) { > // we failed to find a helper to convert a participant record so log a warning > // but leave it in the table for next time > RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId()); > } > {code} > It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry? > This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan... > h4.Cunning Plan > We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take: > # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it. > # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above. > # Configure the job to run @hourly until it fails with this problem. > # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build. > # Boot the AS and confirm that the issue is reproduced. > # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue. > # Attach a debugger to find out what the problem is. -- 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, 7 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