[JBoss JIRA] (ISPN-5613) Replication timeouts should show more information of the affected entries
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5613?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5613:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1243953|https://bugzilla.redhat.com/show_bug.cgi?id=1243953] from POST to MODIFIED
> Replication timeouts should show more information of the affected entries
> -------------------------------------------------------------------------
>
> Key: ISPN-5613
> URL: https://issues.jboss.org/browse/ISPN-5613
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Wolf-Dieter Fink
> Assignee: Dan Berindei
>
> Typical timeouts for replication are
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-595) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for jboss####-#####
> and
> ERROR ....
> Caused by: org.infinispan.util.concurrent.TimeoutException: Node jboss####-##### timed out
> The issue is that it is not possible to check what key/entry is affected.
> The cache can become inconsistent between nodes.
> There should be an information which key is affected.
> For some operations it is not possible at all as there is no information about the entries (i.e. commit) or the key is binary or custom without a valid toString() method.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 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 commented on ISPN-5876:
-----------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1273147|https://bugzilla.redhat.com/show_bug.cgi?id=1273147] from POST to MODIFIED
> 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)
8 years, 6 months
[JBoss JIRA] (ISPN-5882) XSite replication - take-offline.after-failures property is ignored
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5882?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5882:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1274800|https://bugzilla.redhat.com/show_bug.cgi?id=1274800] from POST to MODIFIED
> XSite replication - take-offline.after-failures property is ignored
> -------------------------------------------------------------------
>
> Key: ISPN-5882
> URL: https://issues.jboss.org/browse/ISPN-5882
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 8.1.0.Beta1, 8.1.0.Final
>
>
> Let's say I use the following backup settings and start the server in site LON:
> <backup site="BRN" strategy="SYNC">
> <take-offline after-failures="5"/>
> </backup>
> The following code snipped should cause BRN site to go offline after 5 failures, however the site is still remains online and tries to back up the data to BRN.
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager();
> RemoteCache<Object, Object> cache = remoteCacheManager.getCache();
> for (int i = 0; i < 10; i++) {
> cache.put(i, i);
> }
> Server-side error message example:
> 16:05:19,121 ERROR [org.jgroups.protocols.relay.RELAY2] (HotRodServerWorker-5-2) localhost: no route to BRN: dropping message
> 16:05:29,121 WARN [org.infinispan.xsite.BackupSenderImpl] (HotRodServerWorker-5-2) ISPN000202: Problems backing up data for cache default to site BRN: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from BRN (sync, timeout=10000)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5910) Distributed Stream should pass along certain flags
by William Burns (JIRA)
William Burns created ISPN-5910:
-----------------------------------
Summary: Distributed Stream should pass along certain flags
Key: ISPN-5910
URL: https://issues.jboss.org/browse/ISPN-5910
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.1.0.Alpha2
Reporter: William Burns
Assignee: William Burns
Distributed Stream doesn't currently pass along given flags. It should do this to ensure the same data is returned in cases such as OPERATION_HOTROD etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5909) Speed up StateTransferLargeObjectTest
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5909:
----------------------------------
Summary: Speed up StateTransferLargeObjectTest
Key: ISPN-5909
URL: https://issues.jboss.org/browse/ISPN-5909
Project: Infinispan
Issue Type: Task
Components: Test Suite - Core
Affects Versions: 8.1.0.Alpha2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.1.0.Beta1
The test queries the caches twice at the end, once to check the value types and then again to check the actual values. The second check should be sufficient.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months