[JBoss JIRA] (ISPN-7635) ComponentMetadataPersister hangs with IBM JDK
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7635?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7635:
----------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4987, https://github.com/infinispan/infinispan/pull/5616 (was: https://github.com/infinispan/infinispan/pull/4987)
> ComponentMetadataPersister hangs with IBM JDK
> ---------------------------------------------
>
> Key: ISPN-7635
> URL: https://issues.jboss.org/browse/ISPN-7635
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 9.0.0.CR3
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.CR4, 9.0.0.Final
>
>
> When building with IBM JDK, the ComponentMetadataPersister hangs when generating infinispan-core's metadata:
> [08:24:58]W: [Step 1/2] [WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.infinispan.factories.components.ComponentMetadataPersister,maxpri=10]
> [08:24:58] : [Step 1/2] java.lang.IllegalThreadStateException: Has threads
> [08:24:58] : [Step 1/2] at java.lang.ThreadGroup.destroyImpl(ThreadGroup.java:256)
> [08:24:58] : [Step 1/2] at java.lang.ThreadGroup.destroy(ThreadGroup.java:238)
> [08:24:58] : [Step 1/2] at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328)
> [08:24:58] : [Step 1/2] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> [08:24:58] : [Step 1/2] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [08:24:58] : [Step 1/2] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> [08:24:58] : [Step 1/2] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> [08:24:58] : [Step 1/2] at java.lang.reflect.Method.invoke(Method.java:507)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> After some investigation, it appears this is caused by log4j being on the classpath, pulled in as an optional compile dependency on infinispan-core.
> Since nothing on core depends on log4j the fix is to make the dependency scoped to test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-7635) ComponentMetadataPersister hangs with IBM JDK
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7635?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reopened ISPN-7635:
-----------------------------------
> ComponentMetadataPersister hangs with IBM JDK
> ---------------------------------------------
>
> Key: ISPN-7635
> URL: https://issues.jboss.org/browse/ISPN-7635
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 9.0.0.CR3
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.CR4, 9.0.0.Final
>
>
> When building with IBM JDK, the ComponentMetadataPersister hangs when generating infinispan-core's metadata:
> [08:24:58]W: [Step 1/2] [WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.infinispan.factories.components.ComponentMetadataPersister,maxpri=10]
> [08:24:58] : [Step 1/2] java.lang.IllegalThreadStateException: Has threads
> [08:24:58] : [Step 1/2] at java.lang.ThreadGroup.destroyImpl(ThreadGroup.java:256)
> [08:24:58] : [Step 1/2] at java.lang.ThreadGroup.destroy(ThreadGroup.java:238)
> [08:24:58] : [Step 1/2] at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:328)
> [08:24:58] : [Step 1/2] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [08:24:58] : [Step 1/2] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> [08:24:58] : [Step 1/2] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [08:24:58] : [Step 1/2] at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> [08:24:58] : [Step 1/2] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [08:24:58] : [Step 1/2] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> [08:24:58] : [Step 1/2] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> [08:24:58] : [Step 1/2] at java.lang.reflect.Method.invoke(Method.java:507)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [08:24:58] : [Step 1/2] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> After some investigation, it appears this is caused by log4j being on the classpath, pulled in as an optional compile dependency on infinispan-core.
> Since nothing on core depends on log4j the fix is to make the dependency scoped to test.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-8541) Building from source on OSX caused deadlock during tests
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8541?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant resolved ISPN-8541.
-----------------------------------
Resolution: Duplicate Issue
> Building from source on OSX caused deadlock during tests
> --------------------------------------------------------
>
> Key: ISPN-8541
> URL: https://issues.jboss.org/browse/ISPN-8541
> Project: Infinispan
> Issue Type: Bug
> Components: Build process, Core
> Affects Versions: 9.1.3.Final
> Environment: MacOSX High Sierra
> 17.2.0 Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T02:58:13-05:00)
> Reporter: William Markito Oliveira
> Priority: Minor
> Attachments: jstack.log, jstack2.log, tests.log
>
>
> Building from source using build.sh is frozen after [PolarionJUnitXMLReporter] Test case 'testReplWriteValueAndReadValueAndMetadataOnOwner' already exists in the results
> Running jstack on the build process found 1 deadlock.
> jstack log attached with the locks.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-8534) Make off heap memory based eviction a better estimation
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8534?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8534:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Make off heap memory based eviction a better estimation
> -------------------------------------------------------
>
> Key: ISPN-8534
> URL: https://issues.jboss.org/browse/ISPN-8534
> Project: Infinispan
> Issue Type: Sub-task
> Components: Off Heap
> Affects Versions: 9.2.0.Beta1
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.2.0.Beta2, 9.1.4.Final
>
>
> Due to how eviction works with off heap the address block is not counted. We should make sure that is included to get a better count.
> Also we should make sure to account for at least 8 byte alignment for our various objects as they can vary in any size.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-8517) Lazily ressurect ice fromMemory
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8517?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8517:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Lazily ressurect ice fromMemory
> -------------------------------
>
> Key: ISPN-8517
> URL: https://issues.jboss.org/browse/ISPN-8517
> Project: Infinispan
> Issue Type: Sub-task
> Components: Off Heap
> Affects Versions: 9.2.0.Alpha2
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.2.0.Beta2, 9.1.4.Final
>
>
> Currently many places do
> {code}
> ice = ice = offHeapEntryFactory.fromMemory(address)
> if (wrappedKey.equalsWrappedBytes(ice.getKey()))
> {code}
> In cases where this ends up being a miss, we read the entire value which is wasteful. And the CPU may not have the key in the cache size we read the object into memory. Where as if we do
> {code}
> if (offHeapEntryFactory.equalsKey(address, key))
> ice = ice = offHeapEntryFactory.fromMemory(address)
> {code}
> we know that CPU is reading from the address location twice in a row, which has a very high chance of still being in CPU caches which should hopefully provide better performance. We also then don't have to read the entire ice object in memory unless there was a hit.
> We also should change _performGet_ to return the address instead of the ice. This way callers can use this address for other optimizations such as when doing a _evict_ or _compute_ which have to read the entry first before a remove.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-8525) StaleLocksWithLockOnlyTxDuringStateTransferTest.testSync failing randomly
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8525?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8525:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.Beta2
Resolution: Done
> StaleLocksWithLockOnlyTxDuringStateTransferTest.testSync failing randomly
> -------------------------------------------------------------------------
>
> Key: ISPN-8525
> URL: https://issues.jboss.org/browse/ISPN-8525
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Galder Zamarreño
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.2.0.Beta2
>
>
> http://ci.infinispan.org/job/Infinispan/job/PR-5556/17/
> org.infinispan.statetransfer.StaleLocksWithLockOnlyTxDuringStateTransferTest.testSync
> {code}
> Error Message
> Timed out waiting for rebalancing to complete on node StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeA-8365, expected member list is [StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeA-8365, StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeB-9821], current member list is [StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeA-8365]!
> Stacktrace
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeA-8365, expected member list is [StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeA-8365, StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeB-9821], current member list is [StaleLocksWithLockOnlyTxDuringStateTransferTest-NodeA-8365]!
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:385)
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:421)
> at org.infinispan.statetransfer.StaleLocksWithLockOnlyTxDuringStateTransferTest.testSync(StaleLocksWithLockOnlyTxDuringStateTransferTest.java:102)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 16 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-8568) ClassNotFoundException with Compat mode and custom Pojos
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8568?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8568:
------------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5614
> ClassNotFoundException with Compat mode and custom Pojos
> --------------------------------------------------------
>
> Key: ISPN-8568
> URL: https://issues.jboss.org/browse/ISPN-8568
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Beta2
>
>
> The cache is configured with:
> {code:xml}
> <cache-container name="local">
> <modules>
> <module name="deployment.myTask.jar"/>
> </modules>
> <local-cache name="compat">
> <compatibility enabled="true"/>
> </local-cache>
> </cache-container>
> {code}
> The {{myTask.jar}} contains Entity.class that is the Pojo to be stored in the cache.
> When doing a
> {code:java}
> remoteCache.put(1, new Entity());
> {code}
> The error is
> {noformat}
> 18:13:42,142 ERROR (main) [TestSuiteProgress] Test failed: LocalServerTestCompatModeIT.shouldRunPriceTask
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=9 returned
> server error (status=0x85): java.lang.ClassNotFoundException: org.infinispan.server.test.Entity from [Module "org.infinispan.commons:main" from
> local module loader @4ae82894 (finder: local module finder @543788f3 (roots: /home/gfernandes/github/infinispan/server/integration/testsuite/target/server/node1/modules,/home/gfernandes/github/infinispan/server/integration/testsuite/target/server/node1/modules/system/layers/base))]
> {noformat}
> I noticed that in this case, the Marshaller used is {{GenericJBossMarshaller}} who lives in infinispan-commons, and when asked to de-serialize the pojo in byte[] form, the classloader used is ModuleClassLoader for Module "org.infinispan.commons:main" that does not have visibility of the deployed jar's classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months