[JBoss JIRA] (ISPN-4554) Cache RpcOptions objects in TxDistributionInterceptor
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4554:
----------------------------------
Summary: Cache RpcOptions objects in TxDistributionInterceptor
Key: ISPN-4554
URL: https://issues.jboss.org/browse/ISPN-4554
Project: Infinispan
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: 7.0.0.Alpha5
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Minor
Fix For: 7.0.0.Beta1
The cost of creating a new RpcOptionsBuilder + RpcOptions instance should be trivial, but still there's no reason to do it.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4553) Add possibility to enable/disable jmx statistics on cache level using RHQ
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4553?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4553:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1122098
> Add possibility to enable/disable jmx statistics on cache level using RHQ
> -------------------------------------------------------------------------
>
> Key: ISPN-4553
> URL: https://issues.jboss.org/browse/ISPN-4553
> Project: Infinispan
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMX, reporting and management
> Affects Versions: 7.0.0.Alpha5
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Labels: rhq
>
> Monitoring of cache statistics (InVM plugin for RHQ) works pretty well now. However, when we create a brand new cache (using mgmt operation an a cache manager) -- this new cache is configured with DISABLED jmx stats by default.
> It would be awesome to add operation which can dynamically enable and disable JMX statistics per request (e.g. issue another JMX operation on a cache level.)
> Please, comment whether is this even possible and we will be not violating any restriction. WDYT? Thanks!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4553) Add possibility to enable/disable jmx statistics on cache level using RHQ
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-4553:
----------------------------------
Summary: Add possibility to enable/disable jmx statistics on cache level using RHQ
Key: ISPN-4553
URL: https://issues.jboss.org/browse/ISPN-4553
Project: Infinispan
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JMX, reporting and management
Affects Versions: 7.0.0.Alpha5
Reporter: Tomas Sykora
Assignee: Mircea Markus
Monitoring of cache statistics (InVM plugin for RHQ) works pretty well now. However, when we create a brand new cache (using mgmt operation an a cache manager) -- this new cache is configured with DISABLED jmx stats by default.
It would be awesome to add operation which can dynamically enable and disable JMX statistics per request (e.g. issue another JMX operation on a cache level.)
Please, comment whether is this even possible and we will be not violating any restriction. WDYT? Thanks!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4552) Upgrade H2 driver to 1.4.180
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-4552:
---------------------------------
Summary: Upgrade H2 driver to 1.4.180
Key: ISPN-4552
URL: https://issues.jboss.org/browse/ISPN-4552
Project: Infinispan
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Affects Versions: 7.0.0.Alpha5
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 7.0.0.Beta1
Fixes some OOME with in-memory H2 database.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4378) Configure marshaller class for binary filter/converter instances
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4378?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4378:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2737
> Configure marshaller class for binary filter/converter instances
> ----------------------------------------------------------------
>
> Key: ISPN-4378
> URL: https://issues.jboss.org/browse/ISPN-4378
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> Instead of having the filter/converters plugged with the marshaller instances, it's more practical to have them constructed with the marshaller class, and they can instantiate it in each of the servers. Previous description, for reference, below:
> ----
> The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks.
> Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured.
> There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable.
> However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly.
> Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4378) Configure marshaller class for binary filter/converter instances
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4378?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4378:
-----------------------------------
Summary: Configure marshaller class for binary filter/converter instances (was: Inject marshaller into binary filter/converter instances)
Description:
Instead of having the filter/converters plugged with the marshaller instances, it's more practical to have them constructed with the marshaller class, and they can instantiate it in each of the servers. Previous description, for reference, below:
----
The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks.
Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured.
There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable.
However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly.
Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case.
was:
The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks.
Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured.
There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable.
However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly.
Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case.
> Configure marshaller class for binary filter/converter instances
> ----------------------------------------------------------------
>
> Key: ISPN-4378
> URL: https://issues.jboss.org/browse/ISPN-4378
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> Instead of having the filter/converters plugged with the marshaller instances, it's more practical to have them constructed with the marshaller class, and they can instantiate it in each of the servers. Previous description, for reference, below:
> ----
> The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks.
> Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured.
> There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable.
> However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly.
> Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4551) RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4551?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-4551:
----------------------------
Component/s: Remote Protocols
Server
> RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-4551
> URL: https://issues.jboss.org/browse/ISPN-4551
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols, Server
> Affects Versions: 7.0.0.Alpha5
> Reporter: Ion Savin
> Assignee: Ion Savin
>
> On systems where UTF-8 is not the default charset parallel iteration over non-string keys fails.
> Non-string keys are mapped to strings prefixed by \uFEFF when the entry is stored. The key is URL-encoded and the prefix is stored properly. The GET /cacheName (all keys) response however uses the system-default charset and if that's not UTF-8 the prefix cannot be mapped and ends up being "?".
> To reproduce set the charset to ISO-8859-1 and run RestStoreParallelIterationTest and you should see failures similar to this one:
> {noformat}
> [testng-RestStoreParallelIterationTest] Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> 10:11:27,629 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-RestStoreParallelIterationTest) Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> org.infinispan.persistence.spi.PersistenceException: ISPN022005: Error loading entries from remote server
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:295)
> at org.infinispan.persistence.ParallelIterationTest.runIterationTest(ParallelIterationTest.java:103)
> at org.infinispan.persistence.ParallelIterationTest.testSequentialIteration(ParallelIterationTest.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception!
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:292)
> ... 22 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at org.infinispan.executors.ExecutorAllCompletionService.pollUntilEmpty(ExecutorAllCompletionService.java:48)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:32)
> at org.infinispan.persistence.rest.RestStore.submitProcessTask(RestStore.java:304)
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:284)
> ... 22 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.ParallelIterationTest$2.processEntry(ParallelIterationTest.java:106)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:314)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:304)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4551) RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4551?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-4551:
----------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2736
> RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-4551
> URL: https://issues.jboss.org/browse/ISPN-4551
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Alpha5
> Reporter: Ion Savin
> Assignee: Ion Savin
>
> On systems where UTF-8 is not the default charset parallel iteration over non-string keys fails.
> Non-string keys are mapped to strings prefixed by \uFEFF when the entry is stored. The key is URL-encoded and the prefix is stored properly. The GET /cacheName (all keys) response however uses the system-default charset and if that's not UTF-8 the prefix cannot be mapped and ends up being "?".
> To reproduce set the charset to ISO-8859-1 and run RestStoreParallelIterationTest and you should see failures similar to this one:
> {noformat}
> [testng-RestStoreParallelIterationTest] Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> 10:11:27,629 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-RestStoreParallelIterationTest) Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> org.infinispan.persistence.spi.PersistenceException: ISPN022005: Error loading entries from remote server
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:295)
> at org.infinispan.persistence.ParallelIterationTest.runIterationTest(ParallelIterationTest.java:103)
> at org.infinispan.persistence.ParallelIterationTest.testSequentialIteration(ParallelIterationTest.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception!
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:292)
> ... 22 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at org.infinispan.executors.ExecutorAllCompletionService.pollUntilEmpty(ExecutorAllCompletionService.java:48)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:32)
> at org.infinispan.persistence.rest.RestStore.submitProcessTask(RestStore.java:304)
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:284)
> ... 22 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.ParallelIterationTest$2.processEntry(ParallelIterationTest.java:106)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:314)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:304)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4551) RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4551?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-4551:
----------------------------
Description:
On systems where UTF-8 is not the default charset parallel iteration over non-string keys fails.
Non-string keys are mapped to strings prefixed by \uFEFF when the entry is stored. The key is URL-encoded and the prefix is stored properly. The GET /cacheName (all keys) response however uses the system-default charset and if that's not UTF-8 the prefix cannot be mapped and ends up being "?".
To reproduce set the charset to ISO-8859-1 and run RestStoreParallelIterationTest and you should see failures similar to this one:
{noformat}
[testng-RestStoreParallelIterationTest] Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
10:11:27,629 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-RestStoreParallelIterationTest) Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
org.infinispan.persistence.spi.PersistenceException: ISPN022005: Error loading entries from remote server
at org.infinispan.persistence.rest.RestStore.process(RestStore.java:295)
at org.infinispan.persistence.ParallelIterationTest.runIterationTest(ParallelIterationTest.java:103)
at org.infinispan.persistence.ParallelIterationTest.testSequentialIteration(ParallelIterationTest.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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.access$000(SuiteRunner.java:38)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception!
at org.infinispan.persistence.rest.RestStore.process(RestStore.java:292)
... 22 more
Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at org.infinispan.executors.ExecutorAllCompletionService.pollUntilEmpty(ExecutorAllCompletionService.java:48)
at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:32)
at org.infinispan.persistence.rest.RestStore.submitProcessTask(RestStore.java:304)
at org.infinispan.persistence.rest.RestStore.process(RestStore.java:284)
... 22 more
Caused by: java.lang.NullPointerException
at org.infinispan.persistence.ParallelIterationTest$2.processEntry(ParallelIterationTest.java:106)
at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:314)
at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:304)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
... 24 more
{noformat}
was:
On systems where UTF-8 is not the default charset parallel iteration over non-string keys fails.
Non-string keys are mapped to strings prefixed by \uFEFF when the entry is stored. The key is URL-encoded and the prefix is stored properly. The GET /{cacheName} (all keys) response however uses the system-default charset and if that's not UTF-8 the prefix cannot be mapped and ends up being "?".
To reproduce set the charset to ISO-8859-1 and run RestStoreParallelIterationTest and you should see failures similar to this one:
{noformat}
[testng-RestStoreParallelIterationTest] Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
10:11:27,629 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-RestStoreParallelIterationTest) Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
org.infinispan.persistence.spi.PersistenceException: ISPN022005: Error loading entries from remote server
at org.infinispan.persistence.rest.RestStore.process(RestStore.java:295)
at org.infinispan.persistence.ParallelIterationTest.runIterationTest(ParallelIterationTest.java:103)
at org.infinispan.persistence.ParallelIterationTest.testSequentialIteration(ParallelIterationTest.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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.access$000(SuiteRunner.java:38)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception!
at org.infinispan.persistence.rest.RestStore.process(RestStore.java:292)
... 22 more
Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at org.infinispan.executors.ExecutorAllCompletionService.pollUntilEmpty(ExecutorAllCompletionService.java:48)
at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:32)
at org.infinispan.persistence.rest.RestStore.submitProcessTask(RestStore.java:304)
at org.infinispan.persistence.rest.RestStore.process(RestStore.java:284)
... 22 more
Caused by: java.lang.NullPointerException
at org.infinispan.persistence.ParallelIterationTest$2.processEntry(ParallelIterationTest.java:106)
at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:314)
at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:304)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
... 24 more
{noformat}
> RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-4551
> URL: https://issues.jboss.org/browse/ISPN-4551
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 7.0.0.Alpha5
> Reporter: Ion Savin
> Assignee: Ion Savin
>
> On systems where UTF-8 is not the default charset parallel iteration over non-string keys fails.
> Non-string keys are mapped to strings prefixed by \uFEFF when the entry is stored. The key is URL-encoded and the prefix is stored properly. The GET /cacheName (all keys) response however uses the system-default charset and if that's not UTF-8 the prefix cannot be mapped and ends up being "?".
> To reproduce set the charset to ISO-8859-1 and run RestStoreParallelIterationTest and you should see failures similar to this one:
> {noformat}
> [testng-RestStoreParallelIterationTest] Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> 10:11:27,629 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-RestStoreParallelIterationTest) Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed.
> org.infinispan.persistence.spi.PersistenceException: ISPN022005: Error loading entries from remote server
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:295)
> at org.infinispan.persistence.ParallelIterationTest.runIterationTest(ParallelIterationTest.java:103)
> at org.infinispan.persistence.ParallelIterationTest.testSequentialIteration(ParallelIterationTest.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception!
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:292)
> ... 22 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at org.infinispan.executors.ExecutorAllCompletionService.pollUntilEmpty(ExecutorAllCompletionService.java:48)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:32)
> at org.infinispan.persistence.rest.RestStore.submitProcessTask(RestStore.java:304)
> at org.infinispan.persistence.rest.RestStore.process(RestStore.java:284)
> ... 22 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.ParallelIterationTest$2.processEntry(ParallelIterationTest.java:106)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:314)
> at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:304)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
> at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31)
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months