[JBoss JIRA] (ISPN-8954) StateReceiverImpl should request segments via an executor
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8954?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8954:
-------------------------------
Status: Open (was: New)
> StateReceiverImpl should request segments via an executor
> ---------------------------------------------------------
>
> Key: ISPN-8954
> URL: https://issues.jboss.org/browse/ISPN-8954
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.1.Final
>
>
> Currently when requesting segments an InboundTransferTask is executed in the thread calling StateReceiver::getAllReplicasForSegment. The problem with this is that InboundTransferTask::requestSegments is a blocking RPC call, which due to the synchronization used by a SegmentRequest object means that it's not possible for a segment request to be cancelled while an InboundTransferTask::requestSegment call is being executed. Furthermore, this situation is exasperated by the fact that currently the transfer tasks are created using the state transfer timeout (defualt is 4 mins), so it's possible for the calling thread to be blocked for this amount of time.
> The solution is to utilise the StateTransferExecutor to process the InboundTransferTasks so that a segment request can be cancelled during a transfer request. Also, we should utilise the remaining time of the DefaultConflictManager::ReplicaSpliterator as the upper bound on the transfer tasks.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8908) Remote cache fails to get entries when state transfer is turned off
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-8908?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo reassigned ISPN-8908:
---------------------------------
Assignee: Pedro Ruivo
> Remote cache fails to get entries when state transfer is turned off
> -------------------------------------------------------------------
>
> Key: ISPN-8908
> URL: https://issues.jboss.org/browse/ISPN-8908
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 9.2.0.Final
> Reporter: Vojtech Juranek
> Assignee: Pedro Ruivo
>
> When state transfer is turned off, remote cache fails to obtain cache entries from HR server (in client-server mode) which connects to the cluster. Only about half of the entries can be seen by HR client on newly connected server, both in replicated cache and distributed cache.
> It's not specific to CS mode, same problem is also in embedded mode.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8942) Joiners may miss registered listener
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8942?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8942:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.1.Final
Resolution: Done
> Joiners may miss registered listener
> ------------------------------------
>
> Key: ISPN-8942
> URL: https://issues.jboss.org/browse/ISPN-8942
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.2.1.Final
>
>
> Since the change where the cluster listener registration is send to the cache-members, the following scenario can happen:
> {noformat}
> [NODE_C] 2018-03-14 12:19:23,823 -> received topology with {A,B}. requests listeners from A
> [NODE_D] 2018-03-14 12:19:23,824 -> received topology with {A,B}. requests listeners from A
> [NODE_B] 2018-03-14 12:19:23,926 -> register cluster listener A, B
> [NODE_A] 2018-03-14 12:19:23,931 -> register cluster listener from B
> {noformat}
> Possible fix is to fetch the cluster listener when it is member of the topology.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8942) Joiners may miss registered listener
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8942?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8942:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5841
> Joiners may miss registered listener
> ------------------------------------
>
> Key: ISPN-8942
> URL: https://issues.jboss.org/browse/ISPN-8942
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.2.1.Final
>
>
> Since the change where the cluster listener registration is send to the cache-members, the following scenario can happen:
> {noformat}
> [NODE_C] 2018-03-14 12:19:23,823 -> received topology with {A,B}. requests listeners from A
> [NODE_D] 2018-03-14 12:19:23,824 -> received topology with {A,B}. requests listeners from A
> [NODE_B] 2018-03-14 12:19:23,926 -> register cluster listener A, B
> [NODE_A] 2018-03-14 12:19:23,931 -> register cluster listener from B
> {noformat}
> Possible fix is to fetch the cluster listener when it is member of the topology.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8946) All collection wrappers should always delegate to underlying collections where available
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8946?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-8946:
-------------------------------------
So the more I thought about this I could handle the locking by adding methods to the various locking interceptors. But then this still doesn't fix issues with notifications as well. Although currently some notifications don't work with the various collections (ie. CacheEntryVisited). I am kinda thinking the latter is fine though, as long as we can guarantee write notifications are at least sent.
> All collection wrappers should always delegate to underlying collections where available
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-8946
> URL: https://issues.jboss.org/browse/ISPN-8946
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: William Burns
> Assignee: William Burns
>
> All places that override values returned from keySet and entrySet should always delegate appropriately to the underlying keySet or entrySet. We should try to be as minimally invasive to each level down as possible. An example would be that we shouldn't create copies of said collections if possible and instead just use delegates.
> https://github.com/infinispan/infinispan/pull/5794#discussion_r173789766
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8959) Infinispan occasionally fails to locate an entry in a cache store when using a bounded data container
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8959?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8959:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.1.Final
Resolution: Done
> Infinispan occasionally fails to locate an entry in a cache store when using a bounded data container
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-8959
> URL: https://issues.jboss.org/browse/ISPN-8959
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Eviction
> Affects Versions: 9.2.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 9.2.1.Final
>
>
> If a Cache.get(...) needs to load an entry from the cache store, it uses the PersistenceUtil.loadAndStoreInDataContainer(...) method.
> This method utilizes a DataContainer.compute(...) operation. However, when the data container is backed by a caffeine BoundedLocalCache, the key of the ComputeAction may not be the same as the key from the command, since caffeine wraps keys with an object (e.g. weak reference) which uses the hashCode returned by System.identityHashCode(...). Since loadAndStoreInDataContainer(...) method calls the loadAndCheckExpiration(...) method using the key from the ComputeAction instead of the key from the command, it these instances are not the same, it will fail to locate the entry in the cache store.
> While I have yet to successfully create a reproducer, I've verified the situation in the WF testsuite using the following failed assertion:
> {noformat}
> public static <K, V> InternalCacheEntry<K,V> loadAndStoreInDataContainer(DataContainer<K, V> dataContainer, final PersistenceManager persistenceManager,
> K key, final InvocationContext ctx, final TimeService timeService,
> final AtomicReference<Boolean> isLoaded) {
> final ByRef<Boolean> expired = new ByRef<>(null);
> InternalCacheEntry<K,V> entry = dataContainer.compute(key, (k, oldEntry, factory) -> {
> //under the lock, check if the entry exists in the DataContainer
> if (oldEntry != null) {
> if (isLoaded != null) {
> isLoaded.set(null); //not loaded
> }
> if (oldEntry.canExpire() && oldEntry.isExpired(timeService.wallClockTime())) {
> expired.set(Boolean.TRUE);
> return oldEntry;
> }
> return oldEntry; //no changes in container
> }
> assert key == k : "Expected key type " + key.getClass().getName() + " but compute action uses " + k.getClass().getName();
> MarshalledEntry loaded = loadAndCheckExpiration(persistenceManager, k, ctx, timeService);
> if (loaded == null) {
> if (isLoaded != null) {
> isLoaded.set(Boolean.FALSE); //not loaded
> }
> return null; //no changed in container
> }
> InternalCacheEntry<K, V> newEntry = convert(loaded, factory);
> if (isLoaded != null) {
> isLoaded.set(Boolean.TRUE); //loaded!
> }
> return newEntry;
> });
> if (expired.get() == Boolean.TRUE) {
> return null;
> } else {
> return entry;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-7045) Fix interrupt handling during CacheStore.purge(...)
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-7045?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned ISPN-7045:
----------------------------------
Assignee: (was: Paul Ferraro)
> Fix interrupt handling during CacheStore.purge(...)
> ---------------------------------------------------
>
> Key: ISPN-7045
> URL: https://issues.jboss.org/browse/ISPN-7045
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.2.4.Final
> Reporter: Paul Ferraro
>
> During cache shutdown, any persistence threads are interrupted. Some cache stores, e.g. JdbcBinaryStore, inappropriately rethrow InterruptedExceptions as PersistenceExceptions, which then get logged as ERROR by the ExpirationManager.
> Other cache stores, e.g. SingleFileStore, don't handle/react to interrupts at all!
> I haven't looked at every cache store implementation, but the problem seems widespread.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8959) Infinispan occasionally fails to locate an entry in a cache store when using a bounded data container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-8959?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-8959:
-------------------------------
Description:
If a Cache.get(...) needs to load an entry from the cache store, it uses the PersistenceUtil.loadAndStoreInDataContainer(...) method.
This method utilizes a DataContainer.compute(...) operation. However, when the data container is backed by a caffeine BoundedLocalCache, the key of the ComputeAction may not be the same as the key from the command, since caffeine wraps keys with an object (e.g. weak reference) which uses the hashCode returned by System.identityHashCode(...). Since loadAndStoreInDataContainer(...) method calls the loadAndCheckExpiration(...) method using the key from the ComputeAction instead of the key from the command, it these instances are not the same, it will fail to locate the entry in the cache store.
While I have yet to successfully create a reproducer, I've verified the situation in the WF testsuite using the following failed assertion:
{noformat}
public static <K, V> InternalCacheEntry<K,V> loadAndStoreInDataContainer(DataContainer<K, V> dataContainer, final PersistenceManager persistenceManager,
K key, final InvocationContext ctx, final TimeService timeService,
final AtomicReference<Boolean> isLoaded) {
final ByRef<Boolean> expired = new ByRef<>(null);
InternalCacheEntry<K,V> entry = dataContainer.compute(key, (k, oldEntry, factory) -> {
//under the lock, check if the entry exists in the DataContainer
if (oldEntry != null) {
if (isLoaded != null) {
isLoaded.set(null); //not loaded
}
if (oldEntry.canExpire() && oldEntry.isExpired(timeService.wallClockTime())) {
expired.set(Boolean.TRUE);
return oldEntry;
}
return oldEntry; //no changes in container
}
assert key == k : "Expected key type " + key.getClass().getName() + " but compute action uses " + k.getClass().getName();
MarshalledEntry loaded = loadAndCheckExpiration(persistenceManager, k, ctx, timeService);
if (loaded == null) {
if (isLoaded != null) {
isLoaded.set(Boolean.FALSE); //not loaded
}
return null; //no changed in container
}
InternalCacheEntry<K, V> newEntry = convert(loaded, factory);
if (isLoaded != null) {
isLoaded.set(Boolean.TRUE); //loaded!
}
return newEntry;
});
if (expired.get() == Boolean.TRUE) {
return null;
} else {
return entry;
}
}
{noformat}
was:
If a Cache.get(...) needs to load an entry from the cache store, it uses the PersistenceUtil.loadAndStoreInDataContainer(...) method.
This method utilizes a DataContainer.compute(...) operation. However, when the data container is backed by a caffeine BoundedLocalCache, the key of the ComputeAction may not be the same as the key from the command, since caffeine wraps keys with an object (e.g. weak reference) which uses the hashCode returned by System.identityHashCode(...). Since loadAndStoreInDataContainer(...) method calls the loadAndCheckExpiration(...) method using the key from the ComputeAction instead of the key from the command, it these instances are not the same, it will fail to locate the entry in the cache store.
> Infinispan occasionally fails to locate an entry in a cache store when using a bounded data container
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-8959
> URL: https://issues.jboss.org/browse/ISPN-8959
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Eviction
> Affects Versions: 9.2.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> If a Cache.get(...) needs to load an entry from the cache store, it uses the PersistenceUtil.loadAndStoreInDataContainer(...) method.
> This method utilizes a DataContainer.compute(...) operation. However, when the data container is backed by a caffeine BoundedLocalCache, the key of the ComputeAction may not be the same as the key from the command, since caffeine wraps keys with an object (e.g. weak reference) which uses the hashCode returned by System.identityHashCode(...). Since loadAndStoreInDataContainer(...) method calls the loadAndCheckExpiration(...) method using the key from the ComputeAction instead of the key from the command, it these instances are not the same, it will fail to locate the entry in the cache store.
> While I have yet to successfully create a reproducer, I've verified the situation in the WF testsuite using the following failed assertion:
> {noformat}
> public static <K, V> InternalCacheEntry<K,V> loadAndStoreInDataContainer(DataContainer<K, V> dataContainer, final PersistenceManager persistenceManager,
> K key, final InvocationContext ctx, final TimeService timeService,
> final AtomicReference<Boolean> isLoaded) {
> final ByRef<Boolean> expired = new ByRef<>(null);
> InternalCacheEntry<K,V> entry = dataContainer.compute(key, (k, oldEntry, factory) -> {
> //under the lock, check if the entry exists in the DataContainer
> if (oldEntry != null) {
> if (isLoaded != null) {
> isLoaded.set(null); //not loaded
> }
> if (oldEntry.canExpire() && oldEntry.isExpired(timeService.wallClockTime())) {
> expired.set(Boolean.TRUE);
> return oldEntry;
> }
> return oldEntry; //no changes in container
> }
> assert key == k : "Expected key type " + key.getClass().getName() + " but compute action uses " + k.getClass().getName();
> MarshalledEntry loaded = loadAndCheckExpiration(persistenceManager, k, ctx, timeService);
> if (loaded == null) {
> if (isLoaded != null) {
> isLoaded.set(Boolean.FALSE); //not loaded
> }
> return null; //no changed in container
> }
> InternalCacheEntry<K, V> newEntry = convert(loaded, factory);
> if (isLoaded != null) {
> isLoaded.set(Boolean.TRUE); //loaded!
> }
> return newEntry;
> });
> if (expired.get() == Boolean.TRUE) {
> return null;
> } else {
> return entry;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8959) Infinispan occasionally fails to locate an entry in a cache store when using a bounded data container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-8959?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-8959:
-------------------------------
Description:
If a Cache.get(...) needs to load an entry from the cache store, it uses the PersistenceUtil.loadAndStoreInDataContainer(...) method.
This method utilizes a DataContainer.compute(...) operation. However, when the data container is backed by a caffeine BoundedLocalCache, the key of the ComputeAction may not be the same as the key from the command, since caffeine wraps keys with an object (e.g. weak reference) which uses the hashCode returned by System.identityHashCode(...). Since loadAndStoreInDataContainer(...) method calls the loadAndCheckExpiration(...) method using the key from the ComputeAction instead of the key from the command, it these instances are not the same, it will fail to locate the entry in the cache store.
was:
If a Cache.get(...) needs to load an entry from the cache store, it uses the PersistenceUtil.loadAndStoreInDataContainer(...) method.
The method utilizes a DataContainer.compute(...) operation. However, when the data container is backed by a caffeine BoundedLocalCache, the key of the ComputeAction will not be the same as the key from the command, since caffeine uses weak references for keys which use the hashCode returned by System.identityHashCode(...). Since loadAndStoreInDataContainer(...) method calls the loadAndCheckExpiration(...) method using the key from the ComputeAction instead of the key from the command, it will fail to locate the entry in the cache store.
> Infinispan occasionally fails to locate an entry in a cache store when using a bounded data container
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-8959
> URL: https://issues.jboss.org/browse/ISPN-8959
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Eviction
> Affects Versions: 9.2.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
>
> If a Cache.get(...) needs to load an entry from the cache store, it uses the PersistenceUtil.loadAndStoreInDataContainer(...) method.
> This method utilizes a DataContainer.compute(...) operation. However, when the data container is backed by a caffeine BoundedLocalCache, the key of the ComputeAction may not be the same as the key from the command, since caffeine wraps keys with an object (e.g. weak reference) which uses the hashCode returned by System.identityHashCode(...). Since loadAndStoreInDataContainer(...) method calls the loadAndCheckExpiration(...) method using the key from the ComputeAction instead of the key from the command, it these instances are not the same, it will fail to locate the entry in the cache store.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years