[JBoss JIRA] (ISPN-4444) After state transfer, a node is able to read keys it no longer owns from its data container
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4444?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4444:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1163665|https://bugzilla.redhat.com/show_bug.cgi?id=1163665] from POST to MODIFIED
> After state transfer, a node is able to read keys it no longer owns from its data container
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-4444
> URL: https://issues.jboss.org/browse/ISPN-4444
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.1.0.Alpha1
>
>
> When state transfer ends and each node receives a CH_UPDATE command from the coordinator, it first installs the new topology and then it starts invalidating entries it no longer owns.
> However, there are two cases when the node can still read its stale values:
> 1. If L1 is enabled, it will look in the local DataContainer first, regardless of the key's location.
> 2. If L1 is disabled, but the key was removed on the new owners, the node will still look up the key in the local DataContainer after receiving a null response.
> The problem can be reproduced with {{TxReadAfterLosingOwnershipTest}} and its subclasses, by replacing the {{operation.update(cache(1));}} line with {{operation.update(cache(0));}}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5030) NPE during node rebalance after a leave
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5030?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5030:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161214|https://bugzilla.redhat.com/show_bug.cgi?id=1161214] from POST to MODIFIED
> NPE during node rebalance after a leave
> ---------------------------------------
>
> Key: ISPN-5030
> URL: https://issues.jboss.org/browse/ISPN-5030
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.1.0.Alpha1
> Reporter: Sanne Grinovero
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 7.1.0.Beta1
>
>
> I'm seeing stacktraces dumped to standard out during the normal test run of the infinispan-core module:
> {noformat}
> 2014-11-28 21:39:52,652 WARN [CacheTopologyControlCommand] (remote-thread-DistributedEntryRetrieverTest-NodeA-p610-t6) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=org.infinispan.iteration.DistributedEntryRetrieverTest, type=LEAVE, sender=DistributedEntryRetrieverTest-NodeC-12939, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=2}
> java.lang.NullPointerException
> at org.infinispan.topology.ClusterCacheStatus.updateRebalanceMembers(ClusterCacheStatus.java:307)
> at org.infinispan.topology.ClusterCacheStatus.doLeave(ClusterCacheStatus.java:578)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleLeave(ClusterTopologyManagerImpl.java:148)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:164)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:278)
> 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:745)
> {noformat}
> This is the unmodified testsuite, in current master {{33c5f85}}. It doesn't seem to cause actual test failures.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4949:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161214|https://bugzilla.redhat.com/show_bug.cgi?id=1161214] from POST to MODIFIED
> Split brain: inconsistent data after merge
> ------------------------------------------
>
> Key: ISPN-4949
> URL: https://issues.jboss.org/browse/ISPN-4949
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Alpha1
>
>
> 1) cluster A, B, C, D splits into 2 parts:
> A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D]
> C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost)
> 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D]
> 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed
> 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime)
> 5) The old CH is broadcast in newest topology, no rebalance happens
> 6) Inconsistency: read in X may miss the update
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4919:
------------------------------------
[~pferraro] the way I see it, this issue is about allowing multiple inheritance "roots" instead of forcing all the caches to inherit from the default cache. But I'm only thinking about the embedded configuration, for the server configuration it's probably different.
I imagine {{EmbeddedCacheManager.defineConfiguration(String cacheName, Configuration configuration)}} still won't work once this issue is fixed. You'll still have to {{read()}} the template configuration and apply your changes on the clone, just like the XML parser does now with the default cache configuration.
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-4919:
------------------------------------
[~dan.berindei] Doesn't that contradict the premise of this jira? I thought the point of this jira was to support a feature of the programmatic API that isn't supported by the XML configuration. But now you seem to be saying the opposite, hence my confusion.
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4979:
-----------------------------------------------
William Burns <wburns(a)redhat.com> changed the Status of [bug 1163573|https://bugzilla.redhat.com/show_bug.cgi?id=1163573] from ASSIGNED to POST
> CacheStatusResponse map uses too much memory
> --------------------------------------------
>
> Key: ISPN-4979
> URL: https://issues.jboss.org/browse/ISPN-4979
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.1.0.Alpha1, 7.1.0.Final
>
>
> When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory.
> We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5019:
-----------------------------------------------
William Burns <wburns(a)redhat.com> changed the Status of [bug 1163573|https://bugzilla.redhat.com/show_bug.cgi?id=1163573] from ASSIGNED to POST
> After coordinator change, cache topologies should be installed in parallel
> --------------------------------------------------------------------------
>
> Key: ISPN-5019
> URL: https://issues.jboss.org/browse/ISPN-5019
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Beta1
>
>
> When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches.
> We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months