FlagAffectedCommand interface hierarchy (ISPN-761)
by William Burns
While adding changes for cache methods (entrySet, keySet, values, size) to include passivated entries it had been pointed out to conditionally do these operations if flags such as SKIP_CACHE_STORE and SKIP_CACHE_LOAD were provided. Also does anyone have any feedback on if both flags should apply or just say SKIP_CACHE_STORE? Currently SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand do not inherit from FlagAffectedCommand which are used for commands that behavior is dependent upon flags.
The problem is that FlagAffectedCommand currently extends VisitableCommand, TopologyAffectedCommand, MetadataAwareCommand interfaces. These interfaces do not really apply to the commands I am working on as they are local only. I was planning on removing the extended interfaces from the FlagAffectedCommand interface and update all the commands that implement this interface currently to make sure they still properly implement the additional interfaces. Searching for instanceof FlagAffectedCommand it also appears that all current references should be alright after refactoring. Once these interfaces are decoupled I can add the FlagAffectedCommand interface to the SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand and subsequently to the CommandFactory and my changes should be good.
Any opinions or concerns?
Thanks,
- Will
11 years, 6 months
CommandAwareRpcDispatcher desired logic
by Pedro Ruivo
Hi all,
//related to https://issues.jboss.org/browse/ISPN-3100
In here [1] I've added three simple tests to the CARD logic with the
ResponseFilter.
#1 testResponses() => tests if all the responses are returned. This test
is failing because the FutureCollactor only returns the last response.
*question* is this the desired behaviour or is it a bug (and this test
is incorrect)?
#2 testTimeout() => tests the timeout when a ResponseFilter is used. It
sets the timeout to 1000 milliseconds and sends a command that sleeps
for 5000 millisecond before reply. This test is failing because no
TimeoutException was thrown (as expected). That's why I've created
ISPN-3100.
*question* is the desired behaviour to wait infinitely? If yes, then
ISPN-3100 is invalid.
#3 testTimeoutWithoutFilter() => tests the timeout without a filter.
It's working correctly!
Thanks!
Cheers,
Pedro
[1]
https://github.com/pruivo/infinispan/commit/1fc26d740b773bf3864298615f61c...
11 years, 6 months
Fwd: still to do on HR-embedded integration in ISPN-2281
by Mircea Markus
Hi Martin,
The server memory consumption should improve now that we have ISPN-2281 integrated. would it be possible to run the memory consumption tests to see where we are?
Begin forwarded message:
>> I've just integrated the implementation for ISPN-2281 - great stuff!
>>
>>
>> As this is a very intrusive change it is important to know to measure the gain in memory consumption. i.e. would be great to see some figures on memory usage before this optimisation and after it in your blog post.
>
> ^ QE guys have some memory tests already, why don't we get them to re-run those tests? :)
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11 years, 6 months
Supporting notifications for entries expired while in the cache store - ISPN-694
by Galder Zamarreño
Hi,
Re: https://issues.jboss.org/browse/ISPN-694
We've got a little problem here. Paul requires that entries that might have been expired while in the cache store, when loaded, we send expiration notifications for them.
The problem is that expiration checking is currently done in the actual cache store implementations, which makes supporting this (even outside the purgeExpired business) specific to each cache store. Not ideal.
The alternative would be for CacheLoaderInterceptor to load, do the checks and then remove the entries accordingly. The big problem here is that you're imposing a way to deal with expiration handling for all cache store implementations, and some might be able to do these checks and removals in a more efficient way if they were left to do it themselves. For example, having to load all entries and then decide which are to expire might require a lot of work, instead of potentially communicating directly with the cache store (imagine a remote cache store…) and asking it to return all the entries filtered by those whose expiry has not expired.
However, even if a cache store can do that, it would lead to loading only those entries not expired, but then how do you send the notifications if those expired entries have been filtered out? You probably need multiple load methods here...
@Paul, do you really need this for your use case?
The simplest thing to do might be to go for option 1, and let each cache store send notifications for expired entries for the moment, and then in 6.0 revise not only the API for purgeExpired, but also the API for load/loadAll() to find a way that, if any expiry listeners are in place, a different method can be called on the cache store that signals it to return all entries: both expired and non-expired, and then let the CacheLoaderInterceptor send notifications from a central location.
Thoughts?
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
11 years, 6 months
Infinispan DEF - Custom parameters upon a failover
by Strahinja Lazetic
Hi,
I am currently using Infinispan
Distributed Execution Framework for my Master thesis project and I am
wondering if it is possible that a DistributedCallable receives some
custom parameters from the framework upon a failover, besides Cache
instance and Set of keys passed in the setEnvironment method. As a
simplified example, a DistributedCallable wants to know whether it
was restarted or freshly started. If this is not possible, does it
make sense to add a new method to the DistributedTaskFailoverPolicy
which will return a user supplied parameters Map and then read it
from the setEnvironment method in the DistributedCallable? Here are
the signatures of the methods I was thinking off:
In the DistributedTaskFailoverPolicy
class:
Map<Object, Object>
getEnvironmentParameters()
In the DistributedCallable class:
setEnvironment(Cache<K, V> cache,
Set<K> inputKeys, Map<Object, Object> params)
I was free to try to implement this and
did not take to much time, so now I am wondering if there was already
a way to do something like this in the Infinispan DEF.
Thank you in advance for your comments
and suggestions.
Strahinja Lazetic
11 years, 6 months
