Now that we have Lifecycle Listeners...the next step

[Jeff Genender <jg...@apache.org>]

Now that we have Lifecycle Listeners, I want to start a little
discussion around some of the Tomcat listeners that come standard
installed in their container and whether we include them or not in the
default plan.

Currently Tomcat has the following listeners attached to their
standalone container:

(Full package names included here for folks who want to look at the
Tomcat source)
org.apache.catalina.core.AprLifecycleListener
org.apache.catalina.mbeans.ServerLifecycleListener
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
org.apache.catalina.storeconfig.StoreConfigLifecycleListener

AprLifecycleListener - Init and and destroy APR.

ServerLifecycleListener - Instantiates the set of MBeans associated with
the components of a running instance of Catalina.

GlobalResourcesLifecycleListener - Instantiates the set of MBeans
associated with global JNDI resources that are subject to management.

StoreConfigLifecycleListener - Load and Register StoreConfig MBean
Catalina:type=StoreConfig,resource="url"


I think we can rewrite our own ServerLifecycleListener to have Tomcat
use our mbean server instead of them creating their own.  That would
allow their objects show up in our server, so I think we should add
something like that class.

The GlobalResourcesLifecycleListener and StoreConfigLifecycleListener I
am not sure if we need, but if we were to use them we may want our own
impls to it follows our Object naming scheme.

But most importantly I want to talk about the AprLifecycleListener.  I
really think we should add this as a default listener in the plan
because this will allow people to use a netive APR connector and
*really* get some incredible performance out of Geronimo.  For those not
familiar with APR, its the Apache Portable Runtime project.

http://apr.apache.org/

It basically will test if you have compiled natice binaries for your
platform, and if it find them, it will use those instead of hte pure
java implementation.  The listener is really for initialization and
destruction on start/stop of the server, so there is no overhead.  This
can really give Geronimo a performance boost, especially for those who
use it in a high load site.

Thoughts and opinions on me enabling that listener?  Also thoughts on
some of the other listeners would be good as well.

Thanks,


Jeff

Re: Now that we have Lifecycle Listeners...the next step

[Jeff Genender <jg...@apache.org>]

Kevan Miller wrote:
> 
> On Jun 28, 2007, at 5:10 PM, Jeff Genender wrote:
> 
>> <snip>
>> But most importantly I want to talk about the AprLifecycleListener.  I
>> really think we should add this as a default listener in the plan
>> because this will allow people to use a netive APR connector and
>> *really* get some incredible performance out of Geronimo.  For those not
>> familiar with APR, its the Apache Portable Runtime project.
>>
>> http://apr.apache.org/
>>
>> It basically will test if you have compiled natice binaries for your
>> platform, and if it find them, it will use those instead of hte pure
>> java implementation.  The listener is really for initialization and
>> destruction on start/stop of the server, so there is no overhead.  This
>> can really give Geronimo a performance boost, especially for those who
>> use it in a high load site.
>>
>> Thoughts and opinions on me enabling that listener?  Also thoughts on
>> some of the other listeners would be good as well.
> 
> Nice. I like the idea. I see no reason not to enable this feature in
> Geronimo and good reasons to include it!

Great! I'll do it.

> 
> So, would you propose including tomcat-native.tar.gz in our assembly? A
> little doc on building native libs and how to enable APR (if user desires).

I dont know about including the drivers (except for Windows) since the
Unix libs would clash.  But yes, I think we should have a wiki entry
similar to Tomcat's found here:

http://tomcat.apache.org/tomcat-6.0-doc/apr.html

We could also pre-build a few of the more popular ones so people could
just download them (ie. Windows, Linux 32 bit, Linux 64 bit, MacOSX,
Solaris).

> 
> IIUC, everything runs fine out-of-the-box (we create APR connectors, but
> they can't load native libs and run exactly as the current connectors
> run today). If a user wants to enable APR, it requires something like:
> 
> tar zvf tomcat-native.tar.gz
> cd tomcat-native
> ant
> start geronimo

Yup...exactly.  I'll enable it in the plan ;-)

Jeff


> 
> --kevan

Re: Now that we have Lifecycle Listeners...the next step

[Kevan Miller <ke...@gmail.com>]

On Jun 28, 2007, at 5:10 PM, Jeff Genender wrote:

> <snip>
> But most importantly I want to talk about the AprLifecycleListener.  I
> really think we should add this as a default listener in the plan
> because this will allow people to use a netive APR connector and
> *really* get some incredible performance out of Geronimo.  For  
> those not
> familiar with APR, its the Apache Portable Runtime project.
>
> http://apr.apache.org/
>
> It basically will test if you have compiled natice binaries for your
> platform, and if it find them, it will use those instead of hte pure
> java implementation.  The listener is really for initialization and
> destruction on start/stop of the server, so there is no overhead.   
> This
> can really give Geronimo a performance boost, especially for those who
> use it in a high load site.
>
> Thoughts and opinions on me enabling that listener?  Also thoughts on
> some of the other listeners would be good as well.

