[JBoss JIRA] (ISPN-7636) HR 2.6 decoder misreads add client listener command
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-7636?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek updated ISPN-7636:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4989
> HR 2.6 decoder misreads add client listener command
> ---------------------------------------------------
>
> Key: ISPN-7636
> URL: https://issues.jboss.org/browse/ISPN-7636
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.CR2
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Priority: Critical
>
> HR 2.6 decoder misreads add client listener command, expecting more input form client, which results in hanged HR client, waiting for response from server:
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
> - locked <0x00000000d6ea7db0> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:204)
> - locked <0x00000000d6ea7da0> (a java.lang.Object)
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> - locked <0x00000000d6ea80d0> (a sun.nio.ch.SocketAdaptor$SocketInputStream)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> - locked <0x00000000d6ea7f30> (a java.io.BufferedInputStream)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:220)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:325)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeaderOrEvent(Codec20.java:225)
> at org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation.executeOperation(AddClientListenerOperation.java:97)
> at org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation.executeOperation(AddClientListenerOperation.java:27)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.addClientListener(RemoteCacheImpl.java:439)
> {noformat}
> Can be easily reproduced with many tests from HR client testsuite (e.g. {{ClusterInvalidatedNearCacheTest}}) - tests just hangs
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7636) HR 2.6 decoder misreads add client listener command
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-7636:
-------------------------------------
Summary: HR 2.6 decoder misreads add client listener command
Key: ISPN-7636
URL: https://issues.jboss.org/browse/ISPN-7636
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols
Affects Versions: 9.0.0.CR2
Reporter: Vojtech Juranek
Assignee: Vojtech Juranek
Priority: Critical
HR 2.6 decoder misreads add client listener command, expecting more input form client, which results in hanged HR client, waiting for response from server:
{noformat}
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.Net.poll(Native Method)
at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
- locked <0x00000000d6ea7db0> (a java.lang.Object)
at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:204)
- locked <0x00000000d6ea7da0> (a java.lang.Object)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
- locked <0x00000000d6ea80d0> (a sun.nio.ch.SocketAdaptor$SocketInputStream)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0x00000000d6ea7f30> (a java.io.BufferedInputStream)
at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:220)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:325)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeaderOrEvent(Codec20.java:225)
at org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation.executeOperation(AddClientListenerOperation.java:97)
at org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation.executeOperation(AddClientListenerOperation.java:27)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.addClientListener(RemoteCacheImpl.java:439)
{noformat}
Can be easily reproduced with many tests from HR client testsuite (e.g. {{ClusterInvalidatedNearCacheTest}}) - tests just hangs
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7065) Collect clustered memory statistics
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7065?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-7065:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Collect clustered memory statistics
> -----------------------------------
>
> Key: ISPN-7065
> URL: https://issues.jboss.org/browse/ISPN-7065
> Project: Infinispan
> Issue Type: Feature Request
> Components: JMX, reporting and management, Server
> Reporter: Tristan Tarrant
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Currently, memory stats (such as used/free heap) in a cluster / domain need to be collected by looking at the JVM memory mbeans for each individual node.
> We should provide an MBean which provides aggregated cluster statistics for this as well as exposing this information over the DMR.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 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: Open)
Git Pull Request: 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.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)
9 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: Open (was: New)
> 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.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)
9 years
[JBoss JIRA] (ISPN-7635) ComponentMetadataPersister hangs with IBM JDK
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-7635:
-------------------------------------
Summary: 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.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)
9 years
[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7628?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic reassigned ISPN-7628:
-----------------------------------------
Assignee: Vladimir Blagojevic
> Administration console - the cluster status doesn't reflect "reload-required" state of its nodes
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-7628
> URL: https://issues.jboss.org/browse/ISPN-7628
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
>
> The cluster has "Started" status even though all of its nodes have "reload-required" status.
> Expected result:
> The cluster status should also be "reload-required"
> Another suggestion:
> "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7634) SerializationConfiguration.advancedExternalizers() map should not be mutable
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7634:
----------------------------------
Summary: SerializationConfiguration.advancedExternalizers() map should not be mutable
Key: ISPN-7634
URL: https://issues.jboss.org/browse/ISPN-7634
Project: Infinispan
Issue Type: Bug
Components: Configuration, Core
Affects Versions: 9.0.0.CR2
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Minor
Fix For: 9.0.0.Final
Currently {{SerializationConfiguration.advancedExternalizers()}} returns a mutable {{HashMap}}. We only read it once on startup, so modifying it won't break anything, but it should be immutable to make it clear that externalizers cannot be added at runtime.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7633) Deploying a task requires server reload
by Martin Gencur (JIRA)
Martin Gencur created ISPN-7633:
-----------------------------------
Summary: Deploying a task requires server reload
Key: ISPN-7633
URL: https://issues.jboss.org/browse/ISPN-7633
Project: Infinispan
Issue Type: Bug
Components: Server, Tasks
Affects Versions: 9.0.0.CR2
Reporter: Martin Gencur
Steps to reproduce:
1) deploy a Java task to the server
2) create a cache via CLI
3) try to call the task via remote HotRod cache API
The server must be reloaded before calling the task otherwise an exception similar to the following is thrown:
{code}
Expected: (an instance of org.infinispan.client.hotrod.exceptions.HotRodClientException and exception with message a string containing "Intentionally throws an exception.")
but: exception with message a string containing "Intentionally throws an exception." message was "java.lang.IllegalArgumentException: ISPN027002: Unknown task 'localScript_throwingException'"
Stacktrace was: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=27 returned server error (status=0x85): java.lang.IllegalArgumentException: ISPN027002: Unknown task 'localScript_throwingException'
at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
at org.infinispan.client.hotrod.impl.operations.ExecuteOperation.executeOperation(ExecuteOperation.java:50)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.execute(RemoteCacheImpl.java:542)
at org.infinispan.server.test.task.LocalServerTaskIT.shouldThrowExceptionInViaTask(LocalServerTaskIT.java:119)
....
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years