[
https://jira.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.sys...
]
Paul Ferraro edited comment on ISPN-761 at 11/8/10 12:51 PM:
-------------------------------------------------------------
I opened this issue primarily because the behavior of these methods is functionally
different than it was in JBC. In JBC, the result of Cache.getChildrenNames() (as well as
Cache.getKeys()) included contents of the cache store.
The use case: During startup, the distributed web session manager fetches all session ids
from the distributed cache (via Cache.keySet()) to initialize its session statistics - and
to determine which sessions ought to be expired, passivated, etc. The latter is only
necessary because the AS uses its own expiration/passivation mechanism rather than
infinispan's. We can workaround this limitation by instructing users to enable
preload if they want to disable purgeOnStartup (by default, we enable purgeOnStartup) -
although this is more likely to cause an OOM than a cache loader aware keySet() impl
would.
In my opinion, it is would be more functionally consistent, thus generally appropriate,
for these methods to reflect the contents of the cache store - despite the performance
impact. Users should have the option to optimize these calls via Flag.SKIP_CACHE_LOAD.
At any rate, enabling preload is an acceptable enough workaround at the present.
was (Author: pferraro):
I opened this issue primarily because the behavior of these methods is functionally
different than it was in JBC. In JBC, the result of Cache.getChildrenNames() (as well as
Cache.getKeys()) included contents of the cache store.
The use case: During startup, the distributed web session manager fetches all session ids
from the distributed cache (via Cache.keySet()) to initialize it's session statistics
- and to determine which sessions ought to be expired, passivated, etc. The latter is
only necessary because the distributed web session manager uses the AS's own
expiration/passivation mechanism rather than infinispan's internal expiration logic.
We can workaround this limitation by instructing users to enable preload if they want to
disable purgeOnStartup (by default, we enable purgeOnStartup) - although this is more
likely to cause an OOM than a cache loader aware keySet() impl would.
In my opinion, it is would be more functionally consistent, thus generally appropriate,
for these methods to reflect the contents of the cache store - despite the performance
impact. Users should have the option to optimize these calls via Flag.SKIP_CACHE_LOAD.
At any rate, enabling preload is an acceptable enough workaround at the present.
Cache.keySet(),entrySet(),values(),size() ignore contents of cache
loader
-------------------------------------------------------------------------
Key: ISPN-761
URL:
https://jira.jboss.org/browse/ISPN-761
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.BETA1
Reporter: Paul Ferraro
Assignee: Manik Surtani
Passivated cache entries are not represented in values returned by the keySet(),
entrySet(), values(), and size() Cache methods. This results in inconsistent behavior,
since it is possible that a given cache key may not be contained in keySet() even though
Cache.get(...) would return a non-null value if the entry was previously passivated.
I think CacheLoaderInterceptor needs to implement the following methods:
Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws
Throwable
Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws
Throwable
Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws
Throwable
--
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