...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Mircea Markus
Sent: Tuesday, June 04, 2013 5:44 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Suppressing state transfer via JMX
Manik, what's wrong with Dan's suggestion with clearing the cache before
shutdown
, June 04, 2013 5:44 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Suppressing state transfer via JMX
Manik, what's wrong with Dan's suggestion with clearing the cache before
shutdown?
On 31 May 2013, at 14:20, Manik Surtani msurt...@redhat.com wrote:
If we only want to deal
: Tuesday, June 04, 2013 5:44 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Suppressing state transfer via JMX
Manik, what's wrong with Dan's suggestion with clearing the cache before
shutdown?
On 31 May 2013, at 14:20, Manik Surtani msurt...@redhat.com wrote:
If we only
redundancy.
Erik
-Original Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Mircea
Markus
Sent: Tuesday, June 04, 2013 5:44 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Suppressing state transfer via
It didn't solve the issue for partial shutdown. And doesn't solve the issue
for starting up nodes. You still have a mesh of messages attempting to
coordinate the transfer of a null state.
On 4 Jun 2013, at 10:44, Mircea Markus mmar...@redhat.com wrote:
Manik, what's wrong with Dan's
-boun...@lists.jboss.org] On Behalf Of Mircea Markus
Sent: Tuesday, June 04, 2013 5:44 AM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Suppressing state transfer via JMX
Manik, what's wrong with Dan's suggestion with clearing the cache before
shutdown?
On 31 May 2013, at 14:20, Manik Surtani
Manik, what's wrong with Dan's suggestion with clearing the cache before
shutdown?
On 31 May 2013, at 14:20, Manik Surtani msurt...@redhat.com wrote:
If we only want to deal with full cluster shutdown, then I think stopping
all application requests, calling Cache.clear() on one node, and
Sounds good, although I think ISPN-3140 should remain in its current scope and
just address point 1 below. We can create a separate JIRA for point 2, since I
think even point 1 on its own is useful for some use cases (as you say, where
data loss isn't a concern).
On 31 May 2013, at 17:40,
Guys
We've discussed ISPN-3140 elsewhere before, I'm brining it to this forum now.
https://issues.jboss.org/browse/ISPN-3140
Any thoughts/concerns? Particularly looking to hear from Dan or Adrian about
viability, complexity, ease of implementation.
Thanks
Manik
--
Manik Surtani
If we only want to deal with full cluster shutdown, then I think stopping
all application requests, calling Cache.clear() on one node, and then
shutting down all the nodes should be simpler. On start, assuming no cache
store, the caches will start empty, so starting all the nodes at once and
only
ISPN-3140 only mentions suspending state transfer. The partial cluster
shutdown scenario is part of ISPN-1394. Doesn't it make sense to merge them?
Cheers
Adi
On 05/31/2013 03:52 PM, Dan Berindei wrote:
If we only want to deal with full cluster shutdown, then I think
stopping all application
On 31 May 2013, at 14:12, Adrian Nistor anis...@redhat.com wrote:
ISPN-3140 only mentions suspending state transfer. The partial cluster
shutdown scenario is part of ISPN-1394. Doesn't it make sense to merge them?
ISPN-3140 (manually suppressing state transfer) is regardless of partial or
On 31 May 2013, at 13:52, Dan Berindei dan.berin...@gmail.com wrote:
If we only want to deal with full cluster shutdown, then I think stopping all
application requests, calling Cache.clear() on one node, and then shutting
down all the nodes should be simpler. On start, assuming no cache
Yes, ISPN-1394 has a broader scope but the proposed solution for
ISPN-3140 solves quite a lot of ISPN-1394 and it's not complex. We might
not even need ISPN-1394 soon unless somebody really wants to control
data ownership down to segment granularity. If we only want to batch
joins/leaves and
I see 2 potential issues:
1. How does the user know which node is the master to connect to, since
the operations are a no-op on all the others?
- instead of a no-op, what if the other nodes just forward the
operation to the correct node?
Then the user doesn't have to know who the
The coordinator is the first member of the jgroups view, which is easy
to obtain via jmx from any node, but you do make a valid point. We
should remove this strain from the admin and automate a bit. I like the
forwarding idea.
Excluding the coordinator should not be a problem. After this is
A little correction in my previous email is need. When I said Note that
if suppressRehashing==false operation excludeNodes(..) just queues ...
I actualy meant to say suppressRehashing==true.
On 05/31/2013 07:40 PM, Adrian Nistor wrote:
Yes, ISPN-1394 has a broader scope but the proposed
17 matches
Mail list logo
