[JBoss JIRA] (ISPN-11129) High Availability for non-shared indexes on DIST caches
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11129?page=com.atlassian.jira.plugi... ]
Work on ISPN-11129 started by Gustavo Fernandes.
------------------------------------------------
> High Availability for non-shared indexes on DIST caches
> -------------------------------------------------------
>
> Key: ISPN-11129
> URL: https://issues.redhat.com/browse/ISPN-11129
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> 'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers.
> For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data.
> But non-shared indexes has some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels:
> * Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing
> * Querying: query broadcast is currently used for non-shared indexes. If replicated entries start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11183) Clustered Max Idle should not have to catch TimeoutException for optimistic writes
by Will Burns (Jira)
Will Burns created ISPN-11183:
---------------------------------
Summary: Clustered Max Idle should not have to catch TimeoutException for optimistic writes
Key: ISPN-11183
URL: https://issues.redhat.com/browse/ISPN-11183
Project: Infinispan
Issue Type: Bug
Reporter: Will Burns
Assignee: Will Burns
ISPN-11020 introduced a new implementation of clustered max idle. Due to how locking in optimistic transactions work and the fact that we try to limit the number of expiration removals for a key it can cause a deadlock. To work around this we ensure that reads use a lock acquisition timeout of 0 and catch and check the exception for a TimeoutException. Exception checking is inherently error prone as the cause/supression of exceptions can change very easily as well as the exception could be thrown for a different reason. We should convert this by possibly changing OptimisticLockingInterceptor to return something different if a lock occurs with a lock acquisition timeout of 0.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11157) Optimistic Transaction ignores ZERO_LOCK_ACQUISITION flag
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11157?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11157:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.1.1.Final
(was: 11.0.0.Final)
Resolution: Done
> Optimistic Transaction ignores ZERO_LOCK_ACQUISITION flag
> ---------------------------------------------------------
>
> Key: ISPN-11157
> URL: https://issues.redhat.com/browse/ISPN-11157
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Final
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> When a command or set of commands are sent via the PrepareCommand with optimistic transactions they attempt to lock the entry at that point. Unfortunately the Flag is not adhered to and always uses the default lock timeout. We should check if all WriteCommands have the flag and if so use a timeout 0 instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11109) Deprecate and remove usages of state-transfer-executor
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11109?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11109:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.1.1.Final
Resolution: Done
> Deprecate and remove usages of state-transfer-executor
> ------------------------------------------------------
>
> Key: ISPN-11109
> URL: https://issues.redhat.com/browse/ISPN-11109
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 10.1.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> With ISPN-10310, {{StateConsumerImpl}} applies state asynchronously, so a thread pool specifically for applying state is no longer necessary.
> There are some other users remaining, but they can be migrated to the transport executor.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months