[JBoss JIRA] Created: (ISPN-316) Add aliasing capability to DefaultCacheManager
by Brian Stansberry (JIRA)
Add aliasing capability to DefaultCacheManager
----------------------------------------------
Key: ISPN-316
URL: https://jira.jboss.org/jira/browse/ISPN-316
Project: Infinispan
Issue Type: Feature Request
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 4.1.0.CR1
The JBoss AS impl of the JBC CacheManager supports aliasing of cache configuration names. DefaultCacheManager can do the same. Helpful for preserving configuration compatibility across releases, e.g. an EJB3 bean class annotated with @CacheConfig(name="jboss.cache:service=EJB3SFSBClusteredCache") to work in AS 4.2 still works in AS 5 because I made "jboss.cache:service=EJB3SFSBClusteredCache" an alias for "sfsb-cache".
This doesn't affect the CacheManager API; it's an implementation detail; just inject a map of aliases and then resolve any unknown configuration names against it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (ISPN-673) Stopped cache still causing RPC timeouts on caller.
by Paul Ferraro (JIRA)
Stopped cache still causing RPC timeouts on caller.
---------------------------------------------------
Key: ISPN-673
URL: https://jira.jboss.org/browse/ISPN-673
Project: Infinispan
Issue Type: Bug
Components: RPC
Affects Versions: 4.2.0.ALPHA2
Reporter: Paul Ferraro
Assignee: Manik Surtani
Revision 2384 of org.infinispan.remoting.InboundInvocationHandlerImpl adds an 30 second wait loop for stopped caches, causing RPCs to timeout. For a stopped cache, GlobalComponentRegistry.getNamedComponentRegistry(...) returns null, since its global component registry entry is removed during ComponentRegistry.stop(), yet isDefined(...) will still return true. When not using strict peer to peer, this delay is inappropriate and causes the RPC to timeout.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (ISPN-670) Consider all entries from data container as eviction candidates
by Vladimir Blagojevic (JIRA)
Consider all entries from data container as eviction candidates
---------------------------------------------------------------
Key: ISPN-670
URL: https://jira.jboss.org/browse/ISPN-670
Project: Infinispan
Issue Type: Bug
Components: Eviction
Affects Versions: 4.2.0.ALPHA2, 4.1.0.Final
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
There was a subtle change of eviction semantics starting with 4.1 where only immortal entries are considered as eviction candidates. By default all entries are immortal, that is, their expiration and lifespan are -1. As soon as mortal entries are used (expiration !=-1 || lifespan !=-1) they are not subject to eviction policies and container size can grow above limit specified in maxEntries.
This policy is confusing and it does not make a lot of sense. All candidates, both mortal and immortal should be considered as eviction candidates and as such subject to eviction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years