geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Date Fri, 13 Jan 2006 10:14:35 GMT

I am back.

David Jencks wrote:

> I agree with Jeff that this change is unsatisfactory but I'm not as  
> sure as he is that backing it out is necessary, perhaps we can move  
> forward to an acceptable solution instead.

I have to ask - on what grounds is it unsatisfactory ?
If backing out is unecessary, how do you propose moving forwards, now 
that this has been done ?

> I also am not so sure that this magnitude of change needs prior  
> discussion on the list.  I've frequently made larger changes without  
> discussion of my specific code.  I've also broken lots of stuff at  
> various times.

Jeff has still to demostrate that something has been broken.

Having two competing configuration mechanisms instead of three does not 
constitute 'breakage', but iteration towards one single mechanism.

It may be that I have broken something. If this is the case, I would 
apologise and endevour to fix it immediately.

> One thing I insist on is that it be possible to run geronimo with no  
> clustering support whatsoever, including no clustering classes  
> anywhere in the geronimo system.  I believe this means that each  
> clustering system has to be installed as a configuration.  Doing this  
> right now as the first step will I think help focus the rest of the  
> componentization.
This involves splitting the Jetty and TC configs into local and 
clustered and associated refactoring. Ultimately this is where I would 
like to be aswell, but I think it unlikely to happen in time for 1.0.1.

All I am trying to do is to get a Geronimo/Jetty/Tomcat/WADI solution, 
that has as little impact as possible, in place before 1.0.1.

> I don't understand the requirements very well, I hope for some answers:
> - do we need to support running more than one clustering system with  
> a particular web container instance (e.g. JettyContainerImpl gbean  
> instance)?  I'm hoping "no"

If we pursue the direction that has been discussed, then per-app and 
per-container configs will be possible.

Per-container config will allow the container to specify a single 
default clustering solution, but apps would be free to override this 
with their own specific solution.

> IIUC we are installing clustering as a session manager.  Perhaps I  
> don't understand the code but it looks to me as if the jetty code at  
> least is creating a new instance for each web app.   I can't believe  
> this is an acceptable strategy for all clustering implementations.   
> For instance, I would think if you have a bunch of web apps doing  
> cross-context dispatch you would want them all to share a session  
> manager.  I think we want the possibility of installing a single  
> container wide session manager or per-app session managers.

I believe that I also mentioned this in one of the discussion threads., 
but this requirement did not make it onto my mental roadmap for 1.0.1.

> Is it really plausible to rely on the distributable tag in the spec  
> dd to turn on clustering? 

Presence of the <distributable/> tag in the web.xml indicates the apps 
requirement to the container to be clustered.

> I would think a further tag in our plan  should be needed.

If the app did not override (via some future extension) the container's 
choice of clustering solution, then the container's default solution 
would be implemented.

> Here's what I propose:
> We define a SessionManagerFactory interface, and for each clustering  
> technology provide an implementation as a gbean.    You can get a  
> local and a distributed session manager from this interface.  The  
> runtime configuration for the clustering includes this gbean.  Each  
> web app context gets a reference to this gbean and  gets the  
> appropriate session manager when it starts.  The web app context  
> knows if it is supposed to be local or distributed so it can ask for  
> the right session manager.
> We have a deploy time configuration for each clustering technology  
> also.  This at least supplies the gbean reference to the runtime  
> gbean, and can also install a runtime gbean in the configuration  
> under construction.  In this way the clustering technology can decide  
> on whether one session manager is shared, a factory that always  
> returns unconfigured new instances is needed, or if each web app  
> needs a specially configured session manager.
> If this isn't clear, I'll be happy to try to clarify.

No, it is quite clear - it is pretty close to a long-term suggestion 
which I made in conclusion to my 'geronimo-web.xml' thread:

"...Perhaps a SessionManagerFactoryGBean could be used on a per-server 
basis to create individual SessionManagers (for each app) that can then 
share further server-wide resources ?"

I was simply trying to come up with a short-term solution to tide us 
over 1.0.1 before we sat down and went for the whole enchillada.


