[JBoss JIRA] (ISPN-7705) Administration console - greyed out cluster action can still be selected
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7705?page=com.atlassian.jira.plugin.... ]
Roman Macor reopened ISPN-7705:
-------------------------------
The node operations work correctly, but the cluster operations are greyed out when they should not be.
Steps to reproduce:
click on clusters tab -> cluster -> Actions
Result:
Reload and Restart are greyed out and cannot be clicked
Expected result:
Reload and Restart should be available, only Start should be greyed out
> Administration console - greyed out cluster action can still be selected
> ------------------------------------------------------------------------
>
> Key: ISPN-7705
> URL: https://issues.jboss.org/browse/ISPN-7705
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.Final
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Fix For: 9.0.1.Final, 9.1.0.Final
>
>
> When the cluster is in the running state, start, reload and restart actions are greyed out, but they can still be clicked and the selected action is performed.
> This is not the case for the node operations.
> Also, shouldn't restart action be available when server/node are in running state?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years
[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)
8 years