[JBoss JIRA] (ISPN-6007) Cache.get(...) using Flag.FORCE_WRITE_LOCK should retry on OutdatedTopologyException
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6007?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6007:
-------------------------------
Status: Open (was: New)
> Cache.get(...) using Flag.FORCE_WRITE_LOCK should retry on OutdatedTopologyException
> ------------------------------------------------------------------------------------
>
> Key: ISPN-6007
> URL: https://issues.jboss.org/browse/ISPN-6007
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.2.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Fix For: 8.1.0.Final, 8.0.3.Final
>
>
> From IRC:
> pferraro: Following a shutdown of a node, we're seeing OutdatedTopologyExceptions during a Cache.get(...) using Flag.FORCE_WRITE_LOCK when the requested key is not owned by the requesting node
> pferraro: is there a reason why Infinispan doesn't automatically retry here?
> dberindei: I think we just overlooked it
> dberindei: we are retrying a LockControlCommand when you call lock() explicitly
> dberindei: but maybe not when it's invoked for a get()
> pferraro_: is that something that can be fixed easily?
> dberindei: yes, I think so
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-6007) Cache.get(...) using Flag.FORCE_WRITE_LOCK should retry on OutdatedTopologyException
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-6007:
----------------------------------
Summary: Cache.get(...) using Flag.FORCE_WRITE_LOCK should retry on OutdatedTopologyException
Key: ISPN-6007
URL: https://issues.jboss.org/browse/ISPN-6007
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.0.2.Final
Reporter: Paul Ferraro
Assignee: Dan Berindei
Fix For: 8.1.0.Final, 8.0.3.Final
>From IRC:
pferraro: Following a shutdown of a node, we're seeing OutdatedTopologyExceptions during a Cache.get(...) using Flag.FORCE_WRITE_LOCK when the requested key is not owned by the requesting node
pferraro: is there a reason why Infinispan doesn't automatically retry here?
dberindei: I think we just overlooked it
dberindei: we are retrying a LockControlCommand when you call lock() explicitly
dberindei: but maybe not when it's invoked for a get()
pferraro_: is that something that can be fixed easily?
dberindei: yes, I think so
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-5786) Provide ability to rename a cache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5786?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-5786.
---------------------------------
Resolution: Won't Do
We will implement the cache alias approach instead as described in ISPN-6006
> Provide ability to rename a cache
> ---------------------------------
>
> Key: ISPN-5786
> URL: https://issues.jboss.org/browse/ISPN-5786
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Reporter: Van Halbert
>
> Provide the ability to rename a cache.
> The benefit of this would enable the primary cache to remain available while a secondary cache gets totally refreshed. And once the refresh is complete, perform the cache rename. This would eliminate the down time of the primary cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months