Rajith,
I'll have a crack at these and then if Jeff wants to add anything I'm
sure he will :-)
please see inline...
Rajith Attapattu wrote:
Jeff,
I am currently involved with JavaMail implementations so haven't had
much time to look at the clustering side. Will do soon after the mail
thingy is done.
However can please comment on the points stated below so when you are
done with the 1.0 release and me with the JavaMail thing, we can
continue with the clustering conversation.
Thanks,
Rajith
-----Original Message-----
From: Rajith Attapattu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 30, 2005 7:29 PM
To: dev@geronimo.apache.org; [EMAIL PROTECTED]
Subject: RE: [Geronimo] Clustering
Jeff,
We maybe able to leverage the Apache Directory for the underlying JNDI
aspect of it (I will look in to this, but might need help)
How about the policy management portion of clustering service??
For ex
Clustering strategy
======================
Whether to use Sticky vs Random vs other load balancing mechanisms or
are we allowing the user to choose a strategy from above.
OK - lets get down to brass tacks.
Ultimately we will need a number of different policies including those
that you have outlined above.
Different policies will suit different types of bean and different use
cases and it would be good to put together some sort of list of common
combinations.
Here is a start...
This is all straight off the top of my head - so be gentle :-)
I think we probably can assume homogeneous JNDI population - i.e. all
JNDI services carry exactly the same information - otherwise a client
would have to visit all of them to be sure that a service it required
did not exist. This means that deploying a new JNDI entry is expensive
(since it has to update all JNDI service replicas), but the deployment
of new entries is an exceptional event, whereas client lookup is a
common event - so we keep the common event cheap and the exceptional one
pays the price.
So, somehow (probably initially via some sort of autodiscovery
mechanism) the client hooks up with a jndi service replica and asks it
for a EJBHome stub.
This stub is returned from JNDI to the Client.
I guess the JNDI service could be cluster-aware and package recent
information about cluster membership with the stub back to the client
(proprietary protocol required?), or it could be dumb, in which case the
newly demarshalled stub may have to obtain this information for itself -
by having had some information about the cluster's membership and
auto-discovery handle (e.g. multicast address) serialised with it
(possibly a long time before it is finally used - so the membership data
may be stale and need refreshing via autodiscovery).
I guess we will at least want to have the opportunity of colocating all
serverside resources associated with a single user - since this will
greatly improve our response to said user. This also creates a handy way
to begin partitioning the problem that we might end up with if we just
created every ejb on a random box then hooked them all up together. So,
there is a good usecase here for requiring some sort of 'stickiness'
immediately.
So, it looks like we need two types of Home stub - a sticky one, which
might look at a unique userid held within the client (can we do this?)
and use this to map this user to a particular server and a non-sticky
type, which might use a variety of pluggable algorithms (or subtypes)
including random (but also e.g. trying to find the least loaded server,
the nearest server etc...). (there is also another type of stickiness
where we use the non-sticky algorithm to choose an initial server, then
go back to the same one thenceforth - but this does not give us such
finegrained control over the colocation of resources belonging to the
same user - perhaps we call this per-server stickiness).
So - when I talk about sticky here - I am talking about per-user
stickiness (all invocations from the same user go to the same target)
not just per-bean stickiness (all invocations for the same bean go to
the same server).
Lets say the client uses the Home stub to create an EJB instance for
which it receives a client-side stub. Lets examine the different
possibilities.
SLSB -
Logically it does not matter (in a homogeneous deployment) where
invocations for a SLSB (I'm open to correction on all of this - my EJB
is very rusty) might land. A SLSB should be lightweight and be able to
be transparently brought into existance underneath the incoming
invocation, service it and then be trashed (of course containers pool
etc. to reduce overheads associated with this sort of thing). So, we
have a good usecase for non-sticky behaviour in the SLSB stub here.
In reality, it is likely that this SLSB will access further resources
associated with the client that may be more expensive to pop in and out
of existance (e.g. Entities), so there is a good case for a per-Bean or
per-User (or per-Server?) sticky behaviour here.
SFSB -
The reverse of the SLSB.
Logically it does matter where invocations fall. If the state held in
the SFSB is tied to a single JVM then we would expect a
per-User/Bean/Server sticky algorithm in this sort of stub.
In reality, hopefully, the associated SFSB will be WADI-enabled and able
to travel to wherever it is needed. So, a non-sticky algorithm would
also work, but would probably be rather sub-optimal :-)
Entity -
More like an SLSB, I guess. Logically an Entity should be able to spring
into existance anywhere it is needed. In reality there is cost
associated with this. Cache hits are good, Cache misses are bad - So,
again, all algorithms should work, but a sticky variant is probably the
most common deployment option.
On the server-side, these different policies should tie up with some
ideas that I have discussed on the list about the way that a users
remote resources may be colocated in some sort of SuperSession (maybe a
UserSession or an ApplicationSession (maybe a per-Application stickiness
is also required) (colocates resources from various applications and
tiers that are all associated with the same application-and-user or just
user). So choosing a particular ServSide impl would constrain the
possible client-side load-balancing algorithms available to the
application i.e. they walk hand in hand. Unless we want to be really
outrageous (Geronimo-4.0?), these choices should be made at deployment
time, by humans with knowledge of the layout of the application
components within the cluster and their expected behaviour.....
I think that is it for the moment !
Apologies for the rather rambling nature of my thoughts on this - I
haven't really thought about this stuff rigorously yet, but this should
be enough to share where I am with the list.
Jules
P.S.
We need to figure out how the various forms of stickiness are maintained
when a node dies or voluntarily leaves a cluster. There is lots to talk
about.
We can represent each clustering strategy as a GBean which the user can
pick from (under the Clustering services GBean, I assume you have the
whole clustering feature represented as a GBean ).
So if somebody is not happy about the clustering strategy then simply
write there own and add that as a GBean.
Of course we will have to come up with a neat API for exposing the
aspects that should be open for improvement.
This will also help us to come up with better clustering strategies
later on in the future without a major impact on the code base.
What are your thoughts on this??? Everybody please help with ideas :)
Regards,
Rajith Attapattu.
-----Original Message-----
From: Jeff Genender [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 30, 2005 1:13 PM
To: dev@geronimo.apache.org
Subject: Re: [Geronimo] Clustering
Rajith Attapattu wrote:
Jeff,
Apologize for late reply, down with flu.
Is high availability JNDI (or JNDI clustering) a concept brought up by
JBoss??
I don't know the answer to this question.
Frankly I am no expert on this, so any pointers will be very helpful.
I
see that WADI is yet to implement this. So do u have any documentation
on this?
This is an area we are all starting to look at. One area I would
recommend looking at is seeing if we can leverage the Apache Directory
to handle the HA component of JNDI. If so, this may be a much simpler
job.
Thanks for helping out...this is great to have more folks chipping in on
this.
I assume we will follow the jboss concept closely, but hopefully to
improve on it.
Any help is greatly appreciated.
Rajith.
-----Original Message-----
From: Jeff Genender [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 1:00 PM
To: dev@geronimo.apache.org
Subject: Re: [Geronimo] Clustering
Rajith Attapattu wrote:
As per Jeff's request I am currently ramping up on WADI. I guess jeff
will shortly announce the integration or any other intermediate tasks
that needs to be done before WADI can be integrated.
I guess we will have some discussion on what areas we will work on
when the plan is announced??
Jeff can you pls comment on this?
I think we just need a couple of Gbeans to get it initially integrated
in the web tier...I will tackle that. It currently works under Tomcat
and Jetty in their standalone configurations. Gianni is currently
working on the OpenEJB session integration with WADI...and we look
forward to getting that.
We are interested in the HA JNDI...so lets definitely get some
discussion going on that.
Jeff
With Kind Regards,
Rajith Attapattu.
________________________________________
From: Panda, Akshaya Kumar (Cognizant)
[mailto:[EMAIL PROTECTED]
Sent: Sunday, November 27, 2005 11:42 PM
To: dev@geronimo.apache.org
Subject: RE: [Geronimo] Road Map and TODO
Jeff/Rajith,
Yes i will be intersted to work on this. But before jumping in on, i
would like to know who all are involved in what areas so that it
can
help me to avoid any duplicate effort.
Rajith: can you pl outline what you have planned to do?
thanks
akshay
-----Original Message-----
From: Jeff Genender [mailto:[EMAIL PROTECTED]
Sent: Sat 11/26/2005 9:17 PM
To: dev@geronimo.apache.org
Subject: Re: [Geronimo] Road Map and TODO
Panda, Akshaya Kumar (Cognizant) wrote:
I think WADI is going to provide web tier clustering, any initiative
for HA-JNDI?
thanks
Akshay
No, WADI (and probably should be renamed remove the web-only
connotations) will be providing all HA facets to Geronimo. If you
are
interested in this area, this is where we could use a helping hand,
so
feel free to jump in on this.
Jeff
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
