On 10 Jun 2011, at 13:42, Manik Surtani wrote:
So I've taken on this sub-task from Sanne (ISPN-1169), and here is the deal:
BCHM analyses whether or not to evict stuff every time an operation (put,
get, replace) is run, based on the configured eviction policy (LIRS, LRU or
NONE). It
2) with async stores, the issue is back. The value is not going to be
found while it's in flight in the async storage queue; so unless you
want to avoid supporting it for now, the actual removal from the
container should be performed from the async cache loader code.
Ugh - yes, I agree.
On 17 Jun 2011, at 11:09, Mircea Markus wrote:
2) with async stores, the issue is back. The value is not going to be
found while it's in flight in the async storage queue; so unless you
want to avoid supporting it for now, the actual removal from the
container should be performed from
On 17 Jun 2011, at 11:03, Mircea Markus wrote:
2) EvictionStrategies ensure passivation occurs *before* removing an entry
from the BCHM
Does this cover the following scenario?
1. thread1.get determines that K needs to be passivated
2. thread2 remove(k) removes it from memory
3.
On 9 Jun 2011, at 15:26, Manik Surtani wrote:
We use partial state transfer not to generate partial state per cache, but
the entire state per cache, but since we have 1 cache sharing a given
JGroups channel, as far as JGroups in concerned this *is* partial state of a
node. I.e., the
On 6/17/11 2:49 PM, Mircea Markus wrote:
Now this might sound a bit too radical but do we really need REPLICATED mode?
This is not fully brewed, but if e.g. we set numOwners = Integer.MAX_INTEGER
the cluster is effectively in replicated mode, so can't we just drop the
REPLICATION
On Wed, 2011-06-01 at 16:46 +0200, Bela Ban wrote:
On 6/1/11 4:21 PM, Sanne Grinovero wrote:
Hi Bela,
2011/6/1 Bela Banb...@redhat.com:
We currently use JGroups' partial state transfer to transfer individual
caches from one Infinispan instance to another.
Since I got rid of
