April 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2606: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2619) Create a quickstart to show using of the narayana-osgi-jta bundle (karaf)

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2619?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2619: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) > -------------------------------------------------------------------------- > > Key: JBTM-2619 > URL: https://issues.jboss.org/browse/JBTM-2619 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > It should be with the recovery example -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2624: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf > ----------------------------------------------------------------------------------- > > Key: JBTM-2624 > URL: https://issues.jboss.org/browse/JBTM-2624 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > {quote} > We have several management ways in Karaf : > * mbeans (no need to rewrap them) > * shell commands > * a servlet for the felix web console (used by the community) > * a hawtio plugin (used by fuse) > The first two are the most important imho. > {quote} > the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

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

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2623: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > 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

1
0
0 / 0

[JBoss JIRA] (JBTM-2632) Allow the setting of an initial delay in PeriodRecovery

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2632?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2632: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2632 > URL: https://issues.jboss.org/browse/JBTM-2632 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > <system-properties> > <property name="RecoveryEnvironmentBean.periodicRecoveryPeriod" value="120"/> > <property name="RecoveryEnvironmentBean.recoveryBackoffPeriod" value="10"/> > </system-properties> > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2629: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2634: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

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

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2639: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > 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

1
0
0 / 0

[JBoss JIRA] (JBTM-2641) Add localisation to JMS module warnings

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2641?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2641: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Add localisation to JMS module warnings > --------------------------------------- > > Key: JBTM-2641 > URL: https://issues.jboss.org/browse/JBTM-2641 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Warning messages in JMS modules should be localised same as other modules in ArjunaJTA. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2643: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 5.next > > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

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