February 2016 - jbossts-issues - Jboss List Archives

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

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2619?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2619: -------------------------------- Fix Version/s: 5.next (was: 5.2.14.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, 2 months

1
0
0 / 0

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

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2606: -------------------------------- Fix Version/s: 5.next (was: 5.2.14.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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2605) Narayana Spring integration

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2605?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2605: -------------------------------- Fix Version/s: 5.next (was: 5.2.14.Final) > Narayana Spring integration > --------------------------- > > Key: JBTM-2605 > URL: https://issues.jboss.org/browse/JBTM-2605 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, Documentation, JTA > Reporter: Gytis Trikleris > Fix For: 5.next > > > This is a wrapper for all subtasks related with Spring integration. > As per Tom's request we should improve Narayana integration with Spring and Spring Boot. Also, provide documentation and quickstarts for it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2553) Investigate the test with byteman do not work with the jacoco

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2553?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2553: -------------------------------- Fix Version/s: 5.next (was: 5.2.14.Final) > Investigate the test with byteman do not work with the jacoco > ------------------------------------------------------------- > > Key: JBTM-2553 > URL: https://issues.jboss.org/browse/JBTM-2553 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2571) Enable code coverage for XTS crash recovery tests

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2571?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2571: -------------------------------- Fix Version/s: 5.next (was: 5.2.14.Final) > Enable code coverage for XTS crash recovery tests > ------------------------------------------------- > > Key: JBTM-2571 > URL: https://issues.jboss.org/browse/JBTM-2571 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > Code coverage data is not collected during the XTS crash recovery tests execution. Currently this seems to be blocked by [1], [2], and [3]. > [1] https://community.jboss.org/message/817252 > [2] https://issues.jboss.org/browse/ARQ-1014 > [3] https://issues.jboss.org/browse/ARQ-918 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2409. ------------------------------- > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.2.14.Final > > Attachments: 32287.jstack, hang.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2234) out of memory when logging more messages than heap size (surefire issue)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2234. ------------------------------- > out of memory when logging more messages than heap size (surefire issue) > ------------------------------------------------------------------------ > > Key: JBTM-2234 > URL: https://issues.jboss.org/browse/JBTM-2234 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.0.2 > Environment: JTS testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.2.14.Final > > > Running com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 on JacORB with about 500000 transactions results in an OOM error because surefire keeps in logs in memory until the test has finished. > In this particular test jacorb logs messages at INFO level for each transaction resulting in excessive memory requirements. We can't make the heap too large because the default JVM is 32 bit. However, we could fix it by reducing the jacorb log level to WARN. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2626) Journal Store QA test failures

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2626: -------------------------------- Fix Version/s: 5.next (was: 5.2.14.Final) > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA... > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS... > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

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

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2623: -------------------------------- Fix Version/s: 5.next (was: 5.2.14.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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2618) Improve concurrent behavior of HornetqJournalStore

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2618?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2618. ------------------------------- > Improve concurrent behavior of HornetqJournalStore > -------------------------------------------------- > > Key: JBTM-2618 > URL: https://issues.jboss.org/browse/JBTM-2618 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > Fix For: 5.2.14.Final > > > Remove existing synchronized block and also make better usage of concurrent data structures already present in the code. > When there is a high number of threads, some will be block reducing the overall throughput and increasing response times on the whole system. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 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 February 2016