Hotrod - removeIfUnmodified request
by Mircea Markus
Hi,
At the moment, removeIfUnmodified looks like follows: [header][key length][key][lifespan][max idle][entry_version][value length][value]
Does it make sense to also send maxidle and lifespan for a remove operation?
Cheers,
Mircea
16 years
factorizing some code in CacheDelegate
by Mircea Markus
Hi,
All the methods that support eviction(maxIdle) and expiration(timeToLive) have 3 versions. E.g.
put(k,v, maxIdle, timeToLive);
put(k,v, maxIdle);
put(k,v);
version 2 and 3 delegate to version 1, using default values.
This logic can be re-used in RemoteCache. I'm thinking to create an abstract class (CacheSupport implements Cache) that would take care of all these delegations and will be extended by both CacheDelegate and RemoteCacheImple.
Advantage: code re-use and nicer-looking (sexier as one would say) CacheDelegate and RemoteCacheImpl.
No API changes needed.
Wdyt?
Cheers,
Mircea
16 years
async operations
by Mircea Markus
E.g.
public NotifyingFuture<Boolean> removeAsync(Object key;
I think these might be quite useful for hotrod as well, especially given the fact that operation duration is longer than in the case of "local" caches. Wdyt?
Cheers,
Mircea
16 years
hotrod's RemoteCacheManager
by Mircea Markus
Hi,
While presenting the hot rod client java API in Brno, we agreed to use a RemoteCacheManager that would implement CacheManager (similar to the way in which DefaultCacheManager implements CacheManager; it is used for clients from the same namespace).
Looking at the CacheManager interface[1], most of the methods that do not make sense on the RemoteCacheManager: defineConfiguration, getClusterName, getAddress, isCoordinator, getStatus, getGlobalConfiguration, getDefaultConfiguration and getCacheNames.
The only two methods that really make sense are: getCache() and getCache(cacheName:String). So here are some thoughts I have about having RemoteCacheManager implementing CacheManager.
1. Approach 1 - throw exceptions for the unsupported methods. Not a very nice approach IMO, given the fact that most of the methods fall in this category, which would make the API a bit unusable
2. Approach 2 - do not extend it. This would result in a clearer API
3. Approach 2 - Extract the two getCache methods in an super interface (CacheHolder, CacheRepository, ??) and have both CacheManager and RemoteCacheManager implement it - this one I like the most as it encourages reusability and keeps the API clean.
Thoughts?
Cheers,
Mircea
[1] http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/in...
16 years
Eviction redesign
by Vladimir Blagojevic
Hey,
As a part of new eviction design for 4.1.0 we might require a slight DataContainer API change. Eviction in 4.1.0 will be piggybacked on user threads; current default option using a dedicated eviction thread from EvictionManager is maintained. Option to choose eviction approach will be configurable.
If we are evicting on a dedicated thread (as we are in the current design) then we would have to rely on iteration of DataContainer entries to evict them (i.e that is the contract between EvictionManagerImpl and DataContainer). In order to support current design I'd have to implement iterator that returns evicted entries along with other non evicted entries. Iterator should put evicted elements prior to non-evicted elements (so EvictionManager would actually pick evicted entries for eviction). Continuing support of this contract feels like a kludge...
A better solution seems to be adding a following method to DataContainer:
Iterator<InternalCacheEntry> getEvictionCandidates()
By default, we would return list of entries that were evicted and collected by attached listener to BoundedConcurrentHashMap. If eviction is done on user thread this iterator would be empty, just as it would be empty in case of UnboundedContainer. getEvictionCandidates method would be a new contract between EvictionManager and DataContainer. Method iterator() would therefore return actual non-evicted entries in eviction enabled BoundedContainer and all elements for UnboundedContainer. This approach keeps iterator() contract valid for all containers at the expense of breaking DataContainer API.
Note that BoundedConcurrentHashMap is a lock amortized eviction enabled version of ConcurrentHashMap. BoundedDataContainer is a new container that will implement LRU and LIRS eviction algorithm. SimpleDataContainer will be renamed to UnboundedDataContainer. FIFO eviction will default to LRU. Other data containers (in current repository) will be deprecated/removed.
If you have any comments/ objections speak up.
Regards,
Vladimir
16 years
A mechanism for users to control data locality when using DIST
by Manik Surtani
So there have been some requests for this ability [1], and although I did blog about some strategies to achieve this [2], one of which Brian plans to employ for HTTP session state in JBoss AS 6, I think this is something generally useful and a simpler "user" solution should be offered. Annotations won't work for a number of reasons (mainly because this affinity information should be associated with a key instance, not a key class). So here is what I propose, from an API perspective:
put(K, V) is overloaded with put(K, V, String group). "group" is an arbitrary, user-defined string, and it is up to the API user to ensure these are unique, and related entries are properly grouped.
Note that this is similar in some ways to another JIRA proposed by Mindaugas Žakšauskas some months ago: ISPN-312 [3].
In terms of implementation, I expect we could add a DataAffinityInterceptor which would:
* for puts, instead of putting (K, V) in the cache, it would put (group, AtomicMap) and (K, group) in the cache, and (K, V) in the AtomicMap. Similar behaviour for other writes.
* for gets, instead of retrieving (K), from the cache, it would retrieve K to get the group id, and then retrieve the atomic map related to the group before retrieving the key.
The effect of this is to hide the complexities of interacting with AtomicMaps from users by providing a convenience API.
What do people think?
Cheers
Manik
[1] https://jira.jboss.org/jira/browse/ISPN-359
[2] http://infinispan.blogspot.com/2009/08/distribution-instead-of-buddy.html
[3] https://jira.jboss.org/jira/browse/ISPN-312
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years
vint for key/value size
by Mircea Markus
Hi Galder,
Currently the size of a key (value) is an 5 bytes vint.
The max size of an int (4byte) in java is 2^31 -1. So the max size of an byte array is (2^31 -1).
An 5 bytes vint can be > 2^31, e.g. vint (10000000, 10000000, 10000000, 10000000, 01000000) == 2^34 > greater than Integer.MAX_VALUE. This means that if a client will sends a message with this size(2^34 or greater) we won't be able to put it on a single byte array.
Not sure that will happen, as 2^31 is already 2048MB which is a lot already :), but for correctness sake I guess we can specify that the key size is an 5 bytes vint, but not bigger than 2^31-1.
Similar for the longs we use.
Wdyt?
Cheers,
Mircea
16 years
Updates to Hot Rod protocol spec
by Galder Zamarreno
http://community.jboss.org/docs/DOC-14421
As part of meetings we had this week, we discussed the following changes
to the spec:
- Bring back piggybacking for cluster and hash information. Asynchronous
events for use cases such as client side L1 will be implemented at a later
stage.
- Ping command was added so that clients can verify whether server is
still responding.
- Removed force write lock, skip remote lookup and force asynchronous
flags and added a flag that can force commands like put to return the old
value.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
Hot Rod: To be or not to be transactional and flags
by Galder Zamarreno
Hi,
While writing some tests for the Hot Rod server, the following came to my
mind: Are we gonna enable clients to being/commit/rollback transactions
remotely? The simple answer is: No, since if we were to do this properly,
you'd have to get clients to participate in the transaction and this is
quite a complex thing to do based on my experience wrt EJB user
transactions started from remote clients.
In this case, the following flags do not make sense in the Hot Rod case:
FORCE_WRITE_LOCK -> there's no transaction, so a read acquiring a WL would
be useless
The following are bit dubious but still potentially useful because the
lock acquisitions would be per call, so locks would be acquired for a
pretty short period of time:
ZERO_LOCK_ACQUISITION_TIMEOUT
SKIP_LOCKING
I think the rest of flags do make sense but might require some renaming:
- CACHE_MODE_LOCAL- you could still want to store something in one node
only even if the hot rod servers are replicated/distributed.
- SKIP_CACHE_STATUS_CHECK - as it is.
- FORCE_SYNCHRONOUS - this could make sense. clients, as well as waiting
for response, want to know that it was replicated/distributed correctly in
asynch configured hot rod servers.
- SKIP_CACHE_STORE - as it is, clients might to avoid writing to the cache
store.
- SKIP_REMOTE_LOOKUP - as it is but would need renaming
- PUT_FOR_EXTERNAL_READ - as it is.
- FAIL_SILENTLY - as it is.
Finally, some might not make sense:
- FORCE_ASYNCHRONOUS - this does not make sense, clients can simply not
wait for response and that would be asynchronous for them.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years
