[JBoss JIRA] (JBTM-1807) Participant's terminator resource cannot be found in TXF REST-AT tests
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1807?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1807:
----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/jbosstm/narayana/pull/354
> Participant's terminator resource cannot be found in TXF REST-AT tests
> ----------------------------------------------------------------------
>
> Key: JBTM-1807
> URL: https://issues.jboss.org/browse/JBTM-1807
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Time Spent: 4 hours
> Remaining Estimate: 0 minutes
>
> http://172.17.131.2/job/btny-pulls-narayana/781
> http://172.17.131.2/job/btny-pulls-narayana/784
> {code}
> [0m[33m13:17:34,469 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-7) failed to execute: javax.ws.rs.NotFoundException: Could not find resource for full path: http://localhost:8080/test/2/0_ffffac118307_1f9721a3_51cadbd7_19/1/termin...
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:111) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.1.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138) [undertow-websockets-jsr-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:131) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:118) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:94) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:629) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> {code}
--
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
10 years, 9 months
[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 edited comment on JBTM-1611 at 6/27/13 6:22 AM:
-----------------------------------------------------------------
Removing fix for M4 since it works on that version.
Added it back in again since CrashRecovery12 test 03 and 06 also fail on master with the hornetq store.
was (Author: mmusgrov):
Removing fix for M4 since it works on that version.
> 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, 5.0.0.M4
>
> Attachments: 0001-JBTM-1611-Make-recovery-passes-configurable.patch
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> 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
10 years, 9 months
[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:
----------------------------------------
There are two distinct error conditions here.
CrashRecovery09 tests 1, 3 and 5 and CrashRecovery10 tests 1, 3 and 5 all fail for the same reason:
There is code in ServerTopLevelAction.java which handles the incoming prepare call which eventually ends up in LockManager. The locking scheme used by LockManager depends upon whether or not there is a transaction associated. The fix is to ensure that ServerTopLevelAction does the thread association on prepare (note that this fix was added to the master branch back in May, see JBTM-1350, and that is why we don't see these failures there).
CrashRecovery12 test 03 and 06 fail for a number of different reasons:
To run with the hornetq store each task is started using ExecutionWrapper.java but using the wrapper to *explicitly* start the Recover Manager does not start it correctly (note that if the wrapper is used to start a different main class then the Recovery manager is started correctly).
The particular tests work as follows:
# start a recovery manager process
# start a client which creates a recoverable object but crashes in phase 2
# start a third process which will accept the replay completion call
So, for a successful outcome:
* the recovery manager must be running;
* the initial client and recovery manager must use the same object store (but the tests are configured to use stores in different locations on the disk);
* the process fielding the replay completion call must be listening on the same socket that the recovery manager is using. The tests use port offsets for these two process so they end up using different sockets so recovery never completes.
Resolving these 3 problems makes both tests pass.
> 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, 5.0.0.M4
>
> Attachments: 0001-JBTM-1611-Make-recovery-passes-configurable.patch
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> 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
10 years, 9 months
[JBoss JIRA] (JBTM-1807) Participant's terminator resource cannot be found in TXF REST-AT tests
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1807?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1807 started by Gytis Trikleris.
> Participant's terminator resource cannot be found in TXF REST-AT tests
> ----------------------------------------------------------------------
>
> Key: JBTM-1807
> URL: https://issues.jboss.org/browse/JBTM-1807
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Time Spent: 2 hours
> Remaining Estimate: 4 hours
>
> http://172.17.131.2/job/btny-pulls-narayana/781
> http://172.17.131.2/job/btny-pulls-narayana/784
> {code}
> [0m[33m13:17:34,469 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-7) failed to execute: javax.ws.rs.NotFoundException: Could not find resource for full path: http://localhost:8080/test/2/0_ffffac118307_1f9721a3_51cadbd7_19/1/termin...
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:111) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.1.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138) [undertow-websockets-jsr-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:131) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:118) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:94) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:629) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> {code}
--
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
10 years, 9 months
[JBoss JIRA] (JBTM-1728) Use a global environment variable in CI for version numbers of Narayana and WildFly
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1728?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1728:
-------------------------------------
Gytis,
I've updated the sanity check script. The problem is that it only complains on the first occurrence of the bad version usage, per job. Use the output of the job to find the configs using the hard coded version and then do a search and replace.
> Use a global environment variable in CI for version numbers of Narayana and WildFly
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1728
> URL: https://issues.jboss.org/browse/JBTM-1728
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System, Testing
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Time Spent: 15 minutes
> Remaining Estimate: 0 minutes
>
> We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly. We also have the same issue with jboss-as-7.2.0.Final.
> We should use global env variables instead. See the following for how to do it. Notice that I have already added one for Narayana.
> http://172.17.131.2/configure
> Call the variables:
> WILDFLY_MASTER_VERSION=8.0.0.Alpha2-SNAPSHOT
> JBOSS_7_2_VERSION=7.2.0.Final
> Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly/jboss version numbers. It will make it a lot easier to find all the places it is used.
--
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
10 years, 9 months
[JBoss JIRA] (JBTM-1728) Use a global environment variable in CI for version numbers of Narayana and WildFly
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1728?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1728:
--------------------------------
Description:
We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly. We also have the same issue with jboss-as-7.2.0.Final.
We should use global env variables instead. See the following for how to do it. Notice that I have already added one for Narayana.
http://172.17.131.2/configure
Call the variables:
WILDFLY_MASTER_VERSION=8.0.0.Alpha2-SNAPSHOT
JBOSS_7_2_VERSION=7.2.0.Final
Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly/jboss version numbers. It will make it a lot easier to find all the places it is used.
was:
We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly.
We should use a global env variable instead. See the following for how to do it. Notice that I have already added one for Narayana.
http://172.17.131.2/configure
Call the variable WILDFLY_MASTER_VERSION and set it to "8.0.0.Alpha2-SNAPSHOT".
Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly version numbers. It will make it a lot easier to find all the places it is used.
> Use a global environment variable in CI for version numbers of Narayana and WildFly
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1728
> URL: https://issues.jboss.org/browse/JBTM-1728
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System, Testing
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Time Spent: 15 minutes
> Remaining Estimate: 0 minutes
>
> We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly. We also have the same issue with jboss-as-7.2.0.Final.
> We should use global env variables instead. See the following for how to do it. Notice that I have already added one for Narayana.
> http://172.17.131.2/configure
> Call the variables:
> WILDFLY_MASTER_VERSION=8.0.0.Alpha2-SNAPSHOT
> JBOSS_7_2_VERSION=7.2.0.Final
> Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly/jboss version numbers. It will make it a lot easier to find all the places it is used.
--
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
10 years, 9 months
[JBoss JIRA] (JBTM-1728) Use a global environment variable in CI for version numbers of Narayana and WildFly
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1728?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1728:
--------------------------------
Description:
We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly.
We should use a global env variable instead. See the following for how to do it. Notice that I have already added one for Narayana.
http://172.17.131.2/configure
Call the variable WILDFLY_MASTER_VERSION and set it to "8.0.0.Alpha2-SNAPSHOT".
Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly version numbers. It will make it a lot easier to find all the places it is used.
was:
We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly.
We should use a global env variable instead. See the following for how to do it. Notice that I have already added one for Narayana.
http://172.17.131.2/configure
Call the variable WILDFLY_CURRENT_VERSION and set it to "8.0.0.Alpha2-SNAPSHOT".
Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly version numbers. It will make it a lot easier to find all the places it is used.
> Use a global environment variable in CI for version numbers of Narayana and WildFly
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1728
> URL: https://issues.jboss.org/browse/JBTM-1728
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System, Testing
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Time Spent: 15 minutes
> Remaining Estimate: 0 minutes
>
> We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly.
> We should use a global env variable instead. See the following for how to do it. Notice that I have already added one for Narayana.
> http://172.17.131.2/configure
> Call the variable WILDFLY_MASTER_VERSION and set it to "8.0.0.Alpha2-SNAPSHOT".
> Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly version numbers. It will make it a lot easier to find all the places it is used.
--
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
10 years, 9 months
[JBoss JIRA] (JBTM-1786) Change to TMFAIL for an ABORT on a non-prepared TX
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1786?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBTM-1786:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=978589
> Change to TMFAIL for an ABORT on a non-prepared TX
> --------------------------------------------------
>
> Key: JBTM-1786
> URL: https://issues.jboss.org/browse/JBTM-1786
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA, JTS
> Affects Versions: 4.16.4
> Reporter: Johnathon Lee
> Assignee: Johnathon Lee
>
> An ABORT on a non-prepared TX should be calling end with TMFAIL.
> It's more efficient in that the RM can return an RB* code immediately and short circuit the rollback internally if it likes. More importantly though the RM is less likely to object that it's still running tx activity on another thread and the concurrent TMSUCCESS therefore makes no sense to it.
> Also the XAResourceRecord.topLevelAbort code should immediately continue on to calling rollback on the resource despite the failed end().
--
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
10 years, 10 months
[JBoss JIRA] (JBTM-1809) At trace logging to facilitate discovery of the transaction hierarchy
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-1809:
--------------------------------------
Summary: At trace logging to facilitate discovery of the transaction hierarchy
Key: JBTM-1809
URL: https://issues.jboss.org/browse/JBTM-1809
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JTS
Affects Versions: 5.0.0.M3
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Priority: Optional
Fix For: 5.0.0.M4
In a distributed JTS transaction there is insufficient information in the logs to facilitate the construction of the transaction hierarchy.
For example when a transaction propagates between 3 servers the logs on server 3 do not indicate which of the two other servers has the parent transaction. This feature is required by the [https://community.jboss.org/wiki/TransactionMonitoringAndVisualization] tool.
A possible solution is to print out the TM node identifier and the CORBA request id in the CORBA Client and Server Request Interceptors (in methods send_request and receive_request_service_contexts respectively).
--
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
10 years, 10 months
[JBoss JIRA] (JBTM-1807) Participant's terminator resource cannot be found in TXF REST-AT tests
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1807?focusedWorklogId=12429420&page=... ]
Gytis Trikleris logged work on JBTM-1807:
-----------------------------------------
Author: Gytis Trikleris
Created on: 26/Jun/13 1:46 PM
Start Date: 26/Jun/13 1:46 PM
Worklog Time Spent: 2 hours
Issue Time Tracking
-------------------
Remaining Estimate: 4 hours (was: 2 hours)
Time Spent: 2 hours
Worklog Id: (was: 12429420)
> Participant's terminator resource cannot be found in TXF REST-AT tests
> ----------------------------------------------------------------------
>
> Key: JBTM-1807
> URL: https://issues.jboss.org/browse/JBTM-1807
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Time Spent: 2 hours
> Remaining Estimate: 4 hours
>
> http://172.17.131.2/job/btny-pulls-narayana/781
> http://172.17.131.2/job/btny-pulls-narayana/784
> {code}
> [0m[33m13:17:34,469 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-7) failed to execute: javax.ws.rs.NotFoundException: Could not find resource for full path: http://localhost:8080/test/2/0_ffffac118307_1f9721a3_51cadbd7_19/1/termin...
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:111) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.1.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138) [undertow-websockets-jsr-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:131) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:118) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:94) [undertow-servlet-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:629) [undertow-core-1.0.0.Alpha22.jar:1.0.0.Alpha22]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> {code}
--
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
10 years, 10 months