July 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2270: -------------------------------- Affects Version/s: (was: 4.17.23) > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Ondřej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.later > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1804: -------------------------------- Fix Version/s: 5.next (was: 6.later) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 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 updated JBTM-2234: -------------------------------- Fix Version/s: 5.next (was: 5.later) > 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: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > 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.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1965) Add support for XADisk

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1965: -------------------------------- Fix Version/s: (was: 5.later) > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Student project > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > Fix For: 6.later > > > We're unlikely to maintain fileio but there may be a need for supporting some transactional file interactions. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1965) Add support for XADisk

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1965: -------------------------------- Fix Version/s: 6.later > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Student project > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > Fix For: 6.later > > > We're unlikely to maintain fileio but there may be a need for supporting some transactional file interactions. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2454) Internal IBM J9 compiler error building XTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2454?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2454: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Internal IBM J9 compiler error building XTS > ------------------------------------------- > > Key: JBTM-2454 > URL: https://issues.jboss.org/browse/JBTM-2454 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > On lancel we get the following error. I am unable to reproduce it on my laptop. > The compiler details are: > {quote} > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr1-20150417_01(SR1)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150410_243669 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR1_20150410_1531_B243669 > JIT - tr.r14.java_20150402_88976.03 > GC - R28_Java8_SR1_20150410_1531_B243669_CMPRSS > J9CL - 20150410_243669) > JCL - 20150413_01 based on Oracle jdk8u45-b13 > {quote} > and the build error is: > {quote} > [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ localjunit-disabled-context-propagation-tests --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 12 source files to /home/hudson/workspace/narayana-ibm-jdk/XTS/localjunit/disabled-context-propagation/target/test-classes > An exception has occurred in the compiler (1.8.0-internal). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. > java.lang.NullPointerException > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:142) > at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:189) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.visitType(JavacProcessingEnvironment.java:777) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.visitType(JavacProcessingEnvironment.java:758) > at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1162) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:157) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:798) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.findAnnotationsPresent(JavacProcessingEnvironment.java:993) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:891) > at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1182) > at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1182) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:868) > at com.sun.tools.javac.main.Main.compile(Main.java:535) > at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:141) > at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:150) > at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) > at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169) > at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785) > at org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:152) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2203: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2245) Narayana TM should act upon wildfly suspend calls

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2245?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2245: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Narayana TM should act upon wildfly suspend calls > ------------------------------------------------- > > Key: JBTM-2245 > URL: https://issues.jboss.org/browse/JBTM-2245 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Application Server Integration, XTS > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Wildfly now supports suspend [notifications | http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002862.html] > The design discussion is [here| http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002296.html] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2419) Consider reducing the number of JMH perf test forks on PRs

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2419?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2419: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Consider reducing the number of JMH perf test forks on PRs > ---------------------------------------------------------- > > Key: JBTM-2419 > URL: https://issues.jboss.org/browse/JBTM-2419 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > We run our JMH tests multiple times in order to estimate run-to-run variance. The [JMH docs|http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/m...] state: > bq. JVMs are complex systems, and the non-determinism is inherent for them. This requires us to always account the run-to-run variance as the one of the effects in our experiments. Forking aggregates the results across several JVM launches. > Currently we set the number of forks to 10. We run each test 6 times with each run lasting 1 min. Since we have 10 tests this means it takes 10 * 10 * 6 minutes for the benchmarks to complete. In the future we want to keep adding new performance tests and the time taken to run a PR will become prohibitive. I would like to propose one of the following solutions: > - reduce the number of forks; > - run a subset of performance tests on each PR and then run them all once a week or so on the main build > My preference is to reduce the number of forks to 3. Note that the PR requester has the option to disable performance tests for his PR (by including !PERF in the comment section). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 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 updated JBTM-2409: -------------------------------- Fix Version/s: 5.next (was: 5.later) > 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: Michael Musgrove > Fix For: 5.next > > Attachments: 32287.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.3.15#6346)

8 years, 9 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 July 2015