Nice. I like the idea. I see no reason not to enable this feature in  
Geronimo and good reasons to include it!

So, would you propose including tomcat-native.tar.gz in our assembly?  
A little doc on building native libs and how to enable APR (if user  
desires).

IIUC, everything runs fine out-of-the-box (we create APR connectors,  
but they can't load native libs and run exactly as the current  
connectors run today). If a user wants to enable APR, it requires  
something like:

tar zvf tomcat-native.tar.gz
cd tomcat-native
ant
start geronimo

--kevan

Re: Now that we have Lifecycle Listeners...the next step

[Jeff Genender <jg...@apache.org>]

Vamsavardhana Reddy wrote:
> IIUC, org.apache.tomcat.util.modeler.Registry.getMBeanServer() is the
> method that hooks up the MBeanServer with which tomcat registers its
> MBeans.  Also, tomcat is not creating an MBean server of its own to
> register its MBeans with.  It is using the first one in the results from
> MBeanServerFactory.findMBeanServer(null) which returns all the
> registered MBeanServers.  If there are no MBeanServers, then it creates
> one.  Geronimo was doing the same (though not intentional??) until
> GERONIMO-3268.  I have gone through the ServerLifecycleListener class. 
> I could not figure how to make tomcat register its MBeans with our
> MBeanServer without modifying org.apache.tomcat.util.modeler.Registry. 
> Anything you are seeing which I am failing to see.

It appears the MBeans are registered in the listener with the
MBeanFactor (AFAICT).  I assume (yes just assuming by perusing the code)
that we can swap out calls in here to register mbeans with our server.
In otherwords, we could use our own MBeanFactory.

In any case if its not doable then we go down the patch route which is fine.

Jeff

Re: Now that we have Lifecycle Listeners...the next step

[Vamsavardhana Reddy <c1...@gmail.com>]

On 6/29/07, Jeff Genender <jg...@apache.org> wrote:
>
> Now that we have Lifecycle Listeners, I want to start a little
> discussion around some of the Tomcat listeners that come standard
> installed in their container and whether we include them or not in the
> default plan.
>
> Currently Tomcat has the following listeners attached to their
> standalone container:
>
> (Full package names included here for folks who want to look at the
> Tomcat source)
> org.apache.catalina.core.AprLifecycleListener
> org.apache.catalina.mbeans.ServerLifecycleListener
> org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
> org.apache.catalina.storeconfig.StoreConfigLifecycleListener
>
> AprLifecycleListener - Init and and destroy APR.
>
> ServerLifecycleListener - Instantiates the set of MBeans associated with
> the components of a running instance of Catalina.
>
> GlobalResourcesLifecycleListener - Instantiates the set of MBeans
> associated with global JNDI resources that are subject to management.
>
> StoreConfigLifecycleListener - Load and Register StoreConfig MBean
> Catalina:type=StoreConfig,resource="url"
>
>
> I think we can rewrite our own ServerLifecycleListener to have Tomcat
> use our mbean server instead of them creating their own.  That would
> allow their objects show up in our server, so I think we should add
> something like that class.


IIUC, org.apache.tomcat.util.modeler.Registry.getMBeanServer() is the method
that hooks up the MBeanServer with which tomcat registers its MBeans.  Also,
tomcat is not creating an MBean server of its own to register its MBeans
with.  It is using the first one in the results from
MBeanServerFactory.findMBeanServer(null) which returns all the registered
MBeanServers.  If there are no MBeanServers, then it creates one.  Geronimo
was doing the same (though not intentional??) until GERONIMO-3268.  I have
gone through the ServerLifecycleListener class.  I could not figure how to
make tomcat register its MBeans with our MBeanServer without modifying
org.apache.tomcat.util.modeler.Registry.  Anything you are seeing which I am
failing to see.


The GlobalResourcesLifecycleListener and StoreConfigLifecycleListener I
> am not sure if we need, but if we were to use them we may want our own
> impls to it follows our Object naming scheme.
>
> But most importantly I want to talk about the AprLifecycleListener.  I
> really think we should add this as a default listener in the plan
> because this will allow people to use a netive APR connector and
> *really* get some incredible performance out of Geronimo.  For those not
> familiar with APR, its the Apache Portable Runtime project.
>
> http://apr.apache.org/
>
> It basically will test if you have compiled natice binaries for your
> platform, and if it find them, it will use those instead of hte pure
> java implementation.  The listener is really for initialization and
> destruction on start/stop of the server, so there is no overhead.  This
> can really give Geronimo a performance boost, especially for those who
> use it in a high load site.
>
> Thoughts and opinions on me enabling that listener?  Also thoughts on
> some of the other listeners would be good as well.
>
> Thanks,
>
>
> Jeff
>