[JBoss JIRA] (JBTM-1616) BlackTie Integration Test Framework hang
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1616?page=com.atlassian.jira.plugin.... ]
Amos Feng edited comment on JBTM-1616 at 4/27/13 4:08 AM:
----------------------------------------------------------
It cased by the valgrind bad option, see following server-2121-130425020630-err.txt
{noformat}
valgrind: Bad option: --show-reachable=false
valgrind: Invalid boolean value 'false' (should be 'yes' or 'no')
valgrind: Use --help for more information or consult the user manual.
{noformat}
This issue happen only on blacktie-linux64 because there is "use.valgrind = true"
so the fix should be use "--show-reachable=yes"
was (Author: zhfeng):
It cased by the valgrind bad option, see following server-2121-130425020630-err.txt
{noformat}
valgrind: Bad option: --show-reachable=false
valgrind: Invalid boolean value 'false' (should be 'yes' or 'no')
valgrind: Use --help for more information or consult the user manual.
{noformat}
This issue does not happen only on blacktie-linux64 because there is "use.valgrind = true"
so the fix should be use "--show-reachable=yes"
> 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
> Priority: Critical
> 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, 1 month
[JBoss JIRA] (JBTM-1611) Failing qa testcase org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery09, 10, 12 with jacorb and HornetQ object store enabled
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1611?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-1611:
----------------------------------------
Actually option 1 should be test on a slow machine and is random whether it will enable the test to pass. Therefore I will add some code to make the waiting/scan counts configurable.
> Failing qa testcase org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery09,10,12 with jacorb and HornetQ object store enabled
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1611
> URL: https://issues.jboss.org/browse/JBTM-1611
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 4.17.3
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Fix For: 4.17.5
>
>
> During testing EAP 6.1.0.ER3 I'm hitting problem on QA tests of narayana project for branch 4.17 when running qa tests with jacorb and hornetq object store (happening for NIO and AIO).
> Tests which are failing:
> org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery09
> - CrashRecovery09_Test01
> - CrashRecovery09_Test03
> - CrashRecovery09_Test05
> org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery10
> - CrashRecovery10_Test01
> - CrashRecovery10_Test03
> - CrashRecovery10_Test05
> org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery12
> - CrashRecovery12_Test03
> - CrashRecovery12_Test06
> Detailed log could be found in job:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-61-jbossts-qa-te...
> I was trying to get more info on the test CrashRecovery09 but I can say just that the value honlder has value 0 instead of 1 on org.jboss.jbossts.qa.CrashRecovery09Clients.Client01a (line 84).
--
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, 1 month
[JBoss JIRA] (JBTM-1611) Failing qa testcase org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery09, 10, 12 with jacorb and HornetQ object store enabled
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1611?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-1611:
----------------------------------------
I have been unable to replicate the issue on my laptop using the command:
{noformat}
ant -f run-tests.xml -Dtest.name=crashrecovery09 -Dtest.methods="CrashRecovery09_Test01" -Dprofile=hornetq onetest
{noformat}
and similarly for the other two failing methods in this test group and the other two test groups (crashrecover10 and crashrecover12). Therefore it looks like the issue is environmental.
I have just debugged one of the other QA crash recovery issues (JBTM-1601) and there I found that the client wasn't waiting long enough for recovery to kick in. Extending the wait period before checking for success fixed that issue but unfortunately these test groups uses a different method to wait for recovery. In this case the clients trigger a remote recovery scan. The internal interface does allow the client to trigger multiple passes but the first two test groups have the number of scans hardcoded to 1 and the last group does 2 passes so its not configurable. To test the theory we could either:
# run the test on a fast machine, or
# I patch the QA test suite so that scan counter is configurable and introduce a pause between scans
If either of these approaches work we can put the fix into 4.17.5
> Failing qa testcase org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery09,10,12 with jacorb and HornetQ object store enabled
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1611
> URL: https://issues.jboss.org/browse/JBTM-1611
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 4.17.3
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Fix For: 4.17.5
>
>
> During testing EAP 6.1.0.ER3 I'm hitting problem on QA tests of narayana project for branch 4.17 when running qa tests with jacorb and hornetq object store (happening for NIO and AIO).
> Tests which are failing:
> org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery09
> - CrashRecovery09_Test01
> - CrashRecovery09_Test03
> - CrashRecovery09_Test05
> org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery10
> - CrashRecovery10_Test01
> - CrashRecovery10_Test03
> - CrashRecovery10_Test05
> org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery12
> - CrashRecovery12_Test03
> - CrashRecovery12_Test06
> Detailed log could be found in job:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-61-jbossts-qa-te...
> I was trying to get more info on the test CrashRecovery09 but I can say just that the value honlder has value 0 instead of 1 on org.jboss.jbossts.qa.CrashRecovery09Clients.Client01a (line 84).
--
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, 1 month
[JBoss JIRA] (JBTM-1601) Failing qa testcase org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery02_2 on windows machines with jacorb
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1601?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-1601:
----------------------------------------
I managed to reproduce the problem on one of our windows machines and found that the same 5 tests fail. The problem is that the client sleeps for 5 seconds and then checks that recovery has happened which is perhaps a little eager when running on windows. I tried doubling the delay period and found that tests CrashRecovery02_2_Test26 through CrashRecovery02_2_Test30 then pass.
There is a file called qa/TaskImpl.properties that contains the following entry
* #timeoutFactor is a multiplier by which delays are multiplied - set to a larger value on slow servers
* COMMAND_LINE_12=-DCoreEnvironmentBean.timeoutFactor=1
Changing the multiplier to 2 fixed it for my windows machine. Try the same on yours and if it still fails go for 3.
> Failing qa testcase org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery02_2 on windows machines with jacorb
> --------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1601
> URL: https://issues.jboss.org/browse/JBTM-1601
> 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: Ondřej Chaloupka
> Assignee: Michael Musgrove
>
> I'm hitting an issue on qa tests for windows machines. I'm currently testing EAP 6.1.0.ER3.
> Testcase org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery02_2 is failing when it's run on windows machines. It does not matter which JDK is used. It fails on 4.17 branch and master as well.
> This happens for jacorb.
> The fails consistently occur on 5 tests from the testcase - that are from CrashRecovery02_2_Test26 till CrashRecovery02_2_Test30.
> All of them throw assertion:
> {quote}
> junit.framework.AssertionFailedError: task client1 printed Failed.
> {quote}
> These details apply to test CrashRecovery02_2_Test27:
> The client implementation is org.jboss.jbossts.qa.CrashRecovery02.Client02a and the fail comes from line 114 (branch 4.17).
> {code}
> correct = correct && (resourceTrace1 == ResourceTrace.ResourceTraceCommit);
> {code}
> Where the value of resourceTrace1 is {{ResourceTraceNone}}.
> I didn't get with investigation further so far.
> Steps for reproducing could be handy (using narayana.sh script first):
> 1. export NARAYANA_BUILD=0
> export NARAYANA_TESTS=0
> export CP_NARAYANA_AS=0
> export AS_BUILD=0
> export XTS_AS_TESTS=0
> export TXF_TESTS=0
> export XTS_TESTS=0
> export txbridge=0
> export QA_TESTS=1
> export SUN_ORB=0
> export QA_TARGET=test
> export QA_PROFILE="-Dtest=crashrecovery02_2"
> export WORKSPACE=$PWD
> 2. run naryana.sh - there was problem with paths for me so the command looks like this at the end
> {quote}
> sh scripts/hudson/narayana.sh -Demma.jar.location=c:\\tmp\\ochaloup\\ext -Demma.enabled=false -Dorson.jar.location=\\tmp\\ochaloup\\ext
> {quote}
> You can check whole stacktrace from job on jenkins:
> - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTS/view/JBossT...
> - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTS/view/JBossT...
> Do you think that you could check this?
--
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, 1 month
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1479:
---------------------------------------
Not sure how that forum post is accurate, but here it is: http://stackoverflow.com/questions/3997902/can-a-loaded-jar-be-deleted-by...
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Attachments: test-ds.xml, transaction.xml
>
> Original Estimate: 3 days
> Time Spent: 1 week, 1 day, 3 hours, 20 minutes
> Remaining Estimate: 0 minutes
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
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, 1 month
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1479:
-------------------------------------
I think that might be enough information to log a bug report against IronJacamar? Can you link this bug as dependent on the one you raise? Also can you provide the link to the stackoverflow article just in case.
Thanks,
Tom
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Attachments: test-ds.xml, transaction.xml
>
> Original Estimate: 3 days
> Time Spent: 1 week, 1 day, 3 hours, 20 minutes
> Remaining Estimate: 0 minutes
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
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, 1 month
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1479:
---------------------------------------
For the record, this is the failure:
{code}
-------------------------------------------------------------------------------
Test set: org.jboss.narayana.quickstart.jca.model.CustomerDAOTest
-------------------------------------------------------------------------------
Tests run: 10, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.32 sec <<< FAILURE!
org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0.063 sec <<< ERROR!
java.io.IOException: Could not delete C:\Users\hudson\AppData\Local\Temp\2\iron.jacamar\tmp\jdbc-xa.rar\ironjacamar-jdbc.jar
at com.github.fungal.impl.KernelImpl.recursiveDelete(KernelImpl.java:1520)
at com.github.fungal.impl.KernelImpl.recursiveDelete(KernelImpl.java:1515)
at com.github.fungal.impl.KernelImpl.recursiveDelete(KernelImpl.java:1515)
at com.github.fungal.impl.KernelImpl.shutdown(KernelImpl.java:850)
at org.jboss.jca.embedded.EmbeddedJCA.shutdown(EmbeddedJCA.java:158)
at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
{code}
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Attachments: test-ds.xml, transaction.xml
>
> Original Estimate: 3 days
> Time Spent: 1 week, 1 day, 3 hours, 20 minutes
> Remaining Estimate: 0 minutes
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
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, 1 month