Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of paulmcmahan@gmail.com designates
 66.249.92.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Y80+mqKWSp6R1GHPMK93eCJYj1iq6gKSuic8Z9HPiyHkLK/zeu5Pxdj0vRZtvEnyWyn+w6mVnf/2RATwzyfTSmb7UpbTCGVYuYdJeV+PwdddgTjC+jcwjNPbxvGaGm98BjO4zfTwUg8mobKO85ZrIB8dhBt7HgrKdm1jeIY+aig=
Message-ID: <21df75940601270802w1d09ab9r4fab1e2af395d56b@mail.gmail.com>
Date: Fri, 27 Jan 2006 11:02:50 -0500
From: Paul McMahan <paulmcmahan@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: web clustering componentization
In-Reply-To: <9C84CFA6-689D-4C35-A664-E86F54179F08@yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1013_2566642.1138377770514"
References: <9C84CFA6-689D-4C35-A664-E86F54179F08@yahoo.com>

------=_Part_1013_2566642.1138377770514
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thanks for initiating this important conversation.  As part of the
clustering effort I would like to work on a new admin portlet that can be
used to visualize the cluster topology and do things like set properties fo=
r
the session managers, deploy/undeploy applications, etc.  I think that
making this aspect of Geronimo intuitive and easy to use will be a big
differentiator in our favor.  I would love to hear everyone's feedback abou=
t
this idea.  E.g. given our current direction does this idea make sense? and
what should it look like?

If we are generally in favor of this idea then before proceeding I would
need help understanding certain fundamental concepts of our approach, such
as:

-- Will G have explicit knowledge and control over clustering or will it
just be "embedded" within the applications' logic/configuration?
-- Will G follow a deployment manager paradigm where a certain node is in
charge of managing the entire config and pushing it to the worker nodes?  O=
r
will each node be responsible for its own configuration?
-- What component(s) of G will provide an interface to the clustering
metadata and config?  Would it be possible to provide a single point of
control in G that can take as input a clustering "plan" and handle the
resulting deployments and node configuration?
-- Is each member of a cluster assumed to be using an identical
configuration?
-- Will G be able to participate in heterogeneous clusters with other types
of app servers and/or versions of G?

Looking forward to your feedback and advice.

Best wishes,
Paul


On 1/26/06, David Jencks <david_jencks@yahoo.com > wrote:
>
> I have some ideas about how to set up web clustering in terms of
> geronimo modules and configurations and connections between gbeans.
> I've talked with Jules and Jeff about this and think that they agree
> that this is a good starting point so I'll try to describe it and
> possibly even help implement parts of it.
>
> There are quite a few questions I'm going to ignore, such as EJB SFSB
> clustering and the new session module James and Dain wrote and how it
> might relate to the web clustering stuff.  We have to start somewhere.
>
> For me, one of the most important factors is that the clustering
> solution be pluggable, in particular that you be able to run geronimo
> without any clustering classes.  This means that each clustering
> solution needs to be packaged in one or more Configurations or
> modules and that communication to the clustering module be done
> through interfaces defined in a more core geronimo module.  It also
> implies that the all the web containers should communicate with the
> clustering implementation through the same interface(s).
>
> I'm proposing that the interfaces be SessionManagerFactory and
> SessionManager, the factory being able to provide SessionManager
> instances.  I see the SessionManagerFactory being deployed as a GBean
> and made available to web containers through a gbean reference.
>
> My understanding is that for both jetty and tomcat, the web app
> context needs an instance of a session manager.  Therefore I propose
> giving each web app context a reference to the session manager
> factory gbean.  At an appropriate lifecycle point it can get the
> session manager it needs.  In Tomcat IIUC a host or engine can also
> be where a session manager is configured.  We don't really need to
> support that directly since we can in our deployer push a reference
> to whatever "global" session manager may be configured down into each
> web app context.
>
> I see the jetty and tomcat builders installing references to
> appropriate session manager factory gbeans.  IIUC there is a lot of
> configuration possible for at least WADI, and we should be able to
> support running multiple session manager configurations at once, as
> follows:
>
> - there can be a default session manager (say WADI) configuration,
> and the name of its session manager factory gbean can be configured
> in the web app builder(s).  This will be used for distributable web
> apps that don't specify in their plan a different session manager
> factory gbean.
>
> - a web app plan can contain an explicit reference to a specific
> session manager factory or an entire session manager factory/WADI
> configuration.
>
> - we can use a namespace driven xml-reference builder to construct a
> wadi configuration inside a SMF reference (maybe :-)
>
> There are a couple loose ends I can see and probably lots more I can't:
>
> -- I imagine we want to be able to have pluggable session managers
> for non distributable apps or in the absence of clustering.  I don't
> know if we'd want 2 "default" session manager factory gbeans
> available, one for cluster and one not, or if there is a better
> solution. Having 2 and having the builder decide which you get seems
> simplest at the moment.
>
> -- We need to be able to support the non-wadi existing tomcat-
> specific clustering, and it is unlikely this can be coerced
> effectively into the proposed geronimo SMF and SM interfaces.  We
> could support this with another gbean and interface, but at the
> moment I'm leaning towards giving the web app context either a
> separate gbean reference to the tomcat specific clustering or
> directly installing the tomcat solution into the web app context.
>
> Comments?  Flames?
>
> thanks
> david jencks
>
>

