On 6/20/11 10:02 PM, Manik Surtani wrote:
5.1 is possible, 5.0 would be very tough.
Fine with me then; this gives me more time for 3.0
What are the implications for our current implementation on 5.0 though?
State going missing?
No, Infinispan 5.0 uses JGroups 2.12.x, which still has
On 21 Jun 2011, at 07:01, Bela Ban wrote:
What are the implications for our current implementation on 5.0 though?
State going missing?
No, Infinispan 5.0 uses JGroups 2.12.x, which still has partial state.
Yes, but I was asking about the inconsistency in the design of partial state
5.1 is possible, 5.0 would be very tough.
What are the implications for our current implementation on 5.0 though? State
going missing?
On 16 Jun 2011, at 17:56, Bela Ban wrote:
Correct. Time frame would ideally be 5.0, but realistically it will
probably be 5.1. Is that feasible from a
On 17 Jun 2011, at 13:49, Mircea Markus wrote:
But yes, there is no reason why we can't replace this with RPC as per
Distribution, however I think we do need a streaming solution - not just for
replication but distribution as well. As such I'd only want to re-implement
this bit once,
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
Correct. Time frame would ideally be 5.0, but realistically it will
probably be 5.1. Is that feasible from a roadmap point of view ?
On 6/16/11 6:47 PM, Vladimir Blagojevic wrote:
In another words the essential problem is that digest and channel state
are per channel abstractions and they do
I looked into adding partial state transfer back into JGroups, but found
out that partial state transfer is fundamentally flawed, something I've
always suspected ! (Regular state transfer is correct, and has always
been correct).
- Say we have node A and B. B requests the state from A
- There
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 state of just 1 cache on a channel, not all the caches.
We currently use JGroups' partial state transfer to transfer individual
caches from one Infinispan instance to another.
Since I got rid of partial state transfer in JGroups 3.0, and don't like
to add it back, I'd like to know whether this is still needed.
I thought that we currently require
Hi Bela,
2011/6/1 Bela Ban b...@redhat.com:
We currently use JGroups' partial state transfer to transfer individual
caches from one Infinispan instance to another.
Since I got rid of partial state transfer in JGroups 3.0, and don't like
to add it back, I'd like to know whether this is still
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 partial state transfer in JGroups 3.0, and don't like
to add it
Why are we actually using JGroups' state transfer with replication, but
use our own state transfer with distribution ?
I don't know, but guess it's because each node has a different set of
keys so no node has the same state as another ?
You could still use JGroups state transfer;
On 6/1/11 6:05 PM, Mircea Markus wrote:
Why are we actually using JGroups' state transfer with replication, but
use our own state transfer with distribution ?
I don't know, but guess it's because each node has a different set of
keys so no node has the same state as another ?
You could
15 matches
Mail list logo
