lichtner wrote:
>I would pick one type of clustering at a time, solve that problem, roll it
>out, and then move on to the next one. And I would specifically address
>each type of clustering requirement separately (e.g. http and entity
>beans) because the best solution is different in each case.
>
>
check out my 'Clustering Overview - 10.000 feet...' thread posted a
couple of hours ago - this is exactly what I have done :-)
Jules
>On Fri, 27 Jan 2006, Jules Gosnell wrote:
>
>
>
>>Paul McMahan wrote:
>>
>>
>>
>>>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 for 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 about 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?
>>>
>>>
>>Geronimo should have full knowledge at the container level.
>>
>>
>>
>>>-- 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? Or will each node be responsible for its own configuration?
>>>
>>>
>>I don't know if there has been any discussion of this ? I think that IBM
>>donated a control panel of some sort but I haven't seen it and don't
>>know if it covers deployment.
>>
>>There is some stuff of relevance in the clustering overview that I just
>>posted.
>>
>>I would like to see a situation where you can [un]deploy to/from any
>>node in the [sub]cluster. This would perform the same operation on all
>>nodes in that [sub]cluster. Essentially, applications become 1->all
>>replicated data.
>>
>>This is a very simplistic view - as it is probably not useful to
>>synchronise the lifecycle of instances of the same app around the
>>cluster, otherwise you can't stop one without stopping them all (but
>>maybe this is what you want?) - maybe we need a synchronised and
>>non-sychronised mode...?
>>
>>Of course, it may be that this conversation has already been had and
>>decisions made elsewhere ? In which case, I would be interested in
>>knowing the outcome so that I can update the clustering overview and add
>>pointers to the necessary threads/people etc...
>>
>>
>>
>>>-- 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?
>>>
>>>
>>I'm not aware that anyone has drilled down this far yet, into how a
>>unified approach might work, but I suspect that we will end up with some
>>form of ClusterGBean which provides the node's connection to the Cluster
>>(an activecluster.Cluster), notification of other nodes leaving and
>>joining, messaging primitives etc. A clustering portlet might register
>>listeners with this.
>>
>>
>>
>>>-- Is each member of a cluster assumed to be using an identical
>>>configuration?
>>>
>>>
>>In a homogeneous cluster yes - but I think that we will have to cater
>>for heterogeneous deployments. There is a nascent section in the
>>overview doc about this.
>>
>>
>>
>>>-- Will G be able to participate in heterogeneous clusters with other
>>>types of app servers and/or versions of G?
>>>
>>>
>>I don't know whether anyone else has considered mixing (a) appservers or
>>(b) geronimo versions in the same cluster - I haven't. I think (a)
>>unlikely (unless you are talking about e.g. a business tier that is
>>geronimo and a web-tier that is standalone Jetty/Tomcat, which I guess
>>might be possible, but i suspect that both tiers would just be geronimo
>>running different configurations), (b) is more possible, provided that
>>the protocols used by the different clustering components were
>>compatible. With the amount of complexity already surrounding
>>clustering, though, I think you would just be making your life much more
>>difficult than it need be.
>>
>>Hope that helps,
>>
>>
>>Jules
>>
>>
>>
>>>Looking forward to your feedback and advice.
>>>
>>>Best wishes,
>>>Paul
>>>
>>>
>>>
>>>On 1/26/06, *David Jencks* <david_jencks@yahoo.com
>>><mailto: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
>>>
>>>
>>>
>>>
>>--
>>"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.
>> **********************************/
>>
>>
>>
>>
--
"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.
**********************************/
|