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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>> >> >>>>>>
>> >> >>>>
>> >> >>
>> >>
>> >
>> >
>>
>
>
