[JBoss JIRA] (ISPN-7656) DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7656?page=com.atlassian.jira.plugin.... ]
Work on ISPN-7656 started by William Burns.
-------------------------------------------
> DefaultDataContainer.entrySet().stream().toArray(Object[]::new) may fail
> ------------------------------------------------------------------------
>
> Key: ISPN-7656
> URL: https://issues.jboss.org/browse/ISPN-7656
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Radim Vansa
> Assignee: William Burns
>
> When the default Spliterator estimates size of the array, it calls {{DefaultDataContainer.EntrySet#size()}} that returns directly the size of container (including expired entries). Then the container is iterated using {{ImmutableEntryIterator}} which excludes expired entries by default, and this may return less elements than the original size() provided. That causes failure like this:
> {code}
> java.lang.IllegalStateException: End size 1 is less than fixed size 2
> at java.util.stream.Nodes$FixedNodeBuilder.end(Nodes.java:1232)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:545)
> at java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
> at java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:438)
> {code}
> Note that this can also happen without expiration upon concurrent modification. We have to adjust the characteristics (remove {{#SIZED}}) of provided spliterators.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7586:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR4
Resolution: Done
> Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
> ----------------------------------------------------------------------------------
>
> Key: ISPN-7586
> URL: https://issues.jboss.org/browse/ISPN-7586
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.CR4
>
>
> We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster.
> This cause situations like this in the client:
> {code:java}
> client.put("K","value")
> // will get "V" back
> client.get("K")
> // Deletes will not propagate to the source cluster,
> // the RemoteStore is in 'read-only' mode.
> client.remove("K")
> // Returns "V". Although deleted, value will be retrieved
> // from the remote store
> cache.get("K")
>
> {code}
> This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reopened ISPN-7644:
--------------------------------
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Ryan Emerson edited comment on ISPN-7644 at 3/22/17 1:40 PM:
-------------------------------------------------------------
[~rmacor] This is actually a limitation of using the `<loader class=""/>` syntax, which is what the loaders configuration tab exposes. It won't work properly for any of the included cache-stores as they are not listed as a dependency in `modules/system/layers/base/org/infinispan/main/module.xml`. File-store is the exception, as it is included in core.
Furthermore, stores configured via <loader/> don't have additional dependencies (e.g. JDBC datasources) loaded and the user is required to configure these properties for a working store anyway.
Users who need to utilise one of the built in cache stores purely as a loader, should use the "stores" tab and configure their desired store as "read-only". I propose that we remove all of the loader options from the dropdown menu, except "No cache loader", "Cluster Loader" and "Custom Loader".
[~vblagojevic], [~NadirX] WDYT?
was (Author: ryanemerson):
[~rmacor] This is actually a limitation of using the `<loader class=""/>` syntax, which is what the loaders configuration tab exposes. It won't work properly for any of the included cache-stores as they are not listed as a dependency in `modules/system/layers/base/org/infinispan/main/module.xml`. File-store is the exception, as it is included in core.
Furthermore, stores configured via <loader/> don't have additional dependencies (e.g. JDBC datasources) loaded and the user is required to configure these properties for a working store anyway.
Users who need to utilise one of the built in cache stores purely as a loader, should use the "stores" tab and configure their desired store as "read-only". I propose that we remove all of the loader options from the dropdown menu, except "No cache loader", "Cluster Loader" and "Custom Loader".
[~vblagojevic][~NadirX] WDYT?
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-7644:
------------------------------------
[~rmacor] This is actually a limitation of using the `<loader class=""/>` syntax, which is what the loaders configuration tab exposes. It won't work properly for any of the included cache-stores as they are not listed as a dependency in `modules/system/layers/base/org/infinispan/main/module.xml`. File-store is the exception, as it is included in core.
Furthermore, stores configured via <loader/> don't have additional dependencies (e.g. JDBC datasources) loaded and the user is required to configure these properties for a working store anyway.
Users who need to utilise one of the built in cache stores purely as a loader, should use the "stores" tab and configure their desired store as "read-only". I propose that we remove all of the loader options from the dropdown menu, except "No cache loader", "Cluster Loader" and "Custom Loader".
[~vblagojevic][~NadirX] WDYT?
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7635) ComponentMetadataPersister hangs with IBM JDK
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7635?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7635:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR4
Resolution: Done
> 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.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7655) Calling Primitives.writeRawPrimitive with char raises java.lang.ClassCastException
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7655?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7655:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.CR4
(was: 9.0.0.Final)
Resolution: Done
> Calling Primitives.writeRawPrimitive with char raises java.lang.ClassCastException
> ----------------------------------------------------------------------------------
>
> Key: ISPN-7655
> URL: https://issues.jboss.org/browse/ISPN-7655
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR3
> Environment: Found the problem with a unit test on vertx-infinispan projet that was failing
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Fix For: 9.0.0.CR4
>
>
> java.lang.ClassCastException: java.lang.Character cannot be cast to java.lang.Integer
> at org.infinispan.marshall.core.Primitives.writeRawPrimitive(Primitives.java:89)
> at org.infinispan.marshall.core.Primitives.writePrimitive(Primitives.java:71)
> at org.infinispan.marshall.core.JBossMarshallerTest.testTT(JBossMarshallerTest.java:118)
> 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:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:127)
> 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:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7641?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7641:
----------------------------------
Fix Version/s: 9.0.0.CR4
> Do not use the Triangle when in server mode
> -------------------------------------------
>
> Key: ISPN-7641
> URL: https://issues.jboss.org/browse/ISPN-7641
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.0.0.CR2
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: performance
> Fix For: 9.0.0.CR4, 9.0.0.Final
>
>
> The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup.
> Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent).
> This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle.
> Using the old algorithm only in server mode brings the performance back to normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7641) Do not use the Triangle when in server mode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7641?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7641:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Do not use the Triangle when in server mode
> -------------------------------------------
>
> Key: ISPN-7641
> URL: https://issues.jboss.org/browse/ISPN-7641
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.0.0.CR2
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: performance
> Fix For: 9.0.0.CR4, 9.0.0.Final
>
>
> The triangle algorithm optimizes the scenario where the originator is not the primary owner of key, by sending ordered update from the primary to the backup.
> Current implementation orders the updates by segments and if 2 or more keys in the same segment are updated concurrently, they must be updated in the backup sequential by the same order (safety condition, keeps the data consistent).
> This approach has a negative impact in the scenario where the originator is the primary owner. However, in server mode (more precise in hot rod protocol), the clients connect directly to the primary owner of a key. This leads to a performance degradation with the triangle.
> Using the old algorithm only in server mode brings the performance back to normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months