-
1. Re: Hot Rod Clarifications
galder.zamarreno Jul 27, 2010 2:58 AM (in response to shane_dev)As part of CR2, https://jira.jboss.org/browse/ISPN-516 and https://jira.jboss.org/browse/ISPN-539 were implemented which enabled both preloading and fetchPersistentState to be used with RemoteCacheStore. Your code should not be calling to the CacheStore API.
If your Hot Rod client is a part of remote cache store, then it means that any local modifications will be transfered to the remote Hot Rod servers. You only risk stale entries if the Infinispan instances on the client side are not clustered cos they won't know about each others modifications. IOW, you need your Infinispan instances in 1 and 2 clients to be clustered to avoid stale reads. These two better be in a different cluster to the Hot Rod cluster to avoid mixing up traffic.
ISPN-374 (https://jira.jboss.org/browse/ISPN-374) plans to include notifications on a per key basis. The forum thread linked from the JIRA explains it better.
The remote cache store is intended as a more persistent store where data can survive to crashes in your main nodes. In a way, it can act as a L1 with only data recently used (having eviction configured). If data cannot be found in the main Infinispan instances, it can be retrieved from the backed remote cache store.
Generally, you keep the remote cache store nodes in separate machines to the client side Infinispan instances, so that data can survive node failures.
-
2. Re: Hot Rod Clarifications
shane_dev Aug 4, 2010 3:10 PM (in response to galder.zamarreno)Can you clarify if fetchInMemoryState is now supported?
I was looking at the documentation and it seems mixed.
http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/loaders/remote/RemoteCacheStore.html
"Due to certain HotRod constraints, this cache store does not support preload and also cannot be used for provide state. Setting fetchPersistentState is not allowed."
https://jira.jboss.org/browse/ISPN-516
"This would not load not the entire state, but up to N entries."
http://community.jboss.org/wiki/HotRodBulkGet-Design
"Following method won't be supported by RemoteCacheStore (see Manik's first comment for more details on why this is not supported): public Set<Object> loadAllKeys(Set<Object> keysToExclude)"
"entry count [vint] : maximum number of Infinispan entries to be returned by the server (entry == key + associated value). Needed to support CacheLoader.load(int). If 0 then all entries are returned (needed for CacheLoader.loadAll())."
"The same logic and code from state generation, in case of in memory state retrieval can be used <stateRetrieval fetchInMemoryState="true"/>"
"No locking is performed: this is fast but consistency might suffer."
Jira Issues: 516 & 539 (Hot Rod / RemoteCacheStore - State Transfer)
Both are resolved.
It seems like there are 3 different views on this matter:
- State Transfer is NOT Supported.
- State Transfer is LIMITED to N Entries.
- State Transfer is FULLY Supported.
-
3. Re: Hot Rod Clarifications
galder.zamarreno Aug 5, 2010 5:29 AM (in response to shane_dev)It looks to me that the RemoteCacheStore javadoc has not been updated. Back in CR1 (http://anonsvn.jboss.org/repos/infinispan/tags/4.1.0.CR1/cachestore/remote/src/main/java/org/infinispan/loaders/remote/RemoteCacheStore.java), toStream/fromStream were not implemented and hence at that point fetching persistent state was not supported. However, in CR2, this was resolved (http://anonsvn.jboss.org/repos/infinispan/tags/4.1.0.CR2/cachestore/remote/src/main/java/org/infinispan/loaders/remote/RemoteCacheStore.java) and hence this should be updated.
With bulk gets Hot Rod can retrieve all, or a number of, elements.
-
4. Re: Hot Rod Clarifications
shane_dev Aug 5, 2010 9:56 AM (in response to galder.zamarreno)Thanks Galder,
I had assumed that was the case, but after looking at the documentation I wanted to confirm before we headed down the Hot Rod course.
One thing that caught my interest was the quote on inconsistency.
"No locking is performed: this is fast but consistency might suffer."
It got me to wondering, is this at all related to the state transfer / repl queue issue we have been discussing? I realize this is from the Hot Rod article but I figure it applies to non block state transfer in general. Or, perhaps it is specific to the Hot Rod state transfer.