April 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2636) Backport deferred exceptions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2636: -------------------------------- Fix Version/s: 4.17.32 (was: 4.17.31) > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.32 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2636) Backport deferred exceptions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2636. ------------------------------- > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.32 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2440: ---------------------------------------- I asked [~adinn] to provide an opinion about whether it could be the annotation rather than the agent loading functionality that is the root cause of the problem and he suspects that it is most likely a bug in the dynamic agent loading behaviour in the J9 compiler. He also gave a good analysis of the issue which I am including here: {quote} I downloaded IBM's Java 7 SDK and tried to use it to build Byteman. That's enough to thoroughly test the use of the agent. The tests on the Byteman agent maven module are configured to install the agent from the command line using the -javaagent option (I do that rather than use the BMUnitRunner to auto-load because I don't want failures in BMUnit to stop the agent jar being built). These tests all worked ok. So, the IBM JDK does support all the functionality of the Byteman agent when you load it from the command line. The maven tests in the BMUnit maven module rely the BMUnitRunner annotation to auto-install the agent into an already running test JVM and this is what failed. The error output is attached. As you can see from the first exception trace the IBM JVM does implement dynamic loading -- the Attach operation is fielded and J9 tries to install the agent by executing com.ibm.tools.attach.javaSE.Attachment.loadAgentLibrary If you look at the cause of the exception you can see that this eventually calls into org.jboss.byteman.agent.Main.premain which is the Byteman entry point. This tries to register its ClassFileTransformer (InstrumentationImpl.addTransformer) and at this point J9 blows up. It is objecting to the agent's request for the ClassFileTransformer to be installed as a 'retransformable' transformer. That means it wants to be able to handle retransformations of existing classes as well as being given a chance to modify newly loaded classes. This seems a tad odd because when the Byteman agent is loaded on the command line it also asks its ClassFileTransformer to be installed as a retransformable transformer. So, the refusal by J9 must be some sort of policy decision on its part. I suspect that this may be a performance hack -- J9 may be willing to not perform certain optimizations in order to allow for retransformers if you install them from the get go but otherwise may decide to switch on optimizations that mean subsequent use of retransformers won't work. Whatever the reason IBM have done this you are snookered until you can get them to remove this restriction. n.b. it is a legitimate (i.e. JVMTI agent spec-compliant) behaviour but it's not exactly very useful. I will make eqnuiries to see if I can talk to someone in IBM and get this removed or, at least, find a way to relax it but I am not sure I will have any traction. I think there is only one workaround which will fix this if you want to use BMUnit on both OpenJDK/Oracle and IBM. You will need to switch to loading the agent from the command line (whatever JVM you are using). To do this you need to: i) install the agent on the command line of the test JVM by configuring java command line argument -javaagent:/path/to/byteman.jar=listener:true ii) stop BMUnit from loading the agent by adding adding the property setting -Dorg.jboss.byteman.contrib.bmunit.agent.inhibit n.b. you will need to build the path to the byteman jar by referencing the relevant dependency in your maven repo dir. you should be able to do that using by substituting maven property values (repo dir + byteman dependency version) into the path n.b. if you don't do the load yourself then you may want to set some other -javaagent options and/or Byteman system properties. The auto load will do the equivalent of adding boot:/path/to/byteman.jar to the -javaagent line and adding -Dorg.jboss.byteman.allow.config.update as a system property setting. The former allows you to inject into JDK runtime classes. The latter allows BMUnit to pay heed to your any options specified using a BMUnitConfig annotation on your test class. regards, Andrew Dinn {quote} > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS).

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2623: ---------------------------------------- I have created a branch that fixes the blockers (https://github.com/jbosstm/narayana/tree/JBTM-223/interop) and also a wilfly branch that removes the EJB interceptor that blocks the import of foreign transactions (https://github.com/jbosstm/jboss-as/tree/5_BRANCH_JBTM-223). The interop/README.md file in the JBTM-223 branch describes how to test transaction propagation and recovery. > Check Glassfish-to-Narayana interoperability (via JTS). > ------------------------------------------------------- > > Key: JBTM-2623 > URL: https://issues.jboss.org/browse/JBTM-2623 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS). > Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL. > \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279] > XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown: > {quote} > javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process > at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695) > at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61) > at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352) > at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399) > at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55) > at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330) > at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588) > at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255) > at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251) > at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968) > at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) > at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73) > at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24) > at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258) > at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48) > at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) > at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226) > at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418) > at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) > at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) > at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) > at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) > at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) > at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) > at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210) > at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118) > at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017) > at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606) > at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77) > at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231) > at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2653) Make the service context id for JTS coordinator propagation configurable

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2653: -------------------------------------- Summary: Make the service context id for JTS coordinator propagation configurable Key: JBTM-2653 URL: https://issues.jboss.org/browse/JBTM-2653 Project: JBoss Transaction Manager Issue Type: Task Components: JTS Affects Versions: 5.3.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional JTS transaction propagation uses a CORBA service context to transmit the coordinator object reference. We use a proprietary id to identify this context but if we want to interoperate with foreign transaction managers we need to use the standard value of zero. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-2639. ---------------------------------- Release Notes Text: I was trying to disable debug using QA_TRACE=0 but unset QA_TRACE is the correct way to disable it. Resolution: Cannot Reproduce > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2650) Remove typo from BAControler interface and its implementations

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2650?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2650: ---------------------------------- Status: Open (was: Pull Request Sent) > Remove typo from BAControler interface and its implementations > -------------------------------------------------------------- > > Key: JBTM-2650 > URL: https://issues.jboss.org/browse/JBTM-2650 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Fix typos in BAControler, LocalBAControler, and RemoteBAControler names. Also variables when those classes are used also have typos. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2639: ------------------------------------- http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/159/ > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2639: -------------------------------- Priority: Minor (was: Major) > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2646) Include a quickstart showing a command line equivalent of the wildfly transaction console

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2646?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2646: ----------------------------------- Fix Version/s: 5.next > Include a quickstart showing a command line equivalent of the wildfly transaction console > ----------------------------------------------------------------------------------------- > > Key: JBTM-2646 > URL: https://issues.jboss.org/browse/JBTM-2646 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Provide a standalone tool (in the form of a quickstart) that duplicates the functionality of the wildfly transactions console. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 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 2016