------=_Part_1013_2566642.1138377770514
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thanks for initiating this important conversation.&nbsp; As part of the
clustering effort I
would like to work on a new admin portlet that can be
used to visualize the cluster topology and do things like set
properties for the session managers, deploy/undeploy applications,
etc.&nbsp; I think that making this aspect of Geronimo intuitive and
easy to use will be a big differentiator in our favor.&nbsp; I would
love to hear everyone's feedback about this idea.&nbsp; E.g. given our
current direction does this idea make sense? and what should it look
like?<br>
<br>
If we are generally in favor of this idea then before proceeding I
would need help understanding certain fundamental concepts of our
approach, such as:<br>
<br>
-- Will G have explicit knowledge and control over clustering or will
it just be &quot;embedded&quot; within the applications' logic/configuratio=
n?<br>
-- Will G follow a deployment manager paradigm where a certain node is
in charge of managing the entire config and pushing it to the worker
nodes?&nbsp; Or will each node be responsible for its own configuration?<br=
>
-- What component(s) of G will provide an interface to the clustering
metadata and config?&nbsp; Would it be possible to provide a single
point of control in G that can take as input a clustering &quot;plan&quot; =
and
handle the resulting deployments and node configuration?<br>
-- Is each member of a cluster assumed to be using an identical configurati=
on?<br>
-- Will G be able to participate in heterogeneous clusters with other types=
 of app servers and/or versions of G?<br>
<br>
Looking forward to your feedback and advice.<br>
<br>
Best wishes,<br>
Paul<br>
<br>
<br><br><div><span class=3D"gmail_quote">On 1/26/06, <b class=3D"gmail_send=
ername">David Jencks</b> &lt;<a href=3D"mailto:david_jencks@yahoo.com" targ=
et=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,this)">davi=
d_jencks@yahoo.com
</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;">
I have some ideas about how to set up web clustering in terms of<br>geronim=
o modules and configurations and connections between gbeans.<br>I've talked=
 with Jules and Jeff about this and think that they agree<br>that this is a=
 good starting point so I'll try to describe it and
<br>possibly even help implement parts of it.<br><br>There are quite a few =
questions I'm going to ignore, such as EJB SFSB<br>clustering and the new s=
ession module James and Dain wrote and how it<br>might relate to the web cl=
ustering stuff.&nbsp;&nbsp;We have to start somewhere.
<br><br>For me, one of the most important factors is that the clustering<br=
>solution be pluggable, in particular that you be able to run geronimo<br>w=
ithout any clustering classes.&nbsp;&nbsp;This means that each clustering<b=
r>solution needs to be packaged in one or more Configurations or
<br>modules and that communication to the clustering module be done<br>thro=
ugh interfaces defined in a more core geronimo module.&nbsp;&nbsp;It also<b=
r>implies that the all the web containers should communicate with the<br>cl=
ustering implementation through the same interface(s).
<br><br>I'm proposing that the interfaces be SessionManagerFactory and<br>S=
essionManager, the factory being able to provide SessionManager<br>instance=
s.&nbsp;&nbsp;I see the SessionManagerFactory being deployed as a GBean<br>=
and made available to web containers through a gbean reference.
<br><br>My understanding is that for both jetty and tomcat, the web app<br>=
context needs an instance of a session manager.&nbsp;&nbsp;Therefore I prop=
ose<br>giving each web app context a reference to the session manager<br>fa=
ctory gbean.&nbsp;&nbsp;At an appropriate lifecycle point it can get the
<br>session manager it needs.&nbsp;&nbsp;In Tomcat IIUC a host or engine ca=
n also<br>be where a session manager is configured.&nbsp;&nbsp;We don't rea=
lly need to<br>support that directly since we can in our deployer push a re=
ference<br>to whatever &quot;global&quot; session manager may be configured=
 down into each
<br>web app context.<br><br>I see the jetty and tomcat builders installing =
references to<br>appropriate session manager factory gbeans.&nbsp;&nbsp;IIU=
C there is a lot of<br>configuration possible for at least WADI, and we sho=
uld be able to
<br>support running multiple session manager configurations at once, as<br>=
follows:<br><br>- there can be a default session manager (say WADI) configu=
ration,<br>and the name of its session manager factory gbean can be configu=
red
<br>in the web app builder(s).&nbsp;&nbsp;This will be used for distributab=
le web<br>apps that don't specify in their plan a different session manager=
<br>factory gbean.<br><br>- a web app plan can contain an explicit referenc=
e to a specific
<br>session manager factory or an entire session manager factory/WADI<br>co=
nfiguration.<br><br>- we can use a namespace driven xml-reference builder t=
o construct a<br>wadi configuration inside a SMF reference (maybe :-)<br>


<br>There are a couple loose ends I can see and probably lots more I can't:=
<br><br>-- I imagine we want to be able to have pluggable session managers<=
br>for non distributable apps or in the absence of clustering.&nbsp;&nbsp;I=
 don't
<br>know if we'd want 2 &quot;default&quot; session manager factory gbeans<=
br>available, one for cluster and one not, or if there is a better<br>solut=
ion. Having 2 and having the builder decide which you get seems<br>simplest=
 at the moment.
<br><br>-- We need to be able to support the non-wadi existing tomcat-<br>s=
pecific clustering, and it is unlikely this can be coerced<br>effectively i=
nto the proposed geronimo SMF and SM interfaces.&nbsp;&nbsp;We<br>could sup=
port this with another gbean and interface, but at the
<br>moment I'm leaning towards giving the web app context either a<br>separ=
ate gbean reference to the tomcat specific clustering or<br>directly instal=
ling the tomcat solution into the web app context.<br><br>Comments?&nbsp;&n=
bsp;Flames?
<br><br>thanks<br>david jencks<br><br></blockquote></div><br>

------=_Part_1013_2566642.1138377770514--