[JBoss JIRA] (ISPN-5944) Backport to 8.0.x branch
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-5944:
----------------------------------
Summary: Backport to 8.0.x branch
Key: ISPN-5944
URL: https://issues.jboss.org/browse/ISPN-5944
Project: Infinispan
Issue Type: Task
Components: Core
Affects Versions: 8.0.1.Final
Reporter: Paul Ferraro
Fix For: 8.0.2.Final
Parent task for issues fixed in master to be backported to the 8.0.x branch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5876) Pre-commit cache invalidation creates stale cache vulnerability
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5876?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5876:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1279982, https://bugzilla.redhat.com/show_bug.cgi?id=1273147 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1273147)
> Pre-commit cache invalidation creates stale cache vulnerability
> ---------------------------------------------------------------
>
> Key: ISPN-5876
> URL: https://issues.jboss.org/browse/ISPN-5876
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.7.Final
> Reporter: Stephen Fikes
> Assignee: Galder Zamarreño
> Fix For: 5.2.15.Final, 8.1.0.Beta1, 8.1.0.Final
>
>
> In a cluster where Infinispan serves as the level 2 cache for Hibernate (configured for invalidation), because invalidation requests for modified entities are sent *before* database commit, it is possible for nodes receiving the invalidation request to perform eviction and then (due to "local" read requests) reload the evicted entities prior to the time the database commit takes place in the server where the entity was modified.
> Consequently, other servers in the cluster may contain data that remains stale until a subsequent change in another server or until the entity times out from lack of use.
> It isn't easy to write a testcase for this - it required manual intervention to reproduce - but can be seen with any entity class, cluster, etc. (at least using Oracle - results may vary with specific databases) so I've not attached a testcase. The issue can be seen/understood by code inspection (i.e. the timing of invalidation vs. database commit). That said, my test consisted of a two node cluster and I used Byteman rules to delay database commit of a change to an entity (with an optimistic version property) long enough in "server 1" for eviction to complete and a subsequent re-read (by a worker thread on behalf of an EJB) to take place in "server 2". Following the re-read in "server 2", I the database commit proceeds in "server 1" and "server 2" now has a stale copy of the entity in cache.
> One option is pessimistic locking which will block any read attempt until the DB commit completes. It is not feasible, however, for many applications to use pessimistic locking for all reads as this can have a severe impact on concurrency - and is the reason for using optimistic version control. But due to the early timing of invalidation broadcast (*before* database commit, while the data is not yet stale), optimistic locking is insufficient to guard against "permanently" stale data. We did see that some databases default to blocking repeatable reads even outside of transactions and without explicit lock requests. Oracle does not provide such a mode. So, all reads must be implemented to use pessimistic locks (which must be enclosed in explicit transactions - (b)locking reads are disallowed when autocommit=true in Oracle) and this could require significant effort (re-writes) to use pessimistic reads throughout - in addition to the performance issues this can introduce.
> If broadcast of an invalidation message always occurs *after* database commit, optimistic control attributes are sufficient to block attempts to write stale data and though a few failures may occur (as they would in a single server with multiple active threads), it can be known that the stale data will be removed in some finite period.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5942) ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5942?page=com.atlassian.jira.plugin.... ]
Roman Macor commented on ISPN-5942:
-----------------------------------
ClusterListenerDistTxInitialStateTest.testMetadataExpirationConverterSuccessNotOwner also fails with assertion error:
java.lang.AssertionError: expected:<25000> but was:<null>
> ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-5942
> URL: https://issues.jboss.org/browse/ISPN-5942
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Roman Macor
>
> ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly with:
> Error Message
> expected:<fi> but was:<null>
> Stacktrace
> java.lang.AssertionError: expected:<fi> but was:<null>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerUtilTest.verifySimpleExpirationEvents(AbstractClusterListenerUtilTest.java:292)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testExpirationConverter(AbstractClusterListenerTest.java:767)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testSimpleExpirationConverterNotOwner(AbstractClusterListenerTest.java:742)
> 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)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5943) Access log and statistics of cache operations
by Pedro Zapata (JIRA)
Pedro Zapata created ISPN-5943:
----------------------------------
Summary: Access log and statistics of cache operations
Key: ISPN-5943
URL: https://issues.jboss.org/browse/ISPN-5943
Project: Infinispan
Issue Type: Feature Request
Components: JMX, reporting and management
Reporter: Pedro Zapata
The HotRod and REST endpoint will have a dedicated log category, which will be disabled by default, to which we will log using a format which follows the typical HTTPD server access.log format, i.e. client_ip user_id timestamp op key response_size processing_time.
Enabling the log will be possible either by configuring the XML or by using the CLI.
Additional JMX and DMR metrics will be implemented which report the number of invocations for each operation, their cumulative execution time, and the average execution time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5942) ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5942?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5942:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1279956
Bugzilla Update: Perform
> ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-5942
> URL: https://issues.jboss.org/browse/ISPN-5942
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Roman Macor
>
> ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly with:
> Error Message
> expected:<fi> but was:<null>
> Stacktrace
> java.lang.AssertionError: expected:<fi> but was:<null>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerUtilTest.verifySimpleExpirationEvents(AbstractClusterListenerUtilTest.java:292)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testExpirationConverter(AbstractClusterListenerTest.java:767)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testSimpleExpirationConverterNotOwner(AbstractClusterListenerTest.java:742)
> 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)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5942) ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly
by Roman Macor (JIRA)
Roman Macor created ISPN-5942:
---------------------------------
Summary: ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly
Key: ISPN-5942
URL: https://issues.jboss.org/browse/ISPN-5942
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Reporter: Roman Macor
ClusterListenerDistTxInitialStateTest.testSimpleExpirationConverterNotOwner fails randomly with:
Error Message
expected:<fi> but was:<null>
Stacktrace
java.lang.AssertionError: expected:<fi> but was:<null>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerUtilTest.verifySimpleExpirationEvents(AbstractClusterListenerUtilTest.java:292)
at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testExpirationConverter(AbstractClusterListenerTest.java:767)
at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testSimpleExpirationConverterNotOwner(AbstractClusterListenerTest.java:742)
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)
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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months