hmm... hmmm... :-)
more thoughts on (1) and (2)...
When a node leaves/joins it needs to acquire a lease on the bucket
tables of every node that it intends to move buckets from/to. If two
nodes are doing this at the same time, their requirement will collide
(deadlock) somewhere in the
You can define an order to the semaphores when locking and thereby avoid
a deadlock. If each node being added or terminating itself honors the
order then you will never have a deadlock. However, you still need to
deal with the case of an uncontrolled failure either adding or removing
a note
Joe Bohn wrote:
You can define an order to the semaphores when locking and thereby
avoid a deadlock.
Good idea - If I order the nodes according to some unique id and try for
the lease on their bucket table in the same order, then multiple nodes
trying at the same time should not deadlock...
Hi Jules
At 05:37 AM 7/27/2005, Jules Gosnell wrote:
I agree on the SPoF thing - but I think you misunderstand my
Coordinator arch. I do not have a single static Coordinator node,
but a dynamic Coordinator role, into which a node may be elected.
Thus every node is a potential Coordinator. If
Andy Piper wrote:
Hi Jules
At 05:37 AM 7/27/2005, Jules Gosnell wrote:
I agree on the SPoF thing - but I think you misunderstand my
Coordinator arch. I do not have a single static Coordinator node, but
a dynamic Coordinator role, into which a node may be elected. Thus
every node is a
I've had a look at the Lampson paper, but didn't take it all in on the
first pass - I think it will need some serious concentration. The Paxos
algorithm looks interesting, I will definitely pursue this avenue.
I've also given a little thought to exactly why I need a Coordinator and
how Paxos
hmmm...
now I'm wondering about my solutions to (1) and (2) - if more than one
node tries to join or leave at the same time I may be in trouble - so it
may be safer to go straight to (3) for all cases...
more thought needed :-)
Jules
Jules Gosnell wrote:
I've had a look at the Lampson
Andy Piper wrote:
Hi Jules
It sounds like you've been working hard!
yes - I need a break :-)
I think you might find you run into reliability issues with a
singleton coordinator. This is one of those well known Hard Problems
and for session replication its not really necessary. In
Hi Jules
It sounds like you've been working hard!
I think you might find you run into reliability issues with a singleton
coordinator. This is one of those well known Hard Problems and for session
replication its not really necessary. In essence the coordinator is a
single point of failure
Dain Sundstrom wrote:
This is cool stuff and an excellent intro to your code (you should
put this summary on your website :)
I suggest you start chatting with OpenEJB and ActiveMQ about a shared
session key sooner rather then later as it could take a wile to get
it into their code bases.
This is cool stuff and an excellent intro to your code (you should
put this summary on your website :)
I suggest you start chatting with OpenEJB and ActiveMQ about a shared
session key sooner rather then later as it could take a wile to get
it into their code bases.
I can't wait to see
Guys,
I thought that it was high time that I brought you up to date with my
efforts in building a clustering layer for Geronimo.
The project, wadi.codehaus.org, started as an effort to build a
scalable clustered HttpSession implementation, but in doing this, I
have built components that should
Jules,
This is awesome stuff. I look forward to playing with this stuff in
Geronimo. Let me know if you need a hand with something...
Jeff
Jules Gosnell wrote:
Guys,
I thought that it was high time that I brought you up to date with my
efforts in building a clustering layer for Geronimo.
Jeff Genender wrote:
Jules,
This is awesome stuff. I look forward to playing with this stuff in
Geronimo. Let me know if you need a hand with something...
Thanks for the encouragement, Jeff. It was good to meet you at J1. I'll
give you a shout when things get a little more organised.
14 matches
Mail list logo