You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Jeff Genender <jg...@apache.org> on 2007/06/11 23:04:02 UTC
The clustering discussion - again ;-)
Ok...so now that we have passed the TCK...I can get back and concentrate
on some fun stuff, so I wanted to bring up the old discussion again of
getting a clustering API pinned up on OpenEJB. The whole idea on this
is to allow different clustering components to tie into the product.
Before I stopped and did TCK testing, I got as far as adding the ability
to handle multiple URLs in the client/server to allow for failover.
Now that I am getting back to the meat of the design here, I wanted to
go over at a high level of the direction I am taking this.
1) The client need to get an initial list of servers in the cluster. I
assume this can occur during the first initial context handshake.
2) A version number is applied and sent along with the list.
3) Every time the client speaks to the server is sends along the version
number. If the version is different, the server sends down a new list,
along with the new version number.
4) The server updates the list only when the servers in the cluster have
changed.
Thoughts and comments?
Jeff
Re: The clustering discussion - again ;-)
Posted by Dain Sundstrom <da...@iq80.com>.
On Jun 12, 2007, at 10:20 AM, Jeff Genender wrote:
> Dain Sundstrom wrote:
>> If the version number isn't shared amongst all servers, then I would
>> think the version number will need to contain a server identifier to
>> avoid the case where the client fails over and old (dead) server
>> happened to be on the same version as the new server.
>
> Why would this matter? If the client knows its failing over, it
> signals
> this and gets the whole list and the updated version number from the
> server. Is a server identifier really necessary?
Well, that would be another way to implement it. I was assuming that
when there is a fail over the client simply begins to talk to the new
server. If you design it to have a new custom messages in the
protocol, the sky's the limit. If you want to stick the initial
protocol messages, I don't believe there is a way to signal a
"failing over".
The clustering systems I have seen tend to have a global cluster
version number as a side effect of the cluster communication
protocol, so people using these tend to simply send them to the
client. Having no idea what the cluster protocol looks like, I guess
it was a bad assumption you would have one.
-dain
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Dain Sundstrom wrote:
> If the version number isn't shared amongst all servers, then I would
> think the version number will need to contain a server identifier to
> avoid the case where the client fails over and old (dead) server
> happened to be on the same version as the new server.
Why would this matter? If the client knows its failing over, it signals
this and gets the whole list and the updated version number from the
server. Is a server identifier really necessary?
>
> -dain
Re: The clustering discussion - again ;-)
Posted by Dain Sundstrom <da...@iq80.com>.
On Jun 12, 2007, at 7:55 AM, Jeff Genender wrote:
>
>
> Mohammad Nour El-Din wrote:
>> Sounds good to me, but how this version is going to be shared
>> among all
>> servers ?
>
> The client is usually sticky to a particular server (EJB by nature
> enforces this), therefore it doesn't matter. The client only cares
> about the version number with reference to the server its speaking to.
>
> If a client needs to fail-over to a new server, it will get a new list
> and version number...so I believe it works...but good question
> nevertheless. ;-)
If the version number isn't shared amongst all servers, then I would
think the version number will need to contain a server identifier to
avoid the case where the client fails over and old (dead) server
happened to be on the same version as the new server.
-dain
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Mohammad Nour El-Din wrote:
> Sounds good to me, but how this version is going to be shared among all
> servers ?
The client is usually sticky to a particular server (EJB by nature
enforces this), therefore it doesn't matter. The client only cares
about the version number with reference to the server its speaking to.
If a client needs to fail-over to a new server, it will get a new list
and version number...so I believe it works...but good question
nevertheless. ;-)
Jeff
>
> On 6/12/07, Jeff Genender <jg...@apache.org> wrote:
>>
>> Ok...so now that we have passed the TCK...I can get back and concentrate
>> on some fun stuff, so I wanted to bring up the old discussion again of
>> getting a clustering API pinned up on OpenEJB. The whole idea on this
>> is to allow different clustering components to tie into the product.
>>
>> Before I stopped and did TCK testing, I got as far as adding the ability
>> to handle multiple URLs in the client/server to allow for failover.
>>
>> Now that I am getting back to the meat of the design here, I wanted to
>> go over at a high level of the direction I am taking this.
>>
>> 1) The client need to get an initial list of servers in the cluster. I
>> assume this can occur during the first initial context handshake.
>>
>> 2) A version number is applied and sent along with the list.
>>
>> 3) Every time the client speaks to the server is sends along the version
>> number. If the version is different, the server sends down a new list,
>> along with the new version number.
>>
>> 4) The server updates the list only when the servers in the cluster have
>> changed.
>>
>> Thoughts and comments?
>>
>> Jeff
>>
>
>
>
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Sounds good to me, but how this version is going to be shared among all
servers ?
On 6/12/07, Jeff Genender <jg...@apache.org> wrote:
>
> Ok...so now that we have passed the TCK...I can get back and concentrate
> on some fun stuff, so I wanted to bring up the old discussion again of
> getting a clustering API pinned up on OpenEJB. The whole idea on this
> is to allow different clustering components to tie into the product.
>
> Before I stopped and did TCK testing, I got as far as adding the ability
> to handle multiple URLs in the client/server to allow for failover.
>
> Now that I am getting back to the meat of the design here, I wanted to
> go over at a high level of the direction I am taking this.
>
> 1) The client need to get an initial list of servers in the cluster. I
> assume this can occur during the first initial context handshake.
>
> 2) A version number is applied and sent along with the list.
>
> 3) Every time the client speaks to the server is sends along the version
> number. If the version is different, the server sends down a new list,
> along with the new version number.
>
> 4) The server updates the list only when the servers in the cluster have
> changed.
>
> Thoughts and comments?
>
> Jeff
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by David Blevins <da...@visi.com>.
On Jun 12, 2007, at 3:35 PM, Jeff Genender wrote:
>
>
> David Blevins wrote:
>> I think that might have been an Amelia "no" (i.e. a yes).
>
> Hehe! I know that "No" too ;-)
>
>> You saying
>> you like the idea of the server sending the md5 down and having the
>> client simply send it back, no inspection on the client side --
>> i.e. the
>> version number idea from before but sending the md5 as we would have
>> sent the version number? Or are you referring to the same version
>> number idea as before?
>
> Kind of a hybrid. The MD5 would be the number...that is the "version"
> so-to-speak. Server will check if that number matches its own (it was
> calculated when it first had a cluster setup). If they are the same,
> its business as usual. If the cluster changes, then the server
> changes
> its number and then there is a difference the next time the client
> comes
> knocking. Thus an update will occur.
>
> The reason why I like to use the MD5 as the version number is all
> servers theoretically would calculate the same MD5 (or even a simpler
> lighter algo) and thus always have the same version number w/o
> having to
> share that between all servers.
Cool, that's what i was saying. The version idea where the md5 is
the version. We're on the same page.
-David
Re: The clustering discussion - again ;-)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
+1 to round robin ... options are good and based on Jeff's speedy
coding style has probably already implemented it :)
On Jun 14, 2007, at 1:47 PM, Manu George wrote:
> Yes I understand that random will work but how about others like round
> robin etc? Are we planning to support only the random strategy?
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Cool...I saw some of the stuff in OEJB2, cleaned some of it up and put
in OEJB3...in particular, the URL list...I did that a while ago ;-)
I can put the JIRAs together...and it would be cool to all take shots at
the issues. You did a good job of pointing out some of the stuff we
need below.
Thanks,
Jeff
Gianny Damour wrote:
> At some stage, OpenEJB2 had some clustering stuff through WADI:
> * When an EJB client was interacting with a node, on the way-back of
> invocations or JNDI lookups, it was provided with a list of nodes
> hosting the EJB targeted by the invocations or lookups;
> * EJB clients were able to fail-over to other nodes if the primary
> server was down;
> * WADI was able to move statefull session beans from server to server.
>
> This support has been removed as WADI's API was too unstable (a lot of
> refactoring happened over the last months) and the implementation was
> "not yet ready" for integration. I believe both of these problems are
> now addressed :)
>
> Thanks,
> Gianny
>
> On 17/06/2007, at 5:33 PM, Mohammad Nour El-Din wrote:
>
>> Actually the WADI site says that OpenEJB support is underway, is this
>> related to what we discuss here ???
>>
>> On 6/17/07, Mohammad Nour El-Din <no...@gmail.com> wrote:
>>>
>>> Good pint Gianny, actually u maid me think about a new idea, can we
>>> extend
>>> WADI - http://incubator.apache.org/wadi/index.html - so it can play
>>> as our
>>> clustering infrastructure ???. Jeff comments ???
>>>
>>> On 6/16/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>>> >
>>> > On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
>>> >
>>> > > Awesome! Your help would be very much appreciated.
>>> > >
>>> > > I am flushing out the API now and I can post a patch (or just
>>> > > commit it)
>>> > > and we can alter it as need be.
>>> > >
>>> > > Should we start by talking about the SPI/API and maybe just start
>>> > > posting the interfaces?
>>> > Hello,
>>> >
>>> > It would be great to start with such a SPI/API. Also, do you think
>>> > that you can propose the same SPI/API for Geronimo? There is already
>>> > an API there, which is sufficient for the clustering of HTTP
>>> > sessions; and I suspect it now needs to be improved to support the
>>> > clustering of stateful session beans.
>>> >
>>> > Please, fell free to post JIRAs or something somewhere with the
>>> > proposed SPI/API such that we can contribute!
>>> >
>>> > Thanks,
>>> > Gianny
>>> >
>>> >
>>> > >
>>> > > Jeff
>>> >
>>> >
>>>
>>>
>>> --
>>> Thanks
>>> - Mohammad Nour
>>
>>
>>
>>
>> --
>> Thanks
>> - Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Gianny Damour <gi...@optusnet.com.au>.
At some stage, OpenEJB2 had some clustering stuff through WADI:
* When an EJB client was interacting with a node, on the way-back of
invocations or JNDI lookups, it was provided with a list of nodes
hosting the EJB targeted by the invocations or lookups;
* EJB clients were able to fail-over to other nodes if the primary
server was down;
* WADI was able to move statefull session beans from server to server.
This support has been removed as WADI's API was too unstable (a lot
of refactoring happened over the last months) and the implementation
was "not yet ready" for integration. I believe both of these problems
are now addressed :)
Thanks,
Gianny
On 17/06/2007, at 5:33 PM, Mohammad Nour El-Din wrote:
> Actually the WADI site says that OpenEJB support is underway, is this
> related to what we discuss here ???
>
> On 6/17/07, Mohammad Nour El-Din <no...@gmail.com> wrote:
>>
>> Good pint Gianny, actually u maid me think about a new idea, can
>> we extend
>> WADI - http://incubator.apache.org/wadi/index.html - so it can
>> play as our
>> clustering infrastructure ???. Jeff comments ???
>>
>> On 6/16/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>> >
>> > On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
>> >
>> > > Awesome! Your help would be very much appreciated.
>> > >
>> > > I am flushing out the API now and I can post a patch (or just
>> > > commit it)
>> > > and we can alter it as need be.
>> > >
>> > > Should we start by talking about the SPI/API and maybe just start
>> > > posting the interfaces?
>> > Hello,
>> >
>> > It would be great to start with such a SPI/API. Also, do you think
>> > that you can propose the same SPI/API for Geronimo? There is
>> already
>> > an API there, which is sufficient for the clustering of HTTP
>> > sessions; and I suspect it now needs to be improved to support the
>> > clustering of stateful session beans.
>> >
>> > Please, fell free to post JIRAs or something somewhere with the
>> > proposed SPI/API such that we can contribute!
>> >
>> > Thanks,
>> > Gianny
>> >
>> >
>> > >
>> > > Jeff
>> >
>> >
>>
>>
>> --
>> Thanks
>> - Mohammad Nour
>
>
>
>
> --
> Thanks
> - Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Actually the WADI site says that OpenEJB support is underway, is this
related to what we discuss here ???
On 6/17/07, Mohammad Nour El-Din <no...@gmail.com> wrote:
>
> Good pint Gianny, actually u maid me think about a new idea, can we extend
> WADI - http://incubator.apache.org/wadi/index.html - so it can play as our
> clustering infrastructure ???. Jeff comments ???
>
> On 6/16/07, Gianny Damour <gi...@optusnet.com.au> wrote:
> >
> > On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
> >
> > > Awesome! Your help would be very much appreciated.
> > >
> > > I am flushing out the API now and I can post a patch (or just
> > > commit it)
> > > and we can alter it as need be.
> > >
> > > Should we start by talking about the SPI/API and maybe just start
> > > posting the interfaces?
> > Hello,
> >
> > It would be great to start with such a SPI/API. Also, do you think
> > that you can propose the same SPI/API for Geronimo? There is already
> > an API there, which is sufficient for the clustering of HTTP
> > sessions; and I suspect it now needs to be improved to support the
> > clustering of stateful session beans.
> >
> > Please, fell free to post JIRAs or something somewhere with the
> > proposed SPI/API such that we can contribute!
> >
> > Thanks,
> > Gianny
> >
> >
> > >
> > > Jeff
> >
> >
>
>
> --
> Thanks
> - Mohammad Nour
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Paulo Lopes <pm...@scratchydreams.com>.
I totally agree, it is better having a strong API with good
foundations, already thinking in all the inherent features of
clustering, session replication, distributed deployment, automatic
discovery, synchronization, server election, etc etc etc... than just
start coding "a basic solution" and spend the time refactoring code to
support new missing features which will break any code that is using
the "basic" infrastructure every time a new feature is added.
On 6/17/07, Gianny Damour <gi...@optusnet.com.au> wrote:
> I think we should try to have an agnostic API, i.e. specific to
> OpenEJB, which can be implemented by any clustering provider. As a
> matter of fact, WADI is one of the many clustering frameworks (other
> frameworks being Terracotta or GCache) interested to provide
> clustering to OpenEJB.
>
> As a side note, WADI has never actually been moved to the Apache
> Incubator. I know it was considered at some stage, hence this web-
> site; however, the move has been stopped. So, the actual site is
> there: http://wadi.codehaus.org/.
>
> Thanks,
> Gianny
>
> On 17/06/2007, at 5:29 PM, Mohammad Nour El-Din wrote:
>
> > Good pint Gianny, actually u maid me think about a new idea, can we
> > extend
> > WADI - http://incubator.apache.org/wadi/index.html - so it can play
> > as our
> > clustering infrastructure ???. Jeff comments ???
> >
> > On 6/16/07, Gianny Damour <gi...@optusnet.com.au> wrote:
> >>
> >> On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
> >>
> >> > Awesome! Your help would be very much appreciated.
> >> >
> >> > I am flushing out the API now and I can post a patch (or just
> >> > commit it)
> >> > and we can alter it as need be.
> >> >
> >> > Should we start by talking about the SPI/API and maybe just start
> >> > posting the interfaces?
> >> Hello,
> >>
> >> It would be great to start with such a SPI/API. Also, do you think
> >> that you can propose the same SPI/API for Geronimo? There is already
> >> an API there, which is sufficient for the clustering of HTTP
> >> sessions; and I suspect it now needs to be improved to support the
> >> clustering of stateful session beans.
> >>
> >> Please, fell free to post JIRAs or something somewhere with the
> >> proposed SPI/API such that we can contribute!
> >>
> >> Thanks,
> >> Gianny
> >>
> >>
> >> >
> >> > Jeff
> >>
> >>
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
>
>
--
Paulo Lopes
www.scratchydreams.com
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On 6/17/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>
> I think we should try to have an agnostic API, i.e. specific to
> OpenEJB, which can be implemented by any clustering provider. As a
> matter of fact, WADI is one of the many clustering frameworks (other
> frameworks being Terracotta or GCache) interested to provide
> clustering to OpenEJB.
Sure, this is what Jeff meaned by providing SPI, to be able to plug any
clustering implementation into OpenEJB.
As a side note, WADI has never actually been moved to the Apache
> Incubator. I know it was considered at some stage, hence this web-
> site; however, the move has been stopped. So, the actual site is
> there: http://wadi.codehaus.org/.
>
> Thanks,
> Gianny
>
> On 17/06/2007, at 5:29 PM, Mohammad Nour El-Din wrote:
>
> > Good pint Gianny, actually u maid me think about a new idea, can we
> > extend
> > WADI - http://incubator.apache.org/wadi/index.html - so it can play
> > as our
> > clustering infrastructure ???. Jeff comments ???
> >
> > On 6/16/07, Gianny Damour <gi...@optusnet.com.au> wrote:
> >>
> >> On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
> >>
> >> > Awesome! Your help would be very much appreciated.
> >> >
> >> > I am flushing out the API now and I can post a patch (or just
> >> > commit it)
> >> > and we can alter it as need be.
> >> >
> >> > Should we start by talking about the SPI/API and maybe just start
> >> > posting the interfaces?
> >> Hello,
> >>
> >> It would be great to start with such a SPI/API. Also, do you think
> >> that you can propose the same SPI/API for Geronimo? There is already
> >> an API there, which is sufficient for the clustering of HTTP
> >> sessions; and I suspect it now needs to be improved to support the
> >> clustering of stateful session beans.
> >>
> >> Please, fell free to post JIRAs or something somewhere with the
> >> proposed SPI/API such that we can contribute!
> >>
> >> Thanks,
> >> Gianny
> >>
> >>
> >> >
> >> > Jeff
> >>
> >>
> >
> >
> > --
> > Thanks
> > - Mohammad Nour
>
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Gianny Damour <gi...@optusnet.com.au>.
I think we should try to have an agnostic API, i.e. specific to
OpenEJB, which can be implemented by any clustering provider. As a
matter of fact, WADI is one of the many clustering frameworks (other
frameworks being Terracotta or GCache) interested to provide
clustering to OpenEJB.
As a side note, WADI has never actually been moved to the Apache
Incubator. I know it was considered at some stage, hence this web-
site; however, the move has been stopped. So, the actual site is
there: http://wadi.codehaus.org/.
Thanks,
Gianny
On 17/06/2007, at 5:29 PM, Mohammad Nour El-Din wrote:
> Good pint Gianny, actually u maid me think about a new idea, can we
> extend
> WADI - http://incubator.apache.org/wadi/index.html - so it can play
> as our
> clustering infrastructure ???. Jeff comments ???
>
> On 6/16/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>>
>> On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
>>
>> > Awesome! Your help would be very much appreciated.
>> >
>> > I am flushing out the API now and I can post a patch (or just
>> > commit it)
>> > and we can alter it as need be.
>> >
>> > Should we start by talking about the SPI/API and maybe just start
>> > posting the interfaces?
>> Hello,
>>
>> It would be great to start with such a SPI/API. Also, do you think
>> that you can propose the same SPI/API for Geronimo? There is already
>> an API there, which is sufficient for the clustering of HTTP
>> sessions; and I suspect it now needs to be improved to support the
>> clustering of stateful session beans.
>>
>> Please, fell free to post JIRAs or something somewhere with the
>> proposed SPI/API such that we can contribute!
>>
>> Thanks,
>> Gianny
>>
>>
>> >
>> > Jeff
>>
>>
>
>
> --
> Thanks
> - Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Good pint Gianny, actually u maid me think about a new idea, can we extend
WADI - http://incubator.apache.org/wadi/index.html - so it can play as our
clustering infrastructure ???. Jeff comments ???
On 6/16/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>
> On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
>
> > Awesome! Your help would be very much appreciated.
> >
> > I am flushing out the API now and I can post a patch (or just
> > commit it)
> > and we can alter it as need be.
> >
> > Should we start by talking about the SPI/API and maybe just start
> > posting the interfaces?
> Hello,
>
> It would be great to start with such a SPI/API. Also, do you think
> that you can propose the same SPI/API for Geronimo? There is already
> an API there, which is sufficient for the clustering of HTTP
> sessions; and I suspect it now needs to be improved to support the
> clustering of stateful session beans.
>
> Please, fell free to post JIRAs or something somewhere with the
> proposed SPI/API such that we can contribute!
>
> Thanks,
> Gianny
>
>
> >
> > Jeff
>
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 15/06/2007, at 6:39 AM, Jeff Genender wrote:
> Awesome! Your help would be very much appreciated.
>
> I am flushing out the API now and I can post a patch (or just
> commit it)
> and we can alter it as need be.
>
> Should we start by talking about the SPI/API and maybe just start
> posting the interfaces?
Hello,
It would be great to start with such a SPI/API. Also, do you think
that you can propose the same SPI/API for Geronimo? There is already
an API there, which is sufficient for the clustering of HTTP
sessions; and I suspect it now needs to be improved to support the
clustering of stateful session beans.
Please, fell free to post JIRAs or something somewhere with the
proposed SPI/API such that we can contribute!
Thanks,
Gianny
>
> Jeff
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Awesome! Your help would be very much appreciated.
I am flushing out the API now and I can post a patch (or just commit it)
and we can alter it as need be.
Should we start by talking about the SPI/API and maybe just start
posting the interfaces?
Jeff
Mohammad Nour El-Din wrote:
> Cool, do u have anything implemented yet or u still working on that ? Cauze
> I want to save us some time, and try to put test cases for it first - if
> applicable - before going into any implementation, so every bit of code of
> this issue can be tested peoperly. Cauze sometimes we do the reverse and
> implement something then test it, and we may find ourselves not being able
> to test, may be cauze of the way we implemented it.
>
> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>>
>> Yep...I think a pluggable policy is the way to go.
>>
>> Jeff
>>
>> Mohammad Nour El-Din wrote:
>> > On 6/14/07, David Blevins <da...@visi.com> wrote:
>> >>
>> >>
>> >> On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
>> >> >
>> >> > Manu George wrote:
>> >> >> Yes I understand that random will work but how about others like
>> >> >> round
>> >> >> robin etc? Are we planning to support only the random strategy?
>> >> >
>> >> > I think we can support whatever policy we want since this is a
>> >> > component
>> >> > of OEJB and not the clustering implementation that is bolted on to
>> it.
>> >> > Round robin and random are both fairly simple to implement.
>> >>
>> >> Round robin super easy to implement and definitely should be an
>> >> option. Random seems more appealing as the default, we can just:
>> >>
>> >> URL nextServer = serverList.get(new Random().nextInt
>> >> (serverList.size()));
>> >
>> >
>> > I am thinking of a more generic solution that can help us now and later
>> > when
>> > we try to make things more complex for real load balancing. I mean the
>> > server list can contain more info about the servers like weights for
>> > example
>> > and the client will have an instance of a policy which will take the
>> server
>> > list and returns the server with which the client is going to
>> communictate
>> > like this
>> >
>> > /*
>> > * We will assume that we have an instance of the RoundRobin policy
>> > */
>> > URL requestHandlerServer = policy.getServer(serverList);
>> >
>> >
>> > In case of the Round Robin policy it will do just like David said. And
>> it
>> > can do more
>> > complicated server election algorithm. Comments ???
>> >
>> >
>> > -David
>> >>
>> >> >
>> >> > Jeff
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>> >> >>>
>> >> >>>
>> >> >>> Manu George wrote:
>> >> >>>> As per what I understood if one of the servers are down then the
>> >> >>>> client will call the next one in the list which would send it a
>> >> >>>> new id
>> >> >>>> after which all calls will be to that one.
>> >> >>>
>> >> >>> You are assuming no policy for how a client chooses a server and
>> >> >>> that
>> >> >>> its linear. Consider it random and this issue goes away.
>> >> >>>
>> >> >>>> But in order to decide
>> >> >>>> which server to pick based on the load balancing strategy used I
>> >> >>>> think
>> >> >>>> we may need more information to be passed to the client. Once
>> this
>> >> >>>> discussion is finished i think we should put this in a wiki page
>> >> >>>> as it
>> >> >>>> provides good insights on clustering and the logic used. I can
>> >> >>>> probably do that if no one else wants it :)
>> >> >>>>
>> >> >>>> Regards
>> >> >>>> Manu
>> >> >>>>
>> >> >>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>> >> >>>>> The idea of id download on the first connection doesn't seem
>> >> >>>>> nice to
>> >> >>>>> me. Assume the following scenario:
>> >> >>>>>
>> >> >>>>> you have a cluster of 3 servers, and the 3 are aware of the
>> >> >>>>> other by
>> >> >>>>> their internal configuration. (no discovery inside the
>> >> >>>>> cluster). The
>> >> >>>>> client receives the list of 3 servers and now has to decide
>> >> >>>>> which one
>> >> >>>>> to connect. It is clear here that the client needs to know some
>> >> >>>>> more
>> >> >>>>> about the server to decide which one to pick in order to share
>> the
>> >> >>>>> load balancing in the cluster, more there is no way for the
>> >> >>>>> client to
>> >> >>>>> know if one of the servers is down and if it is that server is
>> >> >>>>> removed
>> >> >>>>> from the list and never connected again during that request.
>> >> >>>>>
>> >> >>>>> My idea is that perhaps we would better have a small extra
>> >> >>>>> server that
>> >> >>>>> i will call a service dispatcher, that is the central point for
>> >> >>>>> the
>> >> >>>>> cluster. no need to change the openejb code each server still
>> >> >>>>> works in
>> >> >>>>> a isolated way. The SD would have the configurations of where
>> the
>> >> >>>>> openejb nodes are in the cluster and their status (up/down).
>> >> >>>>>
>> >> >>>>> The clients would then connect to the SD and the SD would query
>> >> >>>>> the
>> >> >>>>> list of servers, and forward to the next available one. Metrics
>> >> >>>>> could
>> >> >>>>> be gathered from the SD such as time between query and response
>> >> >>>>> from
>> >> >>>>> OEJB making a simple (not so accurate) load balancer system.
>> >> >>>>>
>> >> >>>>> Paulo
>> >> >>>>>
>> >> >>>
>> >> >
>> >>
>> >>
>> >
>> >
>>
>
>
>
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Cool, do u have anything implemented yet or u still working on that ? Cauze
I want to save us some time, and try to put test cases for it first - if
applicable - before going into any implementation, so every bit of code of
this issue can be tested peoperly. Cauze sometimes we do the reverse and
implement something then test it, and we may find ourselves not being able
to test, may be cauze of the way we implemented it.
On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>
> Yep...I think a pluggable policy is the way to go.
>
> Jeff
>
> Mohammad Nour El-Din wrote:
> > On 6/14/07, David Blevins <da...@visi.com> wrote:
> >>
> >>
> >> On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
> >> >
> >> > Manu George wrote:
> >> >> Yes I understand that random will work but how about others like
> >> >> round
> >> >> robin etc? Are we planning to support only the random strategy?
> >> >
> >> > I think we can support whatever policy we want since this is a
> >> > component
> >> > of OEJB and not the clustering implementation that is bolted on to
> it.
> >> > Round robin and random are both fairly simple to implement.
> >>
> >> Round robin super easy to implement and definitely should be an
> >> option. Random seems more appealing as the default, we can just:
> >>
> >> URL nextServer = serverList.get(new Random().nextInt
> >> (serverList.size()));
> >
> >
> > I am thinking of a more generic solution that can help us now and later
> > when
> > we try to make things more complex for real load balancing. I mean the
> > server list can contain more info about the servers like weights for
> > example
> > and the client will have an instance of a policy which will take the
> server
> > list and returns the server with which the client is going to
> communictate
> > like this
> >
> > /*
> > * We will assume that we have an instance of the RoundRobin policy
> > */
> > URL requestHandlerServer = policy.getServer(serverList);
> >
> >
> > In case of the Round Robin policy it will do just like David said. And
> it
> > can do more
> > complicated server election algorithm. Comments ???
> >
> >
> > -David
> >>
> >> >
> >> > Jeff
> >> >
> >> >
> >> >
> >> >>
> >> >> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >> >>>
> >> >>>
> >> >>> Manu George wrote:
> >> >>>> As per what I understood if one of the servers are down then the
> >> >>>> client will call the next one in the list which would send it a
> >> >>>> new id
> >> >>>> after which all calls will be to that one.
> >> >>>
> >> >>> You are assuming no policy for how a client chooses a server and
> >> >>> that
> >> >>> its linear. Consider it random and this issue goes away.
> >> >>>
> >> >>>> But in order to decide
> >> >>>> which server to pick based on the load balancing strategy used I
> >> >>>> think
> >> >>>> we may need more information to be passed to the client. Once this
> >> >>>> discussion is finished i think we should put this in a wiki page
> >> >>>> as it
> >> >>>> provides good insights on clustering and the logic used. I can
> >> >>>> probably do that if no one else wants it :)
> >> >>>>
> >> >>>> Regards
> >> >>>> Manu
> >> >>>>
> >> >>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> >> >>>>> The idea of id download on the first connection doesn't seem
> >> >>>>> nice to
> >> >>>>> me. Assume the following scenario:
> >> >>>>>
> >> >>>>> you have a cluster of 3 servers, and the 3 are aware of the
> >> >>>>> other by
> >> >>>>> their internal configuration. (no discovery inside the
> >> >>>>> cluster). The
> >> >>>>> client receives the list of 3 servers and now has to decide
> >> >>>>> which one
> >> >>>>> to connect. It is clear here that the client needs to know some
> >> >>>>> more
> >> >>>>> about the server to decide which one to pick in order to share
> the
> >> >>>>> load balancing in the cluster, more there is no way for the
> >> >>>>> client to
> >> >>>>> know if one of the servers is down and if it is that server is
> >> >>>>> removed
> >> >>>>> from the list and never connected again during that request.
> >> >>>>>
> >> >>>>> My idea is that perhaps we would better have a small extra
> >> >>>>> server that
> >> >>>>> i will call a service dispatcher, that is the central point for
> >> >>>>> the
> >> >>>>> cluster. no need to change the openejb code each server still
> >> >>>>> works in
> >> >>>>> a isolated way. The SD would have the configurations of where the
> >> >>>>> openejb nodes are in the cluster and their status (up/down).
> >> >>>>>
> >> >>>>> The clients would then connect to the SD and the SD would query
> >> >>>>> the
> >> >>>>> list of servers, and forward to the next available one. Metrics
> >> >>>>> could
> >> >>>>> be gathered from the SD such as time between query and response
> >> >>>>> from
> >> >>>>> OEJB making a simple (not so accurate) load balancer system.
> >> >>>>>
> >> >>>>> Paulo
> >> >>>>>
> >> >>>
> >> >
> >>
> >>
> >
> >
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Yep...I think a pluggable policy is the way to go.
Jeff
Mohammad Nour El-Din wrote:
> On 6/14/07, David Blevins <da...@visi.com> wrote:
>>
>>
>> On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
>> >
>> > Manu George wrote:
>> >> Yes I understand that random will work but how about others like
>> >> round
>> >> robin etc? Are we planning to support only the random strategy?
>> >
>> > I think we can support whatever policy we want since this is a
>> > component
>> > of OEJB and not the clustering implementation that is bolted on to it.
>> > Round robin and random are both fairly simple to implement.
>>
>> Round robin super easy to implement and definitely should be an
>> option. Random seems more appealing as the default, we can just:
>>
>> URL nextServer = serverList.get(new Random().nextInt
>> (serverList.size()));
>
>
> I am thinking of a more generic solution that can help us now and later
> when
> we try to make things more complex for real load balancing. I mean the
> server list can contain more info about the servers like weights for
> example
> and the client will have an instance of a policy which will take the server
> list and returns the server with which the client is going to communictate
> like this
>
> /*
> * We will assume that we have an instance of the RoundRobin policy
> */
> URL requestHandlerServer = policy.getServer(serverList);
>
>
> In case of the Round Robin policy it will do just like David said. And it
> can do more
> complicated server election algorithm. Comments ???
>
>
> -David
>>
>> >
>> > Jeff
>> >
>> >
>> >
>> >>
>> >> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>> >>>
>> >>>
>> >>> Manu George wrote:
>> >>>> As per what I understood if one of the servers are down then the
>> >>>> client will call the next one in the list which would send it a
>> >>>> new id
>> >>>> after which all calls will be to that one.
>> >>>
>> >>> You are assuming no policy for how a client chooses a server and
>> >>> that
>> >>> its linear. Consider it random and this issue goes away.
>> >>>
>> >>>> But in order to decide
>> >>>> which server to pick based on the load balancing strategy used I
>> >>>> think
>> >>>> we may need more information to be passed to the client. Once this
>> >>>> discussion is finished i think we should put this in a wiki page
>> >>>> as it
>> >>>> provides good insights on clustering and the logic used. I can
>> >>>> probably do that if no one else wants it :)
>> >>>>
>> >>>> Regards
>> >>>> Manu
>> >>>>
>> >>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>> >>>>> The idea of id download on the first connection doesn't seem
>> >>>>> nice to
>> >>>>> me. Assume the following scenario:
>> >>>>>
>> >>>>> you have a cluster of 3 servers, and the 3 are aware of the
>> >>>>> other by
>> >>>>> their internal configuration. (no discovery inside the
>> >>>>> cluster). The
>> >>>>> client receives the list of 3 servers and now has to decide
>> >>>>> which one
>> >>>>> to connect. It is clear here that the client needs to know some
>> >>>>> more
>> >>>>> about the server to decide which one to pick in order to share the
>> >>>>> load balancing in the cluster, more there is no way for the
>> >>>>> client to
>> >>>>> know if one of the servers is down and if it is that server is
>> >>>>> removed
>> >>>>> from the list and never connected again during that request.
>> >>>>>
>> >>>>> My idea is that perhaps we would better have a small extra
>> >>>>> server that
>> >>>>> i will call a service dispatcher, that is the central point for
>> >>>>> the
>> >>>>> cluster. no need to change the openejb code each server still
>> >>>>> works in
>> >>>>> a isolated way. The SD would have the configurations of where the
>> >>>>> openejb nodes are in the cluster and their status (up/down).
>> >>>>>
>> >>>>> The clients would then connect to the SD and the SD would query
>> >>>>> the
>> >>>>> list of servers, and forward to the next available one. Metrics
>> >>>>> could
>> >>>>> be gathered from the SD such as time between query and response
>> >>>>> from
>> >>>>> OEJB making a simple (not so accurate) load balancer system.
>> >>>>>
>> >>>>> Paulo
>> >>>>>
>> >>>
>> >
>>
>>
>
>
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
On 6/14/07, David Blevins <da...@visi.com> wrote:
>
>
> On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
> >
> > Manu George wrote:
> >> Yes I understand that random will work but how about others like
> >> round
> >> robin etc? Are we planning to support only the random strategy?
> >
> > I think we can support whatever policy we want since this is a
> > component
> > of OEJB and not the clustering implementation that is bolted on to it.
> > Round robin and random are both fairly simple to implement.
>
> Round robin super easy to implement and definitely should be an
> option. Random seems more appealing as the default, we can just:
>
> URL nextServer = serverList.get(new Random().nextInt
> (serverList.size()));
I am thinking of a more generic solution that can help us now and later when
we try to make things more complex for real load balancing. I mean the
server list can contain more info about the servers like weights for example
and the client will have an instance of a policy which will take the server
list and returns the server with which the client is going to communictate
like this
/*
* We will assume that we have an instance of the RoundRobin policy
*/
URL requestHandlerServer = policy.getServer(serverList);
In case of the Round Robin policy it will do just like David said. And it
can do more
complicated server election algorithm. Comments ???
-David
>
> >
> > Jeff
> >
> >
> >
> >>
> >> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >>>
> >>>
> >>> Manu George wrote:
> >>>> As per what I understood if one of the servers are down then the
> >>>> client will call the next one in the list which would send it a
> >>>> new id
> >>>> after which all calls will be to that one.
> >>>
> >>> You are assuming no policy for how a client chooses a server and
> >>> that
> >>> its linear. Consider it random and this issue goes away.
> >>>
> >>>> But in order to decide
> >>>> which server to pick based on the load balancing strategy used I
> >>>> think
> >>>> we may need more information to be passed to the client. Once this
> >>>> discussion is finished i think we should put this in a wiki page
> >>>> as it
> >>>> provides good insights on clustering and the logic used. I can
> >>>> probably do that if no one else wants it :)
> >>>>
> >>>> Regards
> >>>> Manu
> >>>>
> >>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> >>>>> The idea of id download on the first connection doesn't seem
> >>>>> nice to
> >>>>> me. Assume the following scenario:
> >>>>>
> >>>>> you have a cluster of 3 servers, and the 3 are aware of the
> >>>>> other by
> >>>>> their internal configuration. (no discovery inside the
> >>>>> cluster). The
> >>>>> client receives the list of 3 servers and now has to decide
> >>>>> which one
> >>>>> to connect. It is clear here that the client needs to know some
> >>>>> more
> >>>>> about the server to decide which one to pick in order to share the
> >>>>> load balancing in the cluster, more there is no way for the
> >>>>> client to
> >>>>> know if one of the servers is down and if it is that server is
> >>>>> removed
> >>>>> from the list and never connected again during that request.
> >>>>>
> >>>>> My idea is that perhaps we would better have a small extra
> >>>>> server that
> >>>>> i will call a service dispatcher, that is the central point for
> >>>>> the
> >>>>> cluster. no need to change the openejb code each server still
> >>>>> works in
> >>>>> a isolated way. The SD would have the configurations of where the
> >>>>> openejb nodes are in the cluster and their status (up/down).
> >>>>>
> >>>>> The clients would then connect to the SD and the SD would query
> >>>>> the
> >>>>> list of servers, and forward to the next available one. Metrics
> >>>>> could
> >>>>> be gathered from the SD such as time between query and response
> >>>>> from
> >>>>> OEJB making a simple (not so accurate) load balancer system.
> >>>>>
> >>>>> Paulo
> >>>>>
> >>>
> >
>
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On 6/15/07, Paulo Lopes <pm...@gmail.com> wrote:
> "the best load balanced solution"? how is that?
>
> Let me start with round robin:
>
> imagine you have OEJBServer1 and OEJBServer2 (in the cluster) and now
> you have like N clients OEJBClient(i).
>
> Say that all the clients only know at start OEJBServer1 and ask then
> the server list:
>
> inside OEJBClient(i) code you have:
> OEJBServer1.getMeTheServerList()
> // this returns a collection with: {OEJBServer1, OEJBServer2}
>
> using the round robin: when asking for the next server all clients will execute:
> theClusterServerList.getNextServer();
> // bad enough for each OEJBClient(i) the answer will be OEJBServer1 to every (i)
>
> This leads to a never used OEJBServer2 and an overloaded OEJBServer1.
>
> Now with Random policy:
>
> When asking for what next server each client might get either a 1 or a
> 2, this spreads the load, but if server1 is for instance already
> serving 1000 requests and server2 5, there is 50% of change that the
> next request goes to server1 who is already overloaded and server2
> stays free.
May be we can use weights based on the current server load (may be
based on some other factors too) to determine the probabilities for
directing the next request to the server randomly. For example, if
server1 is serving 80 requests and server2 20, then you direct the
next request to server1 with 20% (= 1 - (80 / (80+20)) probability and
server2 with 80%.
Vamsi
>
> I think the problem is more complex than asking for a URL collection
> and "pick one".
>
> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> > Right...I would agree random is best as the default since it utilizes
> > the best load balanced solution.
> >
> > Jeff
> >
> > David Blevins wrote:
> > >
> > > On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
> > >>
> > >> Manu George wrote:
> > >>> Yes I understand that random will work but how about others like round
> > >>> robin etc? Are we planning to support only the random strategy?
> > >>
> > >> I think we can support whatever policy we want since this is a component
> > >> of OEJB and not the clustering implementation that is bolted on to it.
> > >> Round robin and random are both fairly simple to implement.
> > >
> > > Round robin super easy to implement and definitely should be an option.
> > > Random seems more appealing as the default, we can just:
> > >
> > > URL nextServer = serverList.get(new
> > > Random().nextInt(serverList.size()));
> > >
> > > -David
> > >
> > >>
> > >> Jeff
> > >>
> > >>
> > >>
> > >>>
> > >>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> > >>>>
> > >>>>
> > >>>> Manu George wrote:
> > >>>>> As per what I understood if one of the servers are down then the
> > >>>>> client will call the next one in the list which would send it a new id
> > >>>>> after which all calls will be to that one.
> > >>>>
> > >>>> You are assuming no policy for how a client chooses a server and that
> > >>>> its linear. Consider it random and this issue goes away.
> > >>>>
> > >>>>> But in order to decide
> > >>>>> which server to pick based on the load balancing strategy used I think
> > >>>>> we may need more information to be passed to the client. Once this
> > >>>>> discussion is finished i think we should put this in a wiki page as it
> > >>>>> provides good insights on clustering and the logic used. I can
> > >>>>> probably do that if no one else wants it :)
> > >>>>>
> > >>>>> Regards
> > >>>>> Manu
> > >>>>>
> > >>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> > >>>>>> The idea of id download on the first connection doesn't seem nice to
> > >>>>>> me. Assume the following scenario:
> > >>>>>>
> > >>>>>> you have a cluster of 3 servers, and the 3 are aware of the other by
> > >>>>>> their internal configuration. (no discovery inside the cluster). The
> > >>>>>> client receives the list of 3 servers and now has to decide which one
> > >>>>>> to connect. It is clear here that the client needs to know some more
> > >>>>>> about the server to decide which one to pick in order to share the
> > >>>>>> load balancing in the cluster, more there is no way for the client to
> > >>>>>> know if one of the servers is down and if it is that server is
> > >>>>>> removed
> > >>>>>> from the list and never connected again during that request.
> > >>>>>>
> > >>>>>> My idea is that perhaps we would better have a small extra server
> > >>>>>> that
> > >>>>>> i will call a service dispatcher, that is the central point for the
> > >>>>>> cluster. no need to change the openejb code each server still
> > >>>>>> works in
> > >>>>>> a isolated way. The SD would have the configurations of where the
> > >>>>>> openejb nodes are in the cluster and their status (up/down).
> > >>>>>>
> > >>>>>> The clients would then connect to the SD and the SD would query the
> > >>>>>> list of servers, and forward to the next available one. Metrics could
> > >>>>>> be gathered from the SD such as time between query and response from
> > >>>>>> OEJB making a simple (not so accurate) load balancer system.
> > >>>>>>
> > >>>>>> Paulo
> > >>>>>>
> > >>>>
> > >>
> >
>
>
> --
> Paulo Lopes
> www.scratchydreams.com
>
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
First, I agree with Jeff that we should start with a simple thing and make
it run, then we can make it bigger and bigger. Second, regarding the for the
deployment thing, although we can consider it something separate than the
implementation of clustering, I mean we can manage this by ourselves for
testing only and after having a running clustering impl we can go and impl
this feature, but I want to add two ideas about it just for the record.
1- Clustered/Distributed naming service, that is when I send a look-up
request to a naming service, and this naming service does not find what I
want, it can get benefit from the cluster infrastructure to locate other
naming services either to redirect the client to it or to play like a
delegate of the client and return back the looked-up object. This is the
expensive solution IMO.
2- Cluster deployment manager, that is we have a cluster deployer, a
deployer which can benefit from the clustering infrastructure to locate all
servers in the cluster to deploy any EJB module being deployed on all of
them. This is the less expensive solution IMO.
But all this depends on providing the clustering infra structure into OEJB,
which we have to make it pluggable as Jeff said, so we can make OpenEJB work
with any clustering implementation.
I think we can provide this the same way Sun specifies services for JEE and
how to integrate them into a Server/Container like JTS/JTA and security
services for JEE. So as Jeff said we have to start stating the SPI for both
how to plugin the clustring infrastructure into OEJB and the server election
policy into the clients/stubs, and the APIs provided for both the server
side and client side to use this clustering infrastructure service.
On 6/15/07, Jeff Genender <jg...@apache.org> wrote:
>
>
>
> Paulo Lopes wrote:
> > Another issue that hasn't been discussed is what happens when the
> > nodes are not synchronized? I deploy a EJB on node #1 but my initial
> > context sends me to node #2... if we are talking about clustering we
> > need also to consider a change on the deployer so it deploys any new
> > EJB on all the nodes of the cluster...
>
> Isn't this a facet of the clustering implementation?
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Paulo Lopes wrote:
> Another issue that hasn't been discussed is what happens when the
> nodes are not synchronized? I deploy a EJB on node #1 but my initial
> context sends me to node #2... if we are talking about clustering we
> need also to consider a change on the deployer so it deploys any new
> EJB on all the nodes of the cluster...
Isn't this a facet of the clustering implementation?
Re: The clustering discussion - again ;-)
Posted by Paulo Lopes <pm...@gmail.com>.
Another issue that hasn't been discussed is what happens when the
nodes are not synchronized? I deploy a EJB on node #1 but my initial
context sends me to node #2... if we are talking about clustering we
need also to consider a change on the deployer so it deploys any new
EJB on all the nodes of the cluster...
On 6/15/07, Jeff Genender <jg...@apache.org> wrote:
>
>
> Paulo Lopes wrote:
> > Ok, moving away from my statistics issues :) that can happen in odd
> > situations, there is another thing I don't like :) sorry i'm stubborn.
> > Why does the client need to know one node of the cluster to ask the
> > server list instead of getting it from a discovery/directory service?
>
> I could be wrong, but I am not aware of many EJB stub implementations
> that has discovery capabilities in it...although I guess that
> possibility could exist. IIUC, the client still needs a JNDI
> InitialContext and it has to talk to some JNDI server to even know where
> any of the EJB servers live. Although you could have some form of
> discovery built into the stub to find JNDI servers, I think this would
> be rather unusual.
>
> >
> > I am saying this because if you look at simple example from the DB
> > world whenever i connect to my Oracle cluster for doing my datamining
> > stuff, i never tell my client to connect to a particular node, i tell
> > it to connect to the discovery/directory node and after that either,
> > the client either reconnects to the node that is free, or the middle
> > server just acts as a proxy and forwards my connection to the next
> > available node.
>
> Yep...but the EJB stub (which I call the client) is a different animal.
> Keep in mind we are clustering the EJB servers. Those are the "ugghh -
> I hate to say it" - client (real clients) of the clustering
> implementation. Those are clustering sessions. Therefore each EJB
> server should have the capability to have a copy of the session.
>
> The stub client (or remote client of the ejb server) somehow needs to
> know all the EJB servers who are in the cluster or are being clustered
> for that application. Typically, on most EJB servers that I am aware
> of, do it very similarly to how we are discussing it here...where the
> EJB server gives the list of servers in the cluster to the client and
> its checked for validity on each EJB call.
>
> Keep in mind the discovery does happen, but it happens at the EJB server
> level, not the stub client.
>
> Now...this is not to say at some point we couldn't add JNDI discovery to
> the client stub, which would provide for what you describe. But the big
> negative with that is we are already implementing a heartbeat multicast
> discovery for the cluster, and if the stub needs its own, then we have a
> tremendous amount of chatter.
>
> To make my point more clear...make the analogy to a web server that is
> clustered. Clustering web is easy. We dont have to tell the client
> (the browser) who is in the cluster because that is being done by DNS
> and a load balancer. DNS supplies the round robinning of IPs that
> represent which server to connect to (or the load balancer can handle
> that). In EJB world, the JNDI is our "DNS", the stub is the "browser",
> and the EJB Server is our "Tomcat" ;-)
>
> Now, if I am missing something here...point it out. I want to be sure
> we do this right.
>
> Jeff
>
> >
> > My question is shouldn't this cluster thing be a separate server? (I
> > think so, but from what i've understand from the discussion it seems
> > it will be embedded in the main OEJB server code).
> >
> > On 6/15/07, Jeff Genender <jg...@apache.org> wrote:
> >>
> >>
> >> Paulo Lopes wrote:
> >> > "the best load balanced solution"? how is that?
> >> >
> >>
> >> Its the best out of the two we have discussed thus far.
> >>
> >> > Let me start with round robin:
> >> >
> >> > imagine you have OEJBServer1 and OEJBServer2 (in the cluster) and now
> >> > you have like N clients OEJBClient(i).
> >> >
> >> > Say that all the clients only know at start OEJBServer1 and ask then
> >> > the server list:
> >> >
> >> > inside OEJBClient(i) code you have:
> >> > OEJBServer1.getMeTheServerList()
> >> > // this returns a collection with: {OEJBServer1, OEJBServer2}
> >> >
> >> > using the round robin: when asking for the next server all clients will
> >> > execute:
> >> > theClusterServerList.getNextServer();
> >> > // bad enough for each OEJBClient(i) the answer will be OEJBServer1 to
> >> > every (i)
> >> >
> >> > This leads to a never used OEJBServer2 and an overloaded OEJBServer1.
> >> >
> >>
> >> You are making an assumption that the server is not delivering a random
> >> list of the URLs. This is easily mitigated.
> >>
> >> > Now with Random policy:
> >> >
> >> > When asking for what next server each client might get either a 1 or a
> >> > 2, this spreads the load, but if server1 is for instance already
> >> > serving 1000 requests and server2 5, there is 50% of change that the
> >> > next request goes to server1 who is already overloaded and server2
> >> > stays free.
> >> >
> >>
> >> Explain the probabilities in a random pick how server1 will be accepting
> >> 1000 requests and server 2 only 5? Now the possibility exists that such
> >> a situation could occur, but the probability...I think I have a better
> >> chance of winning the lottery.
> >>
> >> In addition, if someone has a single server servicing 1000 simultaneous
> >> clients for remote EJB, I think they probably need to have more than 2
> >> servers in the cluster ;-)
> >>
> >>
> >> > I think the problem is more complex than asking for a URL collection
> >> > and "pick one".
> >>
> >> Ok...so people have offered up 2 possible policies to start with. Given
> >> the size of putting this together, I believe 2 simple policies for
> >> clustering to get it working is not too bad to begin with. A random
> >> policy will probably be sufficient for 98% of the use cases out there
> >> that would use this. The policy can be a simple SPI that is pluggable
> >> and can be expanded upon. If you have a more robust implementation that
> >> you would like to see in it, then please offer your ideas so they are
> >> tracked here.
> >>
> >> IMHO, we can always build a better mouse trap, but we need to start with
> >> something simple that works.
> >>
> >> Yes the servers could easily come up with an ordering based on load,
> >> deliver *that* list to the clients, and they can round-robin that list.
> >> Again...for a pluggable policy, its rather simple to implement.
> >>
> >> The key here is to flush out the basic protocol for communicating a
> >> list...some list...to the clients. How it fails over, etc, can be done
> >> at the point of implementation.
> >>
> >> Jeff
> >>
> >> >
> >> > On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >> >> Right...I would agree random is best as the default since it utilizes
> >> >> the best load balanced solution.
> >> >>
> >> >> Jeff
> >> >>
> >> >> David Blevins wrote:
> >> >> >
> >> >> > On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
> >> >> >>
> >> >> >> Manu George wrote:
> >> >> >>> Yes I understand that random will work but how about others like
> >> >> round
> >> >> >>> robin etc? Are we planning to support only the random strategy?
> >> >> >>
> >> >> >> I think we can support whatever policy we want since this is a
> >> >> component
> >> >> >> of OEJB and not the clustering implementation that is bolted on
> >> to it.
> >> >> >> Round robin and random are both fairly simple to implement.
> >> >> >
> >> >> > Round robin super easy to implement and definitely should be an
> >> option.
> >> >> > Random seems more appealing as the default, we can just:
> >> >> >
> >> >> > URL nextServer = serverList.get(new
> >> >> > Random().nextInt(serverList.size()));
> >> >> >
> >> >> > -David
> >> >> >
> >> >> >>
> >> >> >> Jeff
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>>
> >> >> >>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Manu George wrote:
> >> >> >>>>> As per what I understood if one of the servers are down then the
> >> >> >>>>> client will call the next one in the list which would send it a
> >> >> new id
> >> >> >>>>> after which all calls will be to that one.
> >> >> >>>>
> >> >> >>>> You are assuming no policy for how a client chooses a server and
> >> >> that
> >> >> >>>> its linear. Consider it random and this issue goes away.
> >> >> >>>>
> >> >> >>>>> But in order to decide
> >> >> >>>>> which server to pick based on the load balancing strategy used I
> >> >> think
> >> >> >>>>> we may need more information to be passed to the client. Once
> >> this
> >> >> >>>>> discussion is finished i think we should put this in a wiki page
> >> >> as it
> >> >> >>>>> provides good insights on clustering and the logic used. I can
> >> >> >>>>> probably do that if no one else wants it :)
> >> >> >>>>>
> >> >> >>>>> Regards
> >> >> >>>>> Manu
> >> >> >>>>>
> >> >> >>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> >> >> >>>>>> The idea of id download on the first connection doesn't seem
> >> >> nice to
> >> >> >>>>>> me. Assume the following scenario:
> >> >> >>>>>>
> >> >> >>>>>> you have a cluster of 3 servers, and the 3 are aware of the
> >> >> other by
> >> >> >>>>>> their internal configuration. (no discovery inside the
> >> >> cluster). The
> >> >> >>>>>> client receives the list of 3 servers and now has to decide
> >> >> which one
> >> >> >>>>>> to connect. It is clear here that the client needs to know some
> >> >> more
> >> >> >>>>>> about the server to decide which one to pick in order to
> >> share the
> >> >> >>>>>> load balancing in the cluster, more there is no way for the
> >> >> client to
> >> >> >>>>>> know if one of the servers is down and if it is that server is
> >> >> >>>>>> removed
> >> >> >>>>>> from the list and never connected again during that request.
> >> >> >>>>>>
> >> >> >>>>>> My idea is that perhaps we would better have a small extra
> >> server
> >> >> >>>>>> that
> >> >> >>>>>> i will call a service dispatcher, that is the central point for
> >> >> the
> >> >> >>>>>> cluster. no need to change the openejb code each server still
> >> >> >>>>>> works in
> >> >> >>>>>> a isolated way. The SD would have the configurations of
> >> where the
> >> >> >>>>>> openejb nodes are in the cluster and their status (up/down).
> >> >> >>>>>>
> >> >> >>>>>> The clients would then connect to the SD and the SD would query
> >> >> the
> >> >> >>>>>> list of servers, and forward to the next available one. Metrics
> >> >> could
> >> >> >>>>>> be gathered from the SD such as time between query and response
> >> >> from
> >> >> >>>>>> OEJB making a simple (not so accurate) load balancer system.
> >> >> >>>>>>
> >> >> >>>>>> Paulo
> >> >> >>>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >> >
> >> >
> >>
> >
> >
>
--
Paulo Lopes
www.scratchydreams.com
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Paulo Lopes wrote:
> Ok, moving away from my statistics issues :) that can happen in odd
> situations, there is another thing I don't like :) sorry i'm stubborn.
> Why does the client need to know one node of the cluster to ask the
> server list instead of getting it from a discovery/directory service?
I could be wrong, but I am not aware of many EJB stub implementations
that has discovery capabilities in it...although I guess that
possibility could exist. IIUC, the client still needs a JNDI
InitialContext and it has to talk to some JNDI server to even know where
any of the EJB servers live. Although you could have some form of
discovery built into the stub to find JNDI servers, I think this would
be rather unusual.
>
> I am saying this because if you look at simple example from the DB
> world whenever i connect to my Oracle cluster for doing my datamining
> stuff, i never tell my client to connect to a particular node, i tell
> it to connect to the discovery/directory node and after that either,
> the client either reconnects to the node that is free, or the middle
> server just acts as a proxy and forwards my connection to the next
> available node.
Yep...but the EJB stub (which I call the client) is a different animal.
Keep in mind we are clustering the EJB servers. Those are the "ugghh -
I hate to say it" - client (real clients) of the clustering
implementation. Those are clustering sessions. Therefore each EJB
server should have the capability to have a copy of the session.
The stub client (or remote client of the ejb server) somehow needs to
know all the EJB servers who are in the cluster or are being clustered
for that application. Typically, on most EJB servers that I am aware
of, do it very similarly to how we are discussing it here...where the
EJB server gives the list of servers in the cluster to the client and
its checked for validity on each EJB call.
Keep in mind the discovery does happen, but it happens at the EJB server
level, not the stub client.
Now...this is not to say at some point we couldn't add JNDI discovery to
the client stub, which would provide for what you describe. But the big
negative with that is we are already implementing a heartbeat multicast
discovery for the cluster, and if the stub needs its own, then we have a
tremendous amount of chatter.
To make my point more clear...make the analogy to a web server that is
clustered. Clustering web is easy. We dont have to tell the client
(the browser) who is in the cluster because that is being done by DNS
and a load balancer. DNS supplies the round robinning of IPs that
represent which server to connect to (or the load balancer can handle
that). In EJB world, the JNDI is our "DNS", the stub is the "browser",
and the EJB Server is our "Tomcat" ;-)
Now, if I am missing something here...point it out. I want to be sure
we do this right.
Jeff
>
> My question is shouldn't this cluster thing be a separate server? (I
> think so, but from what i've understand from the discussion it seems
> it will be embedded in the main OEJB server code).
>
> On 6/15/07, Jeff Genender <jg...@apache.org> wrote:
>>
>>
>> Paulo Lopes wrote:
>> > "the best load balanced solution"? how is that?
>> >
>>
>> Its the best out of the two we have discussed thus far.
>>
>> > Let me start with round robin:
>> >
>> > imagine you have OEJBServer1 and OEJBServer2 (in the cluster) and now
>> > you have like N clients OEJBClient(i).
>> >
>> > Say that all the clients only know at start OEJBServer1 and ask then
>> > the server list:
>> >
>> > inside OEJBClient(i) code you have:
>> > OEJBServer1.getMeTheServerList()
>> > // this returns a collection with: {OEJBServer1, OEJBServer2}
>> >
>> > using the round robin: when asking for the next server all clients will
>> > execute:
>> > theClusterServerList.getNextServer();
>> > // bad enough for each OEJBClient(i) the answer will be OEJBServer1 to
>> > every (i)
>> >
>> > This leads to a never used OEJBServer2 and an overloaded OEJBServer1.
>> >
>>
>> You are making an assumption that the server is not delivering a random
>> list of the URLs. This is easily mitigated.
>>
>> > Now with Random policy:
>> >
>> > When asking for what next server each client might get either a 1 or a
>> > 2, this spreads the load, but if server1 is for instance already
>> > serving 1000 requests and server2 5, there is 50% of change that the
>> > next request goes to server1 who is already overloaded and server2
>> > stays free.
>> >
>>
>> Explain the probabilities in a random pick how server1 will be accepting
>> 1000 requests and server 2 only 5? Now the possibility exists that such
>> a situation could occur, but the probability...I think I have a better
>> chance of winning the lottery.
>>
>> In addition, if someone has a single server servicing 1000 simultaneous
>> clients for remote EJB, I think they probably need to have more than 2
>> servers in the cluster ;-)
>>
>>
>> > I think the problem is more complex than asking for a URL collection
>> > and "pick one".
>>
>> Ok...so people have offered up 2 possible policies to start with. Given
>> the size of putting this together, I believe 2 simple policies for
>> clustering to get it working is not too bad to begin with. A random
>> policy will probably be sufficient for 98% of the use cases out there
>> that would use this. The policy can be a simple SPI that is pluggable
>> and can be expanded upon. If you have a more robust implementation that
>> you would like to see in it, then please offer your ideas so they are
>> tracked here.
>>
>> IMHO, we can always build a better mouse trap, but we need to start with
>> something simple that works.
>>
>> Yes the servers could easily come up with an ordering based on load,
>> deliver *that* list to the clients, and they can round-robin that list.
>> Again...for a pluggable policy, its rather simple to implement.
>>
>> The key here is to flush out the basic protocol for communicating a
>> list...some list...to the clients. How it fails over, etc, can be done
>> at the point of implementation.
>>
>> Jeff
>>
>> >
>> > On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>> >> Right...I would agree random is best as the default since it utilizes
>> >> the best load balanced solution.
>> >>
>> >> Jeff
>> >>
>> >> David Blevins wrote:
>> >> >
>> >> > On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
>> >> >>
>> >> >> Manu George wrote:
>> >> >>> Yes I understand that random will work but how about others like
>> >> round
>> >> >>> robin etc? Are we planning to support only the random strategy?
>> >> >>
>> >> >> I think we can support whatever policy we want since this is a
>> >> component
>> >> >> of OEJB and not the clustering implementation that is bolted on
>> to it.
>> >> >> Round robin and random are both fairly simple to implement.
>> >> >
>> >> > Round robin super easy to implement and definitely should be an
>> option.
>> >> > Random seems more appealing as the default, we can just:
>> >> >
>> >> > URL nextServer = serverList.get(new
>> >> > Random().nextInt(serverList.size()));
>> >> >
>> >> > -David
>> >> >
>> >> >>
>> >> >> Jeff
>> >> >>
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>> >> >>>>
>> >> >>>>
>> >> >>>> Manu George wrote:
>> >> >>>>> As per what I understood if one of the servers are down then the
>> >> >>>>> client will call the next one in the list which would send it a
>> >> new id
>> >> >>>>> after which all calls will be to that one.
>> >> >>>>
>> >> >>>> You are assuming no policy for how a client chooses a server and
>> >> that
>> >> >>>> its linear. Consider it random and this issue goes away.
>> >> >>>>
>> >> >>>>> But in order to decide
>> >> >>>>> which server to pick based on the load balancing strategy used I
>> >> think
>> >> >>>>> we may need more information to be passed to the client. Once
>> this
>> >> >>>>> discussion is finished i think we should put this in a wiki page
>> >> as it
>> >> >>>>> provides good insights on clustering and the logic used. I can
>> >> >>>>> probably do that if no one else wants it :)
>> >> >>>>>
>> >> >>>>> Regards
>> >> >>>>> Manu
>> >> >>>>>
>> >> >>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>> >> >>>>>> The idea of id download on the first connection doesn't seem
>> >> nice to
>> >> >>>>>> me. Assume the following scenario:
>> >> >>>>>>
>> >> >>>>>> you have a cluster of 3 servers, and the 3 are aware of the
>> >> other by
>> >> >>>>>> their internal configuration. (no discovery inside the
>> >> cluster). The
>> >> >>>>>> client receives the list of 3 servers and now has to decide
>> >> which one
>> >> >>>>>> to connect. It is clear here that the client needs to know some
>> >> more
>> >> >>>>>> about the server to decide which one to pick in order to
>> share the
>> >> >>>>>> load balancing in the cluster, more there is no way for the
>> >> client to
>> >> >>>>>> know if one of the servers is down and if it is that server is
>> >> >>>>>> removed
>> >> >>>>>> from the list and never connected again during that request.
>> >> >>>>>>
>> >> >>>>>> My idea is that perhaps we would better have a small extra
>> server
>> >> >>>>>> that
>> >> >>>>>> i will call a service dispatcher, that is the central point for
>> >> the
>> >> >>>>>> cluster. no need to change the openejb code each server still
>> >> >>>>>> works in
>> >> >>>>>> a isolated way. The SD would have the configurations of
>> where the
>> >> >>>>>> openejb nodes are in the cluster and their status (up/down).
>> >> >>>>>>
>> >> >>>>>> The clients would then connect to the SD and the SD would query
>> >> the
>> >> >>>>>> list of servers, and forward to the next available one. Metrics
>> >> could
>> >> >>>>>> be gathered from the SD such as time between query and response
>> >> from
>> >> >>>>>> OEJB making a simple (not so accurate) load balancer system.
>> >> >>>>>>
>> >> >>>>>> Paulo
>> >> >>>>>>
>> >> >>>>
>> >> >>
>> >>
>> >
>> >
>>
>
>
Re: The clustering discussion - again ;-)
Posted by Paulo Lopes <pm...@gmail.com>.
Ok, moving away from my statistics issues :) that can happen in odd
situations, there is another thing I don't like :) sorry i'm stubborn.
Why does the client need to know one node of the cluster to ask the
server list instead of getting it from a discovery/directory service?
I am saying this because if you look at simple example from the DB
world whenever i connect to my Oracle cluster for doing my datamining
stuff, i never tell my client to connect to a particular node, i tell
it to connect to the discovery/directory node and after that either,
the client either reconnects to the node that is free, or the middle
server just acts as a proxy and forwards my connection to the next
available node.
My question is shouldn't this cluster thing be a separate server? (I
think so, but from what i've understand from the discussion it seems
it will be embedded in the main OEJB server code).
On 6/15/07, Jeff Genender <jg...@apache.org> wrote:
>
>
> Paulo Lopes wrote:
> > "the best load balanced solution"? how is that?
> >
>
> Its the best out of the two we have discussed thus far.
>
> > Let me start with round robin:
> >
> > imagine you have OEJBServer1 and OEJBServer2 (in the cluster) and now
> > you have like N clients OEJBClient(i).
> >
> > Say that all the clients only know at start OEJBServer1 and ask then
> > the server list:
> >
> > inside OEJBClient(i) code you have:
> > OEJBServer1.getMeTheServerList()
> > // this returns a collection with: {OEJBServer1, OEJBServer2}
> >
> > using the round robin: when asking for the next server all clients will
> > execute:
> > theClusterServerList.getNextServer();
> > // bad enough for each OEJBClient(i) the answer will be OEJBServer1 to
> > every (i)
> >
> > This leads to a never used OEJBServer2 and an overloaded OEJBServer1.
> >
>
> You are making an assumption that the server is not delivering a random
> list of the URLs. This is easily mitigated.
>
> > Now with Random policy:
> >
> > When asking for what next server each client might get either a 1 or a
> > 2, this spreads the load, but if server1 is for instance already
> > serving 1000 requests and server2 5, there is 50% of change that the
> > next request goes to server1 who is already overloaded and server2
> > stays free.
> >
>
> Explain the probabilities in a random pick how server1 will be accepting
> 1000 requests and server 2 only 5? Now the possibility exists that such
> a situation could occur, but the probability...I think I have a better
> chance of winning the lottery.
>
> In addition, if someone has a single server servicing 1000 simultaneous
> clients for remote EJB, I think they probably need to have more than 2
> servers in the cluster ;-)
>
>
> > I think the problem is more complex than asking for a URL collection
> > and "pick one".
>
> Ok...so people have offered up 2 possible policies to start with. Given
> the size of putting this together, I believe 2 simple policies for
> clustering to get it working is not too bad to begin with. A random
> policy will probably be sufficient for 98% of the use cases out there
> that would use this. The policy can be a simple SPI that is pluggable
> and can be expanded upon. If you have a more robust implementation that
> you would like to see in it, then please offer your ideas so they are
> tracked here.
>
> IMHO, we can always build a better mouse trap, but we need to start with
> something simple that works.
>
> Yes the servers could easily come up with an ordering based on load,
> deliver *that* list to the clients, and they can round-robin that list.
> Again...for a pluggable policy, its rather simple to implement.
>
> The key here is to flush out the basic protocol for communicating a
> list...some list...to the clients. How it fails over, etc, can be done
> at the point of implementation.
>
> Jeff
>
> >
> > On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >> Right...I would agree random is best as the default since it utilizes
> >> the best load balanced solution.
> >>
> >> Jeff
> >>
> >> David Blevins wrote:
> >> >
> >> > On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
> >> >>
> >> >> Manu George wrote:
> >> >>> Yes I understand that random will work but how about others like
> >> round
> >> >>> robin etc? Are we planning to support only the random strategy?
> >> >>
> >> >> I think we can support whatever policy we want since this is a
> >> component
> >> >> of OEJB and not the clustering implementation that is bolted on to it.
> >> >> Round robin and random are both fairly simple to implement.
> >> >
> >> > Round robin super easy to implement and definitely should be an option.
> >> > Random seems more appealing as the default, we can just:
> >> >
> >> > URL nextServer = serverList.get(new
> >> > Random().nextInt(serverList.size()));
> >> >
> >> > -David
> >> >
> >> >>
> >> >> Jeff
> >> >>
> >> >>
> >> >>
> >> >>>
> >> >>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >> >>>>
> >> >>>>
> >> >>>> Manu George wrote:
> >> >>>>> As per what I understood if one of the servers are down then the
> >> >>>>> client will call the next one in the list which would send it a
> >> new id
> >> >>>>> after which all calls will be to that one.
> >> >>>>
> >> >>>> You are assuming no policy for how a client chooses a server and
> >> that
> >> >>>> its linear. Consider it random and this issue goes away.
> >> >>>>
> >> >>>>> But in order to decide
> >> >>>>> which server to pick based on the load balancing strategy used I
> >> think
> >> >>>>> we may need more information to be passed to the client. Once this
> >> >>>>> discussion is finished i think we should put this in a wiki page
> >> as it
> >> >>>>> provides good insights on clustering and the logic used. I can
> >> >>>>> probably do that if no one else wants it :)
> >> >>>>>
> >> >>>>> Regards
> >> >>>>> Manu
> >> >>>>>
> >> >>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> >> >>>>>> The idea of id download on the first connection doesn't seem
> >> nice to
> >> >>>>>> me. Assume the following scenario:
> >> >>>>>>
> >> >>>>>> you have a cluster of 3 servers, and the 3 are aware of the
> >> other by
> >> >>>>>> their internal configuration. (no discovery inside the
> >> cluster). The
> >> >>>>>> client receives the list of 3 servers and now has to decide
> >> which one
> >> >>>>>> to connect. It is clear here that the client needs to know some
> >> more
> >> >>>>>> about the server to decide which one to pick in order to share the
> >> >>>>>> load balancing in the cluster, more there is no way for the
> >> client to
> >> >>>>>> know if one of the servers is down and if it is that server is
> >> >>>>>> removed
> >> >>>>>> from the list and never connected again during that request.
> >> >>>>>>
> >> >>>>>> My idea is that perhaps we would better have a small extra server
> >> >>>>>> that
> >> >>>>>> i will call a service dispatcher, that is the central point for
> >> the
> >> >>>>>> cluster. no need to change the openejb code each server still
> >> >>>>>> works in
> >> >>>>>> a isolated way. The SD would have the configurations of where the
> >> >>>>>> openejb nodes are in the cluster and their status (up/down).
> >> >>>>>>
> >> >>>>>> The clients would then connect to the SD and the SD would query
> >> the
> >> >>>>>> list of servers, and forward to the next available one. Metrics
> >> could
> >> >>>>>> be gathered from the SD such as time between query and response
> >> from
> >> >>>>>> OEJB making a simple (not so accurate) load balancer system.
> >> >>>>>>
> >> >>>>>> Paulo
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> >
> >
>
--
Paulo Lopes
www.scratchydreams.com
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Paulo Lopes wrote:
> "the best load balanced solution"? how is that?
>
Its the best out of the two we have discussed thus far.
> Let me start with round robin:
>
> imagine you have OEJBServer1 and OEJBServer2 (in the cluster) and now
> you have like N clients OEJBClient(i).
>
> Say that all the clients only know at start OEJBServer1 and ask then
> the server list:
>
> inside OEJBClient(i) code you have:
> OEJBServer1.getMeTheServerList()
> // this returns a collection with: {OEJBServer1, OEJBServer2}
>
> using the round robin: when asking for the next server all clients will
> execute:
> theClusterServerList.getNextServer();
> // bad enough for each OEJBClient(i) the answer will be OEJBServer1 to
> every (i)
>
> This leads to a never used OEJBServer2 and an overloaded OEJBServer1.
>
You are making an assumption that the server is not delivering a random
list of the URLs. This is easily mitigated.
> Now with Random policy:
>
> When asking for what next server each client might get either a 1 or a
> 2, this spreads the load, but if server1 is for instance already
> serving 1000 requests and server2 5, there is 50% of change that the
> next request goes to server1 who is already overloaded and server2
> stays free.
>
Explain the probabilities in a random pick how server1 will be accepting
1000 requests and server 2 only 5? Now the possibility exists that such
a situation could occur, but the probability...I think I have a better
chance of winning the lottery.
In addition, if someone has a single server servicing 1000 simultaneous
clients for remote EJB, I think they probably need to have more than 2
servers in the cluster ;-)
> I think the problem is more complex than asking for a URL collection
> and "pick one".
Ok...so people have offered up 2 possible policies to start with. Given
the size of putting this together, I believe 2 simple policies for
clustering to get it working is not too bad to begin with. A random
policy will probably be sufficient for 98% of the use cases out there
that would use this. The policy can be a simple SPI that is pluggable
and can be expanded upon. If you have a more robust implementation that
you would like to see in it, then please offer your ideas so they are
tracked here.
IMHO, we can always build a better mouse trap, but we need to start with
something simple that works.
Yes the servers could easily come up with an ordering based on load,
deliver *that* list to the clients, and they can round-robin that list.
Again...for a pluggable policy, its rather simple to implement.
The key here is to flush out the basic protocol for communicating a
list...some list...to the clients. How it fails over, etc, can be done
at the point of implementation.
Jeff
>
> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>> Right...I would agree random is best as the default since it utilizes
>> the best load balanced solution.
>>
>> Jeff
>>
>> David Blevins wrote:
>> >
>> > On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
>> >>
>> >> Manu George wrote:
>> >>> Yes I understand that random will work but how about others like
>> round
>> >>> robin etc? Are we planning to support only the random strategy?
>> >>
>> >> I think we can support whatever policy we want since this is a
>> component
>> >> of OEJB and not the clustering implementation that is bolted on to it.
>> >> Round robin and random are both fairly simple to implement.
>> >
>> > Round robin super easy to implement and definitely should be an option.
>> > Random seems more appealing as the default, we can just:
>> >
>> > URL nextServer = serverList.get(new
>> > Random().nextInt(serverList.size()));
>> >
>> > -David
>> >
>> >>
>> >> Jeff
>> >>
>> >>
>> >>
>> >>>
>> >>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>> >>>>
>> >>>>
>> >>>> Manu George wrote:
>> >>>>> As per what I understood if one of the servers are down then the
>> >>>>> client will call the next one in the list which would send it a
>> new id
>> >>>>> after which all calls will be to that one.
>> >>>>
>> >>>> You are assuming no policy for how a client chooses a server and
>> that
>> >>>> its linear. Consider it random and this issue goes away.
>> >>>>
>> >>>>> But in order to decide
>> >>>>> which server to pick based on the load balancing strategy used I
>> think
>> >>>>> we may need more information to be passed to the client. Once this
>> >>>>> discussion is finished i think we should put this in a wiki page
>> as it
>> >>>>> provides good insights on clustering and the logic used. I can
>> >>>>> probably do that if no one else wants it :)
>> >>>>>
>> >>>>> Regards
>> >>>>> Manu
>> >>>>>
>> >>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>> >>>>>> The idea of id download on the first connection doesn't seem
>> nice to
>> >>>>>> me. Assume the following scenario:
>> >>>>>>
>> >>>>>> you have a cluster of 3 servers, and the 3 are aware of the
>> other by
>> >>>>>> their internal configuration. (no discovery inside the
>> cluster). The
>> >>>>>> client receives the list of 3 servers and now has to decide
>> which one
>> >>>>>> to connect. It is clear here that the client needs to know some
>> more
>> >>>>>> about the server to decide which one to pick in order to share the
>> >>>>>> load balancing in the cluster, more there is no way for the
>> client to
>> >>>>>> know if one of the servers is down and if it is that server is
>> >>>>>> removed
>> >>>>>> from the list and never connected again during that request.
>> >>>>>>
>> >>>>>> My idea is that perhaps we would better have a small extra server
>> >>>>>> that
>> >>>>>> i will call a service dispatcher, that is the central point for
>> the
>> >>>>>> cluster. no need to change the openejb code each server still
>> >>>>>> works in
>> >>>>>> a isolated way. The SD would have the configurations of where the
>> >>>>>> openejb nodes are in the cluster and their status (up/down).
>> >>>>>>
>> >>>>>> The clients would then connect to the SD and the SD would query
>> the
>> >>>>>> list of servers, and forward to the next available one. Metrics
>> could
>> >>>>>> be gathered from the SD such as time between query and response
>> from
>> >>>>>> OEJB making a simple (not so accurate) load balancer system.
>> >>>>>>
>> >>>>>> Paulo
>> >>>>>>
>> >>>>
>> >>
>>
>
>
Re: The clustering discussion - again ;-)
Posted by Paulo Lopes <pm...@gmail.com>.
"the best load balanced solution"? how is that?
Let me start with round robin:
imagine you have OEJBServer1 and OEJBServer2 (in the cluster) and now
you have like N clients OEJBClient(i).
Say that all the clients only know at start OEJBServer1 and ask then
the server list:
inside OEJBClient(i) code you have:
OEJBServer1.getMeTheServerList()
// this returns a collection with: {OEJBServer1, OEJBServer2}
using the round robin: when asking for the next server all clients will execute:
theClusterServerList.getNextServer();
// bad enough for each OEJBClient(i) the answer will be OEJBServer1 to every (i)
This leads to a never used OEJBServer2 and an overloaded OEJBServer1.
Now with Random policy:
When asking for what next server each client might get either a 1 or a
2, this spreads the load, but if server1 is for instance already
serving 1000 requests and server2 5, there is 50% of change that the
next request goes to server1 who is already overloaded and server2
stays free.
I think the problem is more complex than asking for a URL collection
and "pick one".
On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> Right...I would agree random is best as the default since it utilizes
> the best load balanced solution.
>
> Jeff
>
> David Blevins wrote:
> >
> > On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
> >>
> >> Manu George wrote:
> >>> Yes I understand that random will work but how about others like round
> >>> robin etc? Are we planning to support only the random strategy?
> >>
> >> I think we can support whatever policy we want since this is a component
> >> of OEJB and not the clustering implementation that is bolted on to it.
> >> Round robin and random are both fairly simple to implement.
> >
> > Round robin super easy to implement and definitely should be an option.
> > Random seems more appealing as the default, we can just:
> >
> > URL nextServer = serverList.get(new
> > Random().nextInt(serverList.size()));
> >
> > -David
> >
> >>
> >> Jeff
> >>
> >>
> >>
> >>>
> >>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >>>>
> >>>>
> >>>> Manu George wrote:
> >>>>> As per what I understood if one of the servers are down then the
> >>>>> client will call the next one in the list which would send it a new id
> >>>>> after which all calls will be to that one.
> >>>>
> >>>> You are assuming no policy for how a client chooses a server and that
> >>>> its linear. Consider it random and this issue goes away.
> >>>>
> >>>>> But in order to decide
> >>>>> which server to pick based on the load balancing strategy used I think
> >>>>> we may need more information to be passed to the client. Once this
> >>>>> discussion is finished i think we should put this in a wiki page as it
> >>>>> provides good insights on clustering and the logic used. I can
> >>>>> probably do that if no one else wants it :)
> >>>>>
> >>>>> Regards
> >>>>> Manu
> >>>>>
> >>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> >>>>>> The idea of id download on the first connection doesn't seem nice to
> >>>>>> me. Assume the following scenario:
> >>>>>>
> >>>>>> you have a cluster of 3 servers, and the 3 are aware of the other by
> >>>>>> their internal configuration. (no discovery inside the cluster). The
> >>>>>> client receives the list of 3 servers and now has to decide which one
> >>>>>> to connect. It is clear here that the client needs to know some more
> >>>>>> about the server to decide which one to pick in order to share the
> >>>>>> load balancing in the cluster, more there is no way for the client to
> >>>>>> know if one of the servers is down and if it is that server is
> >>>>>> removed
> >>>>>> from the list and never connected again during that request.
> >>>>>>
> >>>>>> My idea is that perhaps we would better have a small extra server
> >>>>>> that
> >>>>>> i will call a service dispatcher, that is the central point for the
> >>>>>> cluster. no need to change the openejb code each server still
> >>>>>> works in
> >>>>>> a isolated way. The SD would have the configurations of where the
> >>>>>> openejb nodes are in the cluster and their status (up/down).
> >>>>>>
> >>>>>> The clients would then connect to the SD and the SD would query the
> >>>>>> list of servers, and forward to the next available one. Metrics could
> >>>>>> be gathered from the SD such as time between query and response from
> >>>>>> OEJB making a simple (not so accurate) load balancer system.
> >>>>>>
> >>>>>> Paulo
> >>>>>>
> >>>>
> >>
>
--
Paulo Lopes
www.scratchydreams.com
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Right...I would agree random is best as the default since it utilizes
the best load balanced solution.
Jeff
David Blevins wrote:
>
> On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
>>
>> Manu George wrote:
>>> Yes I understand that random will work but how about others like round
>>> robin etc? Are we planning to support only the random strategy?
>>
>> I think we can support whatever policy we want since this is a component
>> of OEJB and not the clustering implementation that is bolted on to it.
>> Round robin and random are both fairly simple to implement.
>
> Round robin super easy to implement and definitely should be an option.
> Random seems more appealing as the default, we can just:
>
> URL nextServer = serverList.get(new
> Random().nextInt(serverList.size()));
>
> -David
>
>>
>> Jeff
>>
>>
>>
>>>
>>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>>>>
>>>>
>>>> Manu George wrote:
>>>>> As per what I understood if one of the servers are down then the
>>>>> client will call the next one in the list which would send it a new id
>>>>> after which all calls will be to that one.
>>>>
>>>> You are assuming no policy for how a client chooses a server and that
>>>> its linear. Consider it random and this issue goes away.
>>>>
>>>>> But in order to decide
>>>>> which server to pick based on the load balancing strategy used I think
>>>>> we may need more information to be passed to the client. Once this
>>>>> discussion is finished i think we should put this in a wiki page as it
>>>>> provides good insights on clustering and the logic used. I can
>>>>> probably do that if no one else wants it :)
>>>>>
>>>>> Regards
>>>>> Manu
>>>>>
>>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>>>>>> The idea of id download on the first connection doesn't seem nice to
>>>>>> me. Assume the following scenario:
>>>>>>
>>>>>> you have a cluster of 3 servers, and the 3 are aware of the other by
>>>>>> their internal configuration. (no discovery inside the cluster). The
>>>>>> client receives the list of 3 servers and now has to decide which one
>>>>>> to connect. It is clear here that the client needs to know some more
>>>>>> about the server to decide which one to pick in order to share the
>>>>>> load balancing in the cluster, more there is no way for the client to
>>>>>> know if one of the servers is down and if it is that server is
>>>>>> removed
>>>>>> from the list and never connected again during that request.
>>>>>>
>>>>>> My idea is that perhaps we would better have a small extra server
>>>>>> that
>>>>>> i will call a service dispatcher, that is the central point for the
>>>>>> cluster. no need to change the openejb code each server still
>>>>>> works in
>>>>>> a isolated way. The SD would have the configurations of where the
>>>>>> openejb nodes are in the cluster and their status (up/down).
>>>>>>
>>>>>> The clients would then connect to the SD and the SD would query the
>>>>>> list of servers, and forward to the next available one. Metrics could
>>>>>> be gathered from the SD such as time between query and response from
>>>>>> OEJB making a simple (not so accurate) load balancer system.
>>>>>>
>>>>>> Paulo
>>>>>>
>>>>
>>
Re: The clustering discussion - again ;-)
Posted by David Blevins <da...@visi.com>.
On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
>
> Manu George wrote:
>> Yes I understand that random will work but how about others like
>> round
>> robin etc? Are we planning to support only the random strategy?
>
> I think we can support whatever policy we want since this is a
> component
> of OEJB and not the clustering implementation that is bolted on to it.
> Round robin and random are both fairly simple to implement.
Round robin super easy to implement and definitely should be an
option. Random seems more appealing as the default, we can just:
URL nextServer = serverList.get(new Random().nextInt
(serverList.size()));
-David
>
> Jeff
>
>
>
>>
>> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>>>
>>>
>>> Manu George wrote:
>>>> As per what I understood if one of the servers are down then the
>>>> client will call the next one in the list which would send it a
>>>> new id
>>>> after which all calls will be to that one.
>>>
>>> You are assuming no policy for how a client chooses a server and
>>> that
>>> its linear. Consider it random and this issue goes away.
>>>
>>>> But in order to decide
>>>> which server to pick based on the load balancing strategy used I
>>>> think
>>>> we may need more information to be passed to the client. Once this
>>>> discussion is finished i think we should put this in a wiki page
>>>> as it
>>>> provides good insights on clustering and the logic used. I can
>>>> probably do that if no one else wants it :)
>>>>
>>>> Regards
>>>> Manu
>>>>
>>>> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>>>>> The idea of id download on the first connection doesn't seem
>>>>> nice to
>>>>> me. Assume the following scenario:
>>>>>
>>>>> you have a cluster of 3 servers, and the 3 are aware of the
>>>>> other by
>>>>> their internal configuration. (no discovery inside the
>>>>> cluster). The
>>>>> client receives the list of 3 servers and now has to decide
>>>>> which one
>>>>> to connect. It is clear here that the client needs to know some
>>>>> more
>>>>> about the server to decide which one to pick in order to share the
>>>>> load balancing in the cluster, more there is no way for the
>>>>> client to
>>>>> know if one of the servers is down and if it is that server is
>>>>> removed
>>>>> from the list and never connected again during that request.
>>>>>
>>>>> My idea is that perhaps we would better have a small extra
>>>>> server that
>>>>> i will call a service dispatcher, that is the central point for
>>>>> the
>>>>> cluster. no need to change the openejb code each server still
>>>>> works in
>>>>> a isolated way. The SD would have the configurations of where the
>>>>> openejb nodes are in the cluster and their status (up/down).
>>>>>
>>>>> The clients would then connect to the SD and the SD would query
>>>>> the
>>>>> list of servers, and forward to the next available one. Metrics
>>>>> could
>>>>> be gathered from the SD such as time between query and response
>>>>> from
>>>>> OEJB making a simple (not so accurate) load balancer system.
>>>>>
>>>>> Paulo
>>>>>
>>>
>
Re: The clustering discussion - again ;-)
Posted by Manu George <ma...@gmail.com>.
Ok I get it now. I was thinking on a different tangent :).
Thanks
Manu
6/14/07, Jeff Genender <jg...@apache.org> wrote:
>
>
> Manu George wrote:
> > Yes I understand that random will work but how about others like round
> > robin etc? Are we planning to support only the random strategy?
>
> I think we can support whatever policy we want since this is a component
> of OEJB and not the clustering implementation that is bolted on to it.
> Round robin and random are both fairly simple to implement.
>
>
> Jeff
>
>
>
> >
> > On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
> >>
> >>
> >> Manu George wrote:
> >> > As per what I understood if one of the servers are down then the
> >> > client will call the next one in the list which would send it a new id
> >> > after which all calls will be to that one.
> >>
> >> You are assuming no policy for how a client chooses a server and that
> >> its linear. Consider it random and this issue goes away.
> >>
> >> > But in order to decide
> >> > which server to pick based on the load balancing strategy used I think
> >> > we may need more information to be passed to the client. Once this
> >> > discussion is finished i think we should put this in a wiki page as it
> >> > provides good insights on clustering and the logic used. I can
> >> > probably do that if no one else wants it :)
> >> >
> >> > Regards
> >> > Manu
> >> >
> >> > On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> >> >> The idea of id download on the first connection doesn't seem nice to
> >> >> me. Assume the following scenario:
> >> >>
> >> >> you have a cluster of 3 servers, and the 3 are aware of the other by
> >> >> their internal configuration. (no discovery inside the cluster). The
> >> >> client receives the list of 3 servers and now has to decide which one
> >> >> to connect. It is clear here that the client needs to know some more
> >> >> about the server to decide which one to pick in order to share the
> >> >> load balancing in the cluster, more there is no way for the client to
> >> >> know if one of the servers is down and if it is that server is removed
> >> >> from the list and never connected again during that request.
> >> >>
> >> >> My idea is that perhaps we would better have a small extra server that
> >> >> i will call a service dispatcher, that is the central point for the
> >> >> cluster. no need to change the openejb code each server still works in
> >> >> a isolated way. The SD would have the configurations of where the
> >> >> openejb nodes are in the cluster and their status (up/down).
> >> >>
> >> >> The clients would then connect to the SD and the SD would query the
> >> >> list of servers, and forward to the next available one. Metrics could
> >> >> be gathered from the SD such as time between query and response from
> >> >> OEJB making a simple (not so accurate) load balancer system.
> >> >>
> >> >> Paulo
> >> >>
> >>
>
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Manu George wrote:
> Yes I understand that random will work but how about others like round
> robin etc? Are we planning to support only the random strategy?
I think we can support whatever policy we want since this is a component
of OEJB and not the clustering implementation that is bolted on to it.
Round robin and random are both fairly simple to implement.
Jeff
>
> On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>>
>>
>> Manu George wrote:
>> > As per what I understood if one of the servers are down then the
>> > client will call the next one in the list which would send it a new id
>> > after which all calls will be to that one.
>>
>> You are assuming no policy for how a client chooses a server and that
>> its linear. Consider it random and this issue goes away.
>>
>> > But in order to decide
>> > which server to pick based on the load balancing strategy used I think
>> > we may need more information to be passed to the client. Once this
>> > discussion is finished i think we should put this in a wiki page as it
>> > provides good insights on clustering and the logic used. I can
>> > probably do that if no one else wants it :)
>> >
>> > Regards
>> > Manu
>> >
>> > On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>> >> The idea of id download on the first connection doesn't seem nice to
>> >> me. Assume the following scenario:
>> >>
>> >> you have a cluster of 3 servers, and the 3 are aware of the other by
>> >> their internal configuration. (no discovery inside the cluster). The
>> >> client receives the list of 3 servers and now has to decide which one
>> >> to connect. It is clear here that the client needs to know some more
>> >> about the server to decide which one to pick in order to share the
>> >> load balancing in the cluster, more there is no way for the client to
>> >> know if one of the servers is down and if it is that server is removed
>> >> from the list and never connected again during that request.
>> >>
>> >> My idea is that perhaps we would better have a small extra server that
>> >> i will call a service dispatcher, that is the central point for the
>> >> cluster. no need to change the openejb code each server still works in
>> >> a isolated way. The SD would have the configurations of where the
>> >> openejb nodes are in the cluster and their status (up/down).
>> >>
>> >> The clients would then connect to the SD and the SD would query the
>> >> list of servers, and forward to the next available one. Metrics could
>> >> be gathered from the SD such as time between query and response from
>> >> OEJB making a simple (not so accurate) load balancer system.
>> >>
>> >> Paulo
>> >>
>>
Re: The clustering discussion - again ;-)
Posted by Manu George <ma...@gmail.com>.
Yes I understand that random will work but how about others like round
robin etc? Are we planning to support only the random strategy?
On 6/14/07, Jeff Genender <jg...@apache.org> wrote:
>
>
> Manu George wrote:
> > As per what I understood if one of the servers are down then the
> > client will call the next one in the list which would send it a new id
> > after which all calls will be to that one.
>
> You are assuming no policy for how a client chooses a server and that
> its linear. Consider it random and this issue goes away.
>
> > But in order to decide
> > which server to pick based on the load balancing strategy used I think
> > we may need more information to be passed to the client. Once this
> > discussion is finished i think we should put this in a wiki page as it
> > provides good insights on clustering and the logic used. I can
> > probably do that if no one else wants it :)
> >
> > Regards
> > Manu
> >
> > On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> >> The idea of id download on the first connection doesn't seem nice to
> >> me. Assume the following scenario:
> >>
> >> you have a cluster of 3 servers, and the 3 are aware of the other by
> >> their internal configuration. (no discovery inside the cluster). The
> >> client receives the list of 3 servers and now has to decide which one
> >> to connect. It is clear here that the client needs to know some more
> >> about the server to decide which one to pick in order to share the
> >> load balancing in the cluster, more there is no way for the client to
> >> know if one of the servers is down and if it is that server is removed
> >> from the list and never connected again during that request.
> >>
> >> My idea is that perhaps we would better have a small extra server that
> >> i will call a service dispatcher, that is the central point for the
> >> cluster. no need to change the openejb code each server still works in
> >> a isolated way. The SD would have the configurations of where the
> >> openejb nodes are in the cluster and their status (up/down).
> >>
> >> The clients would then connect to the SD and the SD would query the
> >> list of servers, and forward to the next available one. Metrics could
> >> be gathered from the SD such as time between query and response from
> >> OEJB making a simple (not so accurate) load balancer system.
> >>
> >> Paulo
> >>
>
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Good Ideas Manu and Paulo. But what Paulo suggested is a sort of centralized
load balancing, but I would suggest a de-centeralized load balancing. I am
not so experienced in this subject, but lets say that these info about all
servers and their load are distributed and shared among all servers in the
cluster, so if a client sends a request to a server, even if it is the
initial server of this client, the server can decide that it has to dispatch
this request to another un-loaded server to serve the request, this way we
can guarantee that these info are available even if we have one node in the
cluster, cause the SD may go down too like any other server in the cluster.
I suggest that we have to document all this brain storming outcomes, and to
start with the simple scenario Jeff explained in his first mail in this
thread. comments ???
On 6/14/07, Manu George <ma...@gmail.com> wrote:
>
> As per what I understood if one of the servers are down then the
> client will call the next one in the list which would send it a new id
> after which all calls will be to that one. But in order to decide
> which server to pick based on the load balancing strategy used I think
> we may need more information to be passed to the client. Once this
> discussion is finished i think we should put this in a wiki page as it
> provides good insights on clustering and the logic used. I can
> probably do that if no one else wants it :)
>
> Regards
> Manu
>
> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> > The idea of id download on the first connection doesn't seem nice to
> > me. Assume the following scenario:
> >
> > you have a cluster of 3 servers, and the 3 are aware of the other by
> > their internal configuration. (no discovery inside the cluster). The
> > client receives the list of 3 servers and now has to decide which one
> > to connect. It is clear here that the client needs to know some more
> > about the server to decide which one to pick in order to share the
> > load balancing in the cluster, more there is no way for the client to
> > know if one of the servers is down and if it is that server is removed
> > from the list and never connected again during that request.
> >
> > My idea is that perhaps we would better have a small extra server that
> > i will call a service dispatcher, that is the central point for the
> > cluster. no need to change the openejb code each server still works in
> > a isolated way. The SD would have the configurations of where the
> > openejb nodes are in the cluster and their status (up/down).
> >
> > The clients would then connect to the SD and the SD would query the
> > list of servers, and forward to the next available one. Metrics could
> > be gathered from the SD such as time between query and response from
> > OEJB making a simple (not so accurate) load balancer system.
> >
> > Paulo
> >
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Manu George wrote:
> As per what I understood if one of the servers are down then the
> client will call the next one in the list which would send it a new id
> after which all calls will be to that one.
You are assuming no policy for how a client chooses a server and that
its linear. Consider it random and this issue goes away.
> But in order to decide
> which server to pick based on the load balancing strategy used I think
> we may need more information to be passed to the client. Once this
> discussion is finished i think we should put this in a wiki page as it
> provides good insights on clustering and the logic used. I can
> probably do that if no one else wants it :)
>
> Regards
> Manu
>
> On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
>> The idea of id download on the first connection doesn't seem nice to
>> me. Assume the following scenario:
>>
>> you have a cluster of 3 servers, and the 3 are aware of the other by
>> their internal configuration. (no discovery inside the cluster). The
>> client receives the list of 3 servers and now has to decide which one
>> to connect. It is clear here that the client needs to know some more
>> about the server to decide which one to pick in order to share the
>> load balancing in the cluster, more there is no way for the client to
>> know if one of the servers is down and if it is that server is removed
>> from the list and never connected again during that request.
>>
>> My idea is that perhaps we would better have a small extra server that
>> i will call a service dispatcher, that is the central point for the
>> cluster. no need to change the openejb code each server still works in
>> a isolated way. The SD would have the configurations of where the
>> openejb nodes are in the cluster and their status (up/down).
>>
>> The clients would then connect to the SD and the SD would query the
>> list of servers, and forward to the next available one. Metrics could
>> be gathered from the SD such as time between query and response from
>> OEJB making a simple (not so accurate) load balancer system.
>>
>> Paulo
>>
Re: The clustering discussion - again ;-)
Posted by Manu George <ma...@gmail.com>.
As per what I understood if one of the servers are down then the
client will call the next one in the list which would send it a new id
after which all calls will be to that one. But in order to decide
which server to pick based on the load balancing strategy used I think
we may need more information to be passed to the client. Once this
discussion is finished i think we should put this in a wiki page as it
provides good insights on clustering and the logic used. I can
probably do that if no one else wants it :)
Regards
Manu
On 6/14/07, Paulo Lopes <pm...@gmail.com> wrote:
> The idea of id download on the first connection doesn't seem nice to
> me. Assume the following scenario:
>
> you have a cluster of 3 servers, and the 3 are aware of the other by
> their internal configuration. (no discovery inside the cluster). The
> client receives the list of 3 servers and now has to decide which one
> to connect. It is clear here that the client needs to know some more
> about the server to decide which one to pick in order to share the
> load balancing in the cluster, more there is no way for the client to
> know if one of the servers is down and if it is that server is removed
> from the list and never connected again during that request.
>
> My idea is that perhaps we would better have a small extra server that
> i will call a service dispatcher, that is the central point for the
> cluster. no need to change the openejb code each server still works in
> a isolated way. The SD would have the configurations of where the
> openejb nodes are in the cluster and their status (up/down).
>
> The clients would then connect to the SD and the SD would query the
> list of servers, and forward to the next available one. Metrics could
> be gathered from the SD such as time between query and response from
> OEJB making a simple (not so accurate) load balancer system.
>
> Paulo
>
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Paulo Lopes wrote:
> The idea of id download on the first connection doesn't seem nice to
> me. Assume the following scenario:
>
> you have a cluster of 3 servers, and the 3 are aware of the other by
> their internal configuration. (no discovery inside the cluster).
This not a correct assumption, there has to be discovery to make this
work or one could not effectively cluster w/o figuring out who is active
and in the cluster.
> The client receives the list of 3 servers and now has to decide which one
> to connect. It is clear here that the client needs to know some more
> about the server to decide which one to pick in order to share the
> load balancing in the cluster, more there is no way for the client to
> know if one of the servers is down and if it is that server is removed
> from the list and never connected again during that request.
>
I'm not sure I agree here. I think a policy would be sent and the
client stub can act in a DNS round-robin fashion or pick a server at
random, with the second being that it can effectively load-balance.
When the inital JNDI context is contacted, the client is given an
initial list, it can just randomly pick the first ejb server to make
contact with.
> My idea is that perhaps we would better have a small extra server that
> i will call a service dispatcher, that is the central point for the
> cluster. no need to change the openejb code each server still works in
> a isolated way. The SD would have the configurations of where the
> openejb nodes are in the cluster and their status (up/down).
>
Centralized server would not be prudent as its a single point of failure
and we are now enforcing a clustering implementation on this as opposed
to a SPI/API to plug clustering implementations into it.
> The clients would then connect to the SD and the SD would query the
> list of servers, and forward to the next available one. Metrics could
> be gathered from the SD such as time between query and response from
> OEJB making a simple (not so accurate) load balancer system.
>
> Paulo
Re: The clustering discussion - again ;-)
Posted by Paulo Lopes <pm...@gmail.com>.
The idea of id download on the first connection doesn't seem nice to
me. Assume the following scenario:
you have a cluster of 3 servers, and the 3 are aware of the other by
their internal configuration. (no discovery inside the cluster). The
client receives the list of 3 servers and now has to decide which one
to connect. It is clear here that the client needs to know some more
about the server to decide which one to pick in order to share the
load balancing in the cluster, more there is no way for the client to
know if one of the servers is down and if it is that server is removed
from the list and never connected again during that request.
My idea is that perhaps we would better have a small extra server that
i will call a service dispatcher, that is the central point for the
cluster. no need to change the openejb code each server still works in
a isolated way. The SD would have the configurations of where the
openejb nodes are in the cluster and their status (up/down).
The clients would then connect to the SD and the SD would query the
list of servers, and forward to the next available one. Metrics could
be gathered from the SD such as time between query and response from
OEJB making a simple (not so accurate) load balancer system.
Paulo
Re: The clustering discussion - again ;-)
Posted by Manu George <ma...@gmail.com>.
Yes you certainly are. I was able to get my doubts cleared on reading your post.
Regards
Manu
On 6/14/07, Mohammad Nour El-Din <no...@gmail.com> wrote:
> Cool I am genius ;-)
>
> On 6/13/07, Jeff Genender <jg...@apache.org> wrote:
> >
> >
> >
> > Mohammad Nour El-Din wrote:
> > > Just to make sure I am following this subject right.
> > >
> > > The client is going to have a servers list, and initially it will be
> > > attached to a server, lets say the server which created this client
> > > interface, and if for instance this server failed over the client is
> > going
> > > to use the next server in it current list which has a version VerX for
> > > example, and while the client is contacting the other server sending it
> > the
> > > request with the its current version, the server will find out that the
> > > version is not correct and it will respond to the client with the new
> > > version. Did I understand the whole discussion right ?
> >
> >
> > Yep.
> >
> > Jeff
> >
> >
> > >
> > >
> > > On 6/13/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> > >>
> > >>
> > >> On Jun 13, 2007, at 12:00 PM, Dain Sundstrom wrote:
> > >>
> > >> > Last time I helped with clustering (on another J2EE server), the
> > >> > term thrown around was "cluster topology", which is not only the
> > >> > membership of the server but the organization of the nodes in the
> > >> > cluster. Over time servers join and leave the cluster and nodes
> > >> > can be repurposed. After each mutation of the topology, the
> > >> > version number would increment (or the hash changes).
> > >>
> > >> What would help to mitigate this issue would be to have some value
> > >> that indicates a state change of the server and include this in the
> > >> hash calculation.
> > >>
> > >
> > >
> > >
> >
>
>
>
> --
> Thanks
> - Mohammad Nour
>
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
lichtner wrote:
> Are you going to save the version number to disk for when you want to shut
> the whole cluster down?
No...it will not be saved. It will be recalculated on any changes to
the nodes.
Jeff
>
> On Wed, 13 Jun 2007, Dain Sundstrom wrote:
>
>> On Jun 13, 2007, at 6:19 AM, Matt Hogstrom wrote:
>>
>>> So what does the version number represent exactly? I assumed it
>>> was basically the state of active members of the cluster at a point
>>> in time.
>> Last time I helped with clustering (on another J2EE server), the term
>> thrown around was "cluster topology", which is not only the
>> membership of the server but the organization of the nodes in the
>> cluster. Over time servers join and leave the cluster and nodes can
>> be repurposed. After each mutation of the topology, the version
>> number would increment (or the hash changes).
>>
>> -dain
>>
Re: The clustering discussion - again ;-)
Posted by lichtner <li...@bway.net>.
Are you going to save the version number to disk for when you want to shut
the whole cluster down?
On Wed, 13 Jun 2007, Dain Sundstrom wrote:
> On Jun 13, 2007, at 6:19 AM, Matt Hogstrom wrote:
>
> > So what does the version number represent exactly? I assumed it
> > was basically the state of active members of the cluster at a point
> > in time.
>
> Last time I helped with clustering (on another J2EE server), the term
> thrown around was "cluster topology", which is not only the
> membership of the server but the organization of the nodes in the
> cluster. Over time servers join and leave the cluster and nodes can
> be repurposed. After each mutation of the topology, the version
> number would increment (or the hash changes).
>
> -dain
>
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Cool I am genius ;-)
On 6/13/07, Jeff Genender <jg...@apache.org> wrote:
>
>
>
> Mohammad Nour El-Din wrote:
> > Just to make sure I am following this subject right.
> >
> > The client is going to have a servers list, and initially it will be
> > attached to a server, lets say the server which created this client
> > interface, and if for instance this server failed over the client is
> going
> > to use the next server in it current list which has a version VerX for
> > example, and while the client is contacting the other server sending it
> the
> > request with the its current version, the server will find out that the
> > version is not correct and it will respond to the client with the new
> > version. Did I understand the whole discussion right ?
>
>
> Yep.
>
> Jeff
>
>
> >
> >
> > On 6/13/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >>
> >>
> >> On Jun 13, 2007, at 12:00 PM, Dain Sundstrom wrote:
> >>
> >> > Last time I helped with clustering (on another J2EE server), the
> >> > term thrown around was "cluster topology", which is not only the
> >> > membership of the server but the organization of the nodes in the
> >> > cluster. Over time servers join and leave the cluster and nodes
> >> > can be repurposed. After each mutation of the topology, the
> >> > version number would increment (or the hash changes).
> >>
> >> What would help to mitigate this issue would be to have some value
> >> that indicates a state change of the server and include this in the
> >> hash calculation.
> >>
> >
> >
> >
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Mohammad Nour El-Din wrote:
> Just to make sure I am following this subject right.
>
> The client is going to have a servers list, and initially it will be
> attached to a server, lets say the server which created this client
> interface, and if for instance this server failed over the client is going
> to use the next server in it current list which has a version VerX for
> example, and while the client is contacting the other server sending it the
> request with the its current version, the server will find out that the
> version is not correct and it will respond to the client with the new
> version. Did I understand the whole discussion right ?
Yep.
Jeff
>
>
> On 6/13/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>
>>
>> On Jun 13, 2007, at 12:00 PM, Dain Sundstrom wrote:
>>
>> > Last time I helped with clustering (on another J2EE server), the
>> > term thrown around was "cluster topology", which is not only the
>> > membership of the server but the organization of the nodes in the
>> > cluster. Over time servers join and leave the cluster and nodes
>> > can be repurposed. After each mutation of the topology, the
>> > version number would increment (or the hash changes).
>>
>> What would help to mitigate this issue would be to have some value
>> that indicates a state change of the server and include this in the
>> hash calculation.
>>
>
>
>
Re: The clustering discussion - again ;-)
Posted by Mohammad Nour El-Din <no...@gmail.com>.
Just to make sure I am following this subject right.
The client is going to have a servers list, and initially it will be
attached to a server, lets say the server which created this client
interface, and if for instance this server failed over the client is going
to use the next server in it current list which has a version VerX for
example, and while the client is contacting the other server sending it the
request with the its current version, the server will find out that the
version is not correct and it will respond to the client with the new
version. Did I understand the whole discussion right ?
On 6/13/07, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
>
> On Jun 13, 2007, at 12:00 PM, Dain Sundstrom wrote:
>
> > Last time I helped with clustering (on another J2EE server), the
> > term thrown around was "cluster topology", which is not only the
> > membership of the server but the organization of the nodes in the
> > cluster. Over time servers join and leave the cluster and nodes
> > can be repurposed. After each mutation of the topology, the
> > version number would increment (or the hash changes).
>
> What would help to mitigate this issue would be to have some value
> that indicates a state change of the server and include this in the
> hash calculation.
>
--
Thanks
- Mohammad Nour
Re: The clustering discussion - again ;-)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jun 13, 2007, at 12:00 PM, Dain Sundstrom wrote:
> Last time I helped with clustering (on another J2EE server), the
> term thrown around was "cluster topology", which is not only the
> membership of the server but the organization of the nodes in the
> cluster. Over time servers join and leave the cluster and nodes
> can be repurposed. After each mutation of the topology, the
> version number would increment (or the hash changes).
What would help to mitigate this issue would be to have some value
that indicates a state change of the server and include this in the
hash calculation.
Re: The clustering discussion - again ;-)
Posted by Dain Sundstrom <da...@iq80.com>.
On Jun 13, 2007, at 6:19 AM, Matt Hogstrom wrote:
> So what does the version number represent exactly? I assumed it
> was basically the state of active members of the cluster at a point
> in time.
Last time I helped with clustering (on another J2EE server), the term
thrown around was "cluster topology", which is not only the
membership of the server but the organization of the nodes in the
cluster. Over time servers join and leave the cluster and nodes can
be repurposed. After each mutation of the topology, the version
number would increment (or the hash changes).
-dain
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Matt Hogstrom wrote:
> So what does the version number represent exactly? I assumed it was
> basically the state of active members of the cluster at a point in time.
>
Well, it does represent the state of active members...but its more of a
way to flag when the list of servers needs to go to the client. i.e. if
I have 20 servers in my cluster, I don't want to send that list on every
call...only when the list changes (entry or exit from a cluster). This
is a lightweight way to notify the client when it needs a refresh.
Jeff
> On Jun 12, 2007, at 6:35 PM, Jeff Genender wrote:
>
>>
>>
>> David Blevins wrote:
>>> I think that might have been an Amelia "no" (i.e. a yes).
>>
>> Hehe! I know that "No" too ;-)
>>
>>> You saying
>>> you like the idea of the server sending the md5 down and having the
>>> client simply send it back, no inspection on the client side -- i.e. the
>>> version number idea from before but sending the md5 as we would have
>>> sent the version number? Or are you referring to the same version
>>> number idea as before?
>>
>> Kind of a hybrid. The MD5 would be the number...that is the "version"
>> so-to-speak. Server will check if that number matches its own (it was
>> calculated when it first had a cluster setup). If they are the same,
>> its business as usual. If the cluster changes, then the server changes
>> its number and then there is a difference the next time the client comes
>> knocking. Thus an update will occur.
>>
>> The reason why I like to use the MD5 as the version number is all
>> servers theoretically would calculate the same MD5 (or even a simpler
>> lighter algo) and thus always have the same version number w/o having to
>> share that between all servers.
>>
>> Jeff
>>
>>>
>>> -David
>>
Re: The clustering discussion - again ;-)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
So what does the version number represent exactly? I assumed it was
basically the state of active members of the cluster at a point in time.
On Jun 12, 2007, at 6:35 PM, Jeff Genender wrote:
>
>
> David Blevins wrote:
>> I think that might have been an Amelia "no" (i.e. a yes).
>
> Hehe! I know that "No" too ;-)
>
>> You saying
>> you like the idea of the server sending the md5 down and having the
>> client simply send it back, no inspection on the client side --
>> i.e. the
>> version number idea from before but sending the md5 as we would have
>> sent the version number? Or are you referring to the same version
>> number idea as before?
>
> Kind of a hybrid. The MD5 would be the number...that is the "version"
> so-to-speak. Server will check if that number matches its own (it was
> calculated when it first had a cluster setup). If they are the same,
> its business as usual. If the cluster changes, then the server
> changes
> its number and then there is a difference the next time the client
> comes
> knocking. Thus an update will occur.
>
> The reason why I like to use the MD5 as the version number is all
> servers theoretically would calculate the same MD5 (or even a simpler
> lighter algo) and thus always have the same version number w/o
> having to
> share that between all servers.
>
> Jeff
>
>>
>> -David
>
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
David Blevins wrote:
> I think that might have been an Amelia "no" (i.e. a yes).
Hehe! I know that "No" too ;-)
> You saying
> you like the idea of the server sending the md5 down and having the
> client simply send it back, no inspection on the client side -- i.e. the
> version number idea from before but sending the md5 as we would have
> sent the version number? Or are you referring to the same version
> number idea as before?
Kind of a hybrid. The MD5 would be the number...that is the "version"
so-to-speak. Server will check if that number matches its own (it was
calculated when it first had a cluster setup). If they are the same,
its business as usual. If the cluster changes, then the server changes
its number and then there is a difference the next time the client comes
knocking. Thus an update will occur.
The reason why I like to use the MD5 as the version number is all
servers theoretically would calculate the same MD5 (or even a simpler
lighter algo) and thus always have the same version number w/o having to
share that between all servers.
Jeff
>
> -David
Re: The clustering discussion - again ;-)
Posted by David Blevins <da...@visi.com>.
On Jun 12, 2007, at 12:09 PM, Jeff Genender wrote:
>
>
> David Blevins wrote:
>>
>> I guess we never really talked about how each server would get the
>> list
>> of peers in the cluster. Depending on how we do that, we could
>> return
>> to the md5'ed list idea but not the way it was proposed where the
>> hash
>> would be calculated by both sides on every request -- at least that's
>> the way i read it.
>
> Nah...I think we calculate it on the server when the cluster
> changes and
> that becomes the version number that is sent to the client. The
> client
> doesn't need to worry about any calculations, and the server will only
> test if the version has changed in order to send down a new copy of
> the
> version and list. Therefore its a calc that only happens very rarely.
>
> How does that sound?
I think that might have been an Amelia "no" (i.e. a yes). You saying
you like the idea of the server sending the md5 down and having the
client simply send it back, no inspection on the client side -- i.e.
the version number idea from before but sending the md5 as we would
have sent the version number? Or are you referring to the same
version number idea as before?
-David
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
David Blevins wrote:
>
> I guess we never really talked about how each server would get the list
> of peers in the cluster. Depending on how we do that, we could return
> to the md5'ed list idea but not the way it was proposed where the hash
> would be calculated by both sides on every request -- at least that's
> the way i read it.
Nah...I think we calculate it on the server when the cluster changes and
that becomes the version number that is sent to the client. The client
doesn't need to worry about any calculations, and the server will only
test if the version has changed in order to send down a new copy of the
version and list. Therefore its a calc that only happens very rarely.
How does that sound?
Jeff
Re: The clustering discussion - again ;-)
Posted by David Blevins <da...@visi.com>.
On Jun 12, 2007, at 10:23 AM, Jeff Genender wrote:
>
>
> Matt Hogstrom wrote:
>> Wouldn't the server's themselves be operating off of some version
>> number
>> so they can synchronize their own state?
>> It would seem that this would be the same version number.
>
> Yeah...actually a hash of the server list seemed to be a way to
> calculate a version number across servers, so its in-sync based on the
> cluster state. But Mr Blevins talked me out of this ;-)
I guess we never really talked about how each server would get the
list of peers in the cluster. Depending on how we do that, we could
return to the md5'ed list idea but not the way it was proposed where
the hash would be calculated by both sides on every request -- at
least that's the way i read it.
-David
>>
>> On Jun 11, 2007, at 5:04 PM, Jeff Genender wrote:
>>
>>> Ok...so now that we have passed the TCK...I can get back and
>>> concentrate
>>> on some fun stuff, so I wanted to bring up the old discussion
>>> again of
>>> getting a clustering API pinned up on OpenEJB. The whole idea on
>>> this
>>> is to allow different clustering components to tie into the product.
>>>
>>> Before I stopped and did TCK testing, I got as far as adding the
>>> ability
>>> to handle multiple URLs in the client/server to allow for failover.
>>>
>>> Now that I am getting back to the meat of the design here, I
>>> wanted to
>>> go over at a high level of the direction I am taking this.
>>>
>>> 1) The client need to get an initial list of servers in the
>>> cluster. I
>>> assume this can occur during the first initial context handshake.
>>>
>>> 2) A version number is applied and sent along with the list.
>>>
>>> 3) Every time the client speaks to the server is sends along the
>>> version
>>> number. If the version is different, the server sends down a new
>>> list,
>>> along with the new version number.
>>>
>>> 4) The server updates the list only when the servers in the
>>> cluster have
>>> changed.
>>>
>>> Thoughts and comments?
>>>
>>> Jeff
>>>
>
Re: The clustering discussion - again ;-)
Posted by Jeff Genender <jg...@apache.org>.
Matt Hogstrom wrote:
> Wouldn't the server's themselves be operating off of some version number
> so they can synchronize their own state?
> It would seem that this would be the same version number.
Yeah...actually a hash of the server list seemed to be a way to
calculate a version number across servers, so its in-sync based on the
cluster state. But Mr Blevins talked me out of this ;-)
>
> On Jun 11, 2007, at 5:04 PM, Jeff Genender wrote:
>
>> Ok...so now that we have passed the TCK...I can get back and concentrate
>> on some fun stuff, so I wanted to bring up the old discussion again of
>> getting a clustering API pinned up on OpenEJB. The whole idea on this
>> is to allow different clustering components to tie into the product.
>>
>> Before I stopped and did TCK testing, I got as far as adding the ability
>> to handle multiple URLs in the client/server to allow for failover.
>>
>> Now that I am getting back to the meat of the design here, I wanted to
>> go over at a high level of the direction I am taking this.
>>
>> 1) The client need to get an initial list of servers in the cluster. I
>> assume this can occur during the first initial context handshake.
>>
>> 2) A version number is applied and sent along with the list.
>>
>> 3) Every time the client speaks to the server is sends along the version
>> number. If the version is different, the server sends down a new list,
>> along with the new version number.
>>
>> 4) The server updates the list only when the servers in the cluster have
>> changed.
>>
>> Thoughts and comments?
>>
>> Jeff
>>
Re: The clustering discussion - again ;-)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Wouldn't the server's themselves be operating off of some version
number so they can synchronize their own state?
It would seem that this would be the same version number.
On Jun 11, 2007, at 5:04 PM, Jeff Genender wrote:
> Ok...so now that we have passed the TCK...I can get back and
> concentrate
> on some fun stuff, so I wanted to bring up the old discussion again of
> getting a clustering API pinned up on OpenEJB. The whole idea on this
> is to allow different clustering components to tie into the product.
>
> Before I stopped and did TCK testing, I got as far as adding the
> ability
> to handle multiple URLs in the client/server to allow for failover.
>
> Now that I am getting back to the meat of the design here, I wanted to
> go over at a high level of the direction I am taking this.
>
> 1) The client need to get an initial list of servers in the
> cluster. I
> assume this can occur during the first initial context handshake.
>
> 2) A version number is applied and sent along with the list.
>
> 3) Every time the client speaks to the server is sends along the
> version
> number. If the version is different, the server sends down a new
> list,
> along with the new version number.
>
> 4) The server updates the list only when the servers in the cluster
> have
> changed.
>
> Thoughts and comments?
>
> Jeff
>