[JBoss JIRA] (ISPN-9082) Off Heap maxIdle expiration is not implemented
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-9082?page=com.atlassian.jira.plugin... ]
Will Burns updated ISPN-9082:
-----------------------------
Summary: Off Heap maxIdle expiration is not implemented (was: Off Heap maxIdle expiration works like lifespan)
> Off Heap maxIdle expiration is not implemented
> ----------------------------------------------
>
> Key: ISPN-9082
> URL: https://issues.redhat.com/browse/ISPN-9082
> Project: Infinispan
> Issue Type: Bug
> Components: Expiration, Off Heap
> Affects Versions: 9.2.1.Final
> Reporter: Will Burns
> Priority: Major
>
> Due to the usage of read/write locks Off Heap cannot easily update the last access time of an off heap entry. It would have to release the read lock and try to acquire the write lock to then finally update the last access time of an object. We would also have to guarantee the address pointer hadn't changed between when the read and write lock were obtained, since the value could have changed during that time period.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[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)
6 years, 2 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)
6 years, 2 months