geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Date Mon, 16 Jan 2006 23:18:02 GMT
Alan D. Cabrera wrote:

> I am of the strong opinion of releasing new features in a patch 
> release is a bad idea.  This should go in 1.1.0.  I think that we 
> should feature freeze 1.1.0 at the end of this month.
>
I agree with you, Alan, but the change did not add a new feature. WADI 
was integrated in 1.0, but there were issues with this integration that 
were not fixed. My change resolved these issues and at the same time 
unified the way that Jetty and Tomcat integrated with WADI.


Jules

>
> Regards,
> Alan
>
> Jules Gosnell wrote, On 1/16/2006 3:01 AM:
>
>> Here is my penniesworth :
>>
>> Users want clustering - I get mails everyday
>> Users do not expect that a 1.0 release will contain a complete 
>> clustering solution - they have realistic expectations.
>>
>> We have a chance with the 1.0, now 1.0.1 release, to mark certain 
>> areas as 'technology preview' and use these to demonstrate emerging 
>> Geronimo technologies to our user-base. This is one of the ways that 
>> Open Source projects traditionally generate interest and reach out to 
>> new potential developers. All aspects of clustering in Geronimo are 
>> going to require considerable work, and this is our chance to show 
>> our users that we are involved in at least some of these areas and 
>> invite them to contribute.
>>
>> I crafted my last change to make as few alterations to 1.0 as 
>> possible. It was called 'unacceptable', as far as I can tell, because 
>> it did not go far enough. Now we are saying that we only want minimal 
>> change between 1.0 and 1.0.1.... - so what is it to be ?
>>
>> A clearly defined subset of WADI fnality will 'work' by the time 
>> 1.0.1 is released. If we work towards the necessary integration now, 
>> then we will have a while to discuss it and get it in, if we don't, 
>> then it will again be termed too precipitous, we will miss 1.0.1 and 
>> the current fragmented approach to web clustering will persist in 
>> Geronimo, impacting on a growing number of users.
>>
>>
>>
>> Jules
>>
>>
>> Jan Bartel wrote:
>>
>>> David,
>>>
>>> To paraphrase what you said (if I understand correctly), the choices 
>>> are to either back clustering out of geronimo for the 1.0.1 release 
>>> and work on it for a future release, or to make minimal changes to 
>>> it to make it work
>>> in geronimo as is.
>>>
>>> I think it's unlikely that there will be a significant rush to 
>>> production with a 1.0 release of geronimo, so there is probably a 
>>> bit of latitude for less-than-optimal functioning in terms of 2nd 
>>> order functionality such as clustering if it were to be left in. It 
>>> would be good to get Jules' input on the state of WADI on this point.
>>>
>>> However, if we leave clustering in the way it is implemented at the 
>>> moment, then the disadvantages are:
>>> 1. clustering is enabled differently for tomcat and jetty and a basic
>>>   tenet of geronimo is to make the webcontainers interchangeable
>>> 2. clustering is enabled in the webapp descriptors instead of the 
>>> container
>>> 3. users that use the 1.0.1 clustering will have to change each webapp
>>>   to use it on future releases.
>>> If we roll forward again to the most recent clustering changes:
>>> 1. clustering interface is uniform for both tomcat and jetty
>>> 2. clustering is enabled in the container 3. no geronimo webapp 
>>> descriptor changes necessary
>>>
>>> Of course, the most recent changes are not the final clustering
>>> solution, so there would be changes to the container plans
>>> in the future (eg in 1.1). But changes to the plans could probably 
>>> be expected for any geronimo services between releases, no?
>>>
>>> I don't like the option of leaving the clustering with per-webapp
>>> geronimo descriptor configuration because it's just simply the
>>> wrong way to do it and will be a pain in the neck for users when
>>> we change to a better way in future releases. I think it would be 
>>> better to take clustering out than to release 1.0.1 with it like it is.
>>>
>>> So, the two options I see for 1.0.1 are:
>>>
>>> 1. take the clustering out and release in 1.1 after more discussion
>>> 2. leave clustering in, roll forward again and fix any issues
>>>
>>> I really don't have a preference either way - I think both are 
>>> meritworthy.
>>>
>>> regards
>>> Jan
>>>
>>>
>>>
>>>
>>>
>>>> I think that it would be better to work on clustering in head and 
>>>> not  try to hurry to get something that we know will change and has 
>>>> not  been well tested into 1.0.1.  I have no experience with 
>>>> actual  clustering.  Will people who want to use it expect 
>>>> something well  tested and stable?  Will they be willing to work 
>>>> off snapshot builds  to pick up the latest fixes?  What would the 
>>>> reaction be to something  that only sort of works in an official 
>>>> release?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>> On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote:
>>>>
>>>>> OK, Folks - here is how I see it -
>>>>>
>>>>> Everyone knows that they are right and the other guy is wrong.
>>>>>
>>>>> Result - DEADLOCK - everyone loses.
>>>>>
>>>>> Solution - release locks, back off, coordinate, retry.
>>>>>
>>>>> Releasing locks involves us all making concessions :
>>>>>
>>>>> I suggest -
>>>>>
>>>>> Jan, Greg and I conceded that Jeff could have been more involved 
>>>>> in  discussion before this change went in.
>>>>> Jeff concedes that Jan, Greg and I should have been involved in  
>>>>> discussion before he backed the change out.
>>>>> We all agree to overlook all current technical differences.
>>>>> We all agree to put aside whatever bad feelings may have arisen  
>>>>> from this incident.
>>>>>
>>>>> OK - locks released, backing-off complete.
>>>>>
>>>>> Now, coordination :
>>>>>
>>>>> WADI side :
>>>>>
>>>>> I will downgrade the log.info to a log.debug
>>>>> I will remove the axion dependency.
>>>>> I will resubmit the change as a patch to Jan and Jeff.
>>>>>
>>>>> Jetty/Tomcat side :
>>>>> Jan and Jeff will take this patch, and all relevant input.
>>>>> If they feel that they need further discussion, they will have it.
>>>>> They will implement a simple, unified solution to the issue for 
>>>>> all  existing cases and get it in to Geronimo 1.0.1
>>>>>
>>>>>
>>>>> I simply want a speedy, painless resolution so we can continue  
>>>>> forward.
>>>>>
>>>>> If everyone else is happy with these terms, then here is my '+1'
>>>>>
>>>>>
>>>>> Jules
>>>>>
>>>>>
>>>>> 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 log.info() 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 node.sh 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
>>>>>>>> (wadi-dev-d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b@public.gmane.org,

>>>>>>>> dev-VfzB7HFVXnJICAUklc1DCNi2O/JbrIOy@public.gmane.org).
>>>>>>>>
>>>>>>>> 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)
>>>>> *
>>>>> *    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.
 **********************************/


Mime
View raw message