[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2976?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2976:
------------------------------------
I'll get to work on CompressedFileAppender and ThreadNameFilter. I remember one selling poing of log4j2 was that you could add a filter that would execute before the message was formatted, which would make ThreadNameFilter more efficient.
> Log4J dependencies in codebase to be cleaned up
> -----------------------------------------------
>
> Key: ISPN-2976
> URL: https://issues.jboss.org/browse/ISPN-2976
> Project: Infinispan
> Issue Type: Task
> Affects Versions: 5.2.5.Final
> Reporter: Manik Surtani
> Assignee: Mircea Markus
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes.
> {{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly.
> {{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}.
> {{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-2978) Support temporary sessions in the CLI
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-2978:
-------------------------------------
Summary: Support temporary sessions in the CLI
Key: ISPN-2978
URL: https://issues.jboss.org/browse/ISPN-2978
Project: Infinispan
Issue Type: Enhancement
Components: CLI
Affects Versions: 5.2.5.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 5.3.0.Alpha1
Allow executing CLI commands with a throwaway session (passing a null)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up
by Manik Surtani (JIRA)
Manik Surtani created ISPN-2976:
-----------------------------------
Summary: Log4J dependencies in codebase to be cleaned up
Key: ISPN-2976
URL: https://issues.jboss.org/browse/ISPN-2976
Project: Infinispan
Issue Type: Task
Affects Versions: 5.2.5.Final
Reporter: Manik Surtani
Assignee: Mircea Markus
Fix For: 5.3.0.Alpha1, 5.3.0.Final
When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes.
{{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly.
{{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}.
{{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-2975) Random failures in DistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout and subclasses
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2975?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2975:
-------------------------------
Issue Type: Bug (was: Feature Request)
> Random failures in DistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout and subclasses
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2975
> URL: https://issues.jboss.org/browse/ISPN-2975
> Project: Infinispan
> Issue Type: Bug
> Components: RPC, Test Suite
> Affects Versions: 5.2.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Alpha1
>
>
> DistributedTaskBuilder supports setting a timeout for the distributed task. That timeout is used in two places: both a timeout for the FutureTask submitted to the local executor, and as a timeout for RPC invocations.
> The test testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout expects a TimeoutException, which I think is correct. But the distributed task future doesn't throw a TimeoutException if the RPC timed out, instead it throws something like this:
> {noformat}
> org.testng.TestException: Expected exception java.util.concurrent.TimeoutException but got java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575org.testng.TestException:Expected exception java.util.concurrent.TimeoutException but got java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
> at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1497)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:754)
> 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:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
> at java.util.concurrent.FutureTask.get(FutureTask.java:91)
> at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.innerGet(DefaultExecutorService.java:948)
> at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.get(DefaultExecutorService.java:927)
> at org.infinispan.distexec.DistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout(DistributedExecutorTest.java:159)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) ... 15 more
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:542)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:186)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:190)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:247)
> at org.infinispan.remoting.rpc.RpcManagerImpl.access$000(RpcManagerImpl.java:79)
> at org.infinispan.remoting.rpc.RpcManagerImpl$1.call(RpcManagerImpl.java:281) ... 5 more
> Caused by: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:418)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:301)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179) ... 11 more
> {noformat}
> I believe CommandAwareRpcDispatcher should wrap org.jgroups.TimeoutException in a org.infinispan.util.concurrent.TimeoutException, and DistributedTaskPart.innerGet should also treat ExecutionExceptions containing TimeoutExceptions specially.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-2975) Random failures in DistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout and subclasses
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2975:
----------------------------------
Summary: Random failures in DistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout and subclasses
Key: ISPN-2975
URL: https://issues.jboss.org/browse/ISPN-2975
Project: Infinispan
Issue Type: Feature Request
Components: RPC, Test Suite
Affects Versions: 5.2.0.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.3.0.Alpha1
DistributedTaskBuilder supports setting a timeout for the distributed task. That timeout is used in two places: both a timeout for the FutureTask submitted to the local executor, and as a timeout for RPC invocations.
The test testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout expects a TimeoutException, which I think is correct. But the distributed task future doesn't throw a TimeoutException if the RPC timed out, instead it throws something like this:
{noformat}
org.testng.TestException: Expected exception java.util.concurrent.TimeoutException but got java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575org.testng.TestException:Expected exception java.util.concurrent.TimeoutException but got java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1497)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:754)
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:334)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
at java.util.concurrent.FutureTask.get(FutureTask.java:91)
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.innerGet(DefaultExecutorService.java:948)
at org.infinispan.distexec.DefaultExecutorService$DistributedTaskPart.get(DefaultExecutorService.java:927)
at org.infinispan.distexec.DistributedExecutorTest.testBasicTargetRemoteDistributedCallableWithHighFutureAndLowTaskTimeout(DistributedExecutorTest.java:159)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) ... 15 more
Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
at org.infinispan.util.Util.rewrapAsCacheException(Util.java:542)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:186)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:190)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:247)
at org.infinispan.remoting.rpc.RpcManagerImpl.access$000(RpcManagerImpl.java:79)
at org.infinispan.remoting.rpc.RpcManagerImpl$1.call(RpcManagerImpl.java:281) ... 5 more
Caused by: org.jgroups.TimeoutException: timeout sending message to ReplSyncDistributedExecutorTest-NodeV-34575
at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:418)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:301)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179) ... 11 more
{noformat}
I believe CommandAwareRpcDispatcher should wrap org.jgroups.TimeoutException in a org.infinispan.util.concurrent.TimeoutException, and DistributedTaskPart.innerGet should also treat ExecutionExceptions containing TimeoutExceptions specially.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-2974) DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
by Horia Chiorean (JIRA)
[ https://issues.jboss.org/browse/ISPN-2974?page=com.atlassian.jira.plugin.... ]
Horia Chiorean updated ISPN-2974:
---------------------------------
Description:
When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node and evicted at the time of the change, to be rewritten with whatever the partial latest delta was.
In more detail:
* configure 2 nodes in replicated mode, with eviction enabled
* consider NodeA the writer and NodeB the reader
* NodeA inserts some data (custom entries) into the cache
* NodeB correctly receives via state transfer the initial data
* NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
* NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
If eviction is not enabled, everything works as expected.
was:
When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node but evicted at the time of the change, to be rewritten with whatever the partial latest delta was.
In more detail:
* configure 2 nodes in replicated mode, with eviction enabled
* consider NodeA the writer and NodeB the reader
* NodeA inserts some data (custom entries) into the cache
* NodeB correctly receives via state transfer the initial data
* NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
* NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
If eviction is not enabled, everything works as expected.
> DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2974
> URL: https://issues.jboss.org/browse/ISPN-2974
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final, 5.2.5.Final
> Reporter: Horia Chiorean
> Assignee: Mircea Markus
> Priority: Critical
>
> When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node and evicted at the time of the change, to be rewritten with whatever the partial latest delta was.
> In more detail:
> * configure 2 nodes in replicated mode, with eviction enabled
> * consider NodeA the writer and NodeB the reader
> * NodeA inserts some data (custom entries) into the cache
> * NodeB correctly receives via state transfer the initial data
> * NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
> * NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
> If eviction is not enabled, everything works as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years