[JBoss JIRA] (ISPN-8892) RemoteStore should only implement CacheLoader
by William Burns (JIRA)
William Burns created ISPN-8892:
-----------------------------------
Summary: RemoteStore should only implement CacheLoader
Key: ISPN-8892
URL: https://issues.jboss.org/browse/ISPN-8892
Project: Infinispan
Issue Type: Task
Components: Loaders and Stores
Reporter: William Burns
Assignee: William Burns
Fix For: 9.3.0.Final
The RestStore is redundant since a user could just use the RemoteStore which performs better for pretty much every operation. The only real usage for RestStore is if you wanted to pull data from an existing server and wanted to cache that data. As such we should change RestStore to just implement the CacheLoader interface.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-8741) ClusteredLockSplitBrainTest fails randomly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8741?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8741:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.Final
Resolution: Done
> ClusteredLockSplitBrainTest fails randomly
> ------------------------------------------
>
> Key: ISPN-8741
> URL: https://issues.jboss.org/browse/ISPN-8741
> Project: Infinispan
> Issue Type: Bug
> Components: Clustered Locks
> Affects Versions: 9.2.0.CR1
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Fix For: 9.2.0.Final
>
>
> When it works
> ====
> node A acquires the lock
> Split brain of [A] [B, C, D]
> Meanwhile, node B tries to acquire the lock, which is not free, so the request goes to the pending queue of B.
> With the view change listener, B calls unlock for A.
> The listener of B is notified that the lock is released.
> Retries for B
> It works, and A can't do anything else because it's not in the majority partition.
> When it fails
> ====
> node A acquires the lock
> Split brain of [A] [B, C, D]
> Meanwhile, node B tries to acquire the lock, which is not free, so the request goes to the pending queue of B.
> With the view change listener, B calls unlock for A.
> The listener of B is notified that the lock is released.
> Retries for B
> It fails, because it says that actually the lock is still with locked by A in node D, but it is available in Node B and C.
> Another unlock is retried for Node D, and this works, and still tries to unlock B and C, which fail because now thy are locked by B.
> This gets on the limbo and the request is expired by the scheduler.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months