> thanks
> david jencks
> On Jan 12, 2006, at 7:54 AM, Jeff Genender wrote:
>> I didn't finish #4..sorry...
>> 4) Your integration of setting the manager (no matter what) is a  direct
>> clash with the Tomcat clustering components (GBeans).  We need a more
>> unified approach to selecting a clustering component.
>> Jeff Genender wrote:
>>> Hi Jules.
>>> A few comments.  First, you made changes without discussing them  on 
>>> the
>>> dev lists.
>>> As per the discussions in the past, both Aaron and David Jencks,  as 
>>> well
>>> as I threw in our .02 on how to integrate the clustering.  I would
>>> appreciate you discuss code ideas and changes that have such a  drastic
>>> impact on the Geronimo code base.  Here are the issues with your  
>>> check in:
>>> 1) I explained before for Jetty, and obviously now I need to do it  for
>>> Tomcat, a -1 on Axion as a dependency.  There should not be any web
>>> application dependencies injected at the container level.  This means
>>> there is a severe architectural issue with WADI when we are injecting
>>> these dependencies into the container.
>>> 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the
>>> distributablesession manager in the TomcatContainer.  Hardcoding a
>>> pluggable session engine is very bad, and defeats the pluggability  
>>> of a
>>> configuration that we requested.
>>> 3) You placed in the code, and Aaron worked pretty hard to
>>> clean those up.
>>> 4) Your integration of setting the manager (no matter what) is a  
>>> direct
>>> clash with the
>>> Jules, I am giving a complete -1 of checkin of 368344.  These are all
>>> for technical reasons.  Please back out these changes, and bring this
>>> discussion to the Geronimo lists as this needs some significant
>>> discussion for implementation.  I would appreciate that you please
>>> involve the Apache way and open discussions on the lists before doing
>>> this sort of thing in the future.
>>> Again, I will CC the G lists to make this clear, that I would like  
>>> this
>>> change backed out.
>>> Jeff
>>> Jules Gosnell wrote:
>>>> Here is a list of outstanding issues associated with this work:
>>>> - ActiveMQ's shutdown hook seems to trigger when Geronimo is  
>>>> shutdown,
>>>> removing AMQ before WADI - WADI doesn't like this. I have added a
>>>> property to the script which suppresses this behaviour. I  
>>>> will
>>>> document it in the Getting Started doc.
>>>> - There 'may' be issues with nodes finding each other, when a  
>>>> Geronimo
>>>> node is introduced into a WADI cluster - investigating.
>>>> - Jeff - you should look over the changes and make sure that they  
>>>> do not
>>>> impact on any other TC fn-ality. They were done with Emacs, so the
>>>> formatting may be offensive. Please feel free to make them your  
>>>> own and
>>>> bring any issues back to the list. The WADIGBean, is no longer  
>>>> used, so
>>>> you may want to remove this from the repo.
>>>> - Jan and Jeff - since this config is now done on the container  
>>>> bean and
>>>> not in the geronimo-web.xml, you may no longer need to implement  your
>>>> own geronimo-web.xml schemas (I haven't looked very closely at  
>>>> TC). You
>>>> may want to consider this and perhaps lose them.
>>>> - In order to get the same webapp to work in all containers
>>>> (tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat),  I 
>>>> had
>>>> to move deps back to Geronimo container-level. These include Axion,
>>>> which I know will upset Jeff. As I have stated before, WADI's  
>>>> dependence
>>>> on Axion is easily removed. If Jeff or anyone wants to look at  
>>>> replacing
>>>> it with Derby, it is fine with me, as long as they do some  testing 
>>>> and
>>>> confirm that having created a session on a single node and  
>>>> restarted it,
>>>> the session survives (if the DB is still running). This needs to be
>>>> tested on all supported containers. Axion was used because it is an
>>>> in-VM DB (so imposes no further integration dependencies on the  
>>>> Getting
>>>> Started stuff and is useful for unit-testing) and was in use by  
>>>> Geronimo
>>>> at the time. So I suggest that any replacement needs to also be  
>>>> able to
>>>> run in-vm aswell. As we go further and move WADI's actual  
>>>> configuration
>>>> from the app to the container-level, these issues will disappear and
>>>> WADI will be able to be hooked to whatever persistance mechanism is
>>>> shipped in Geronimo by default.
>>>> - Jan & Jeff , you may want to consider pushing some of this session
>>>> manager selection code up into a shared GeronimoWebContainer  
>>>> abstraction
>>>> so that you don't both end up maintaining similar but diverging  
>>>> code...
>>>> - I may have overlooked a couple of issues. If I come across them, I
>>>> shall post them.
>>>> Further work on Geronimo integration :
>>>> - more testing
>>>> - make a new WADI release and update geronimo-trunk to use it
>>>> - look at applying diffs to a G1.0 tree and producing a binary  
>>>> patch for
>>>> 1.0 distros.
>>>> - update website and release it
>>>> Jules
>>>> Jules Gosnell wrote:
>>>>> Guys,
>>>>> Jan and I have just refactored the Geronimo Jetty and Tomcat
>>>>> integrations to take the same approach to the installation of a 3rd
>>>>> party session manager, to ease the integration of WADI. This is now
>>>>> checked in on Geronimo's trunk.
>>>>> Each top level web container GBean now supports a pair of  
>>>>> attributes -
>>>>> LocalSessionManager and DistributableSessionManager. These may  be 
>>>>> used
>>>>> to override the container's choice of SessionManager for webapps  
>>>>> with
>>>>> and without the <distributable/> tag present in the WEB-INF/ web.xml,
>>>>> respectively.
>>>>> The attributes expect to be given a classname, if required, this  
>>>>> class
>>>>> will be loaded and instantiated. The resulting instance will be  used
>>>>> as the session manager. If not provided, the container will use a
>>>>> sensible default. Currently Jetty and TC are set up to use their  own
>>>>> default session managers in the local case and the correct WADI
>>>>> session manager in the distributable case.
>>>>> This means that the same WADI-enabled webapp, with its plan held
>>>>> internally (WEB-INF/geronimo-web.xml) may now be hot-deployed on
>>>>> either a Jetty or a Tomcat based Geronimo, without changes :-)
>>>>> I will post specific WADI issues to the WADI dev lists
>>>>> (,
>>>>> This shouldn't be seen as a final position on the subject -  there is
>>>>> still much to talk about, but is a useful interim step, that  
>>>>> allows us
>>>>> to have something working whilst we figure out how to go forward.
>>>>> Enjoy,
>>>>> Jules

"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)
 * Open Source Training & Support.

View raw message