geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Management API for Web Server Statistics
Date Wed, 23 Nov 2005 16:48:22 GMT
Thanks Aaron.  That makes a lot more sense (and is a lot easier) than 
what I was trying to do with the GBean.

I'll complete the jetty impl first while I try to figure out how to 
gather/enable/disable/reset the tomcat stats.

Joe


Aaron Mulder wrote:
> The Stats shouldn't be a GBean, just a Serializable POJO holding the
> values.  And it wouldn't have the start/stop/reset stuff on it either,
> that would go on the parent as a custom API addition (though we could
> of course add it to the Geronimo WebContainer API or whatever). 
> Basically the owning GBean just hangs on to a POJO, and updates it and
> gives it out when neccessary.  Take another look at the Stats
> implementation in JVMImpl.  So I'd expect it to go something like
> this:
> 
> SomeWebContainer {
>     private SomeWebStats stats;
>     public Stats getStats() {
>         if(stats == null) stats = new SomeWebStats();
>         stats.setRequestCount(...);
>         stats.setErrorCount(...);
>         ...
>         return stats;
>     }
>     public void resetStatistics() {
>         stats = null;
>     }
> }
> 
> As far as Tomcat goes, can you look at the code for Tomcat's web
> console and work with Jeff Genender on duplicating that statistics
> gathering in Geronimo?  I seem to recall they create their components
> as MBeans and then query them through JMX to gather statistics, but
> I'm not really sure how that would work in the Geronimo environment.
> 
> Thanks,
>     Aaron
> 
> On 11/23/05, Joe Bohn <joe.bohn@earthlink.net> wrote:
> 
>>Aaron,
>>
>>After a long diversion on other items, I'm looking at the web server
>>statistics portlet and management api again.  I was starting to expand
>>upon the structure that you began so that the Web Servers will report
>>statistics in a similar fashion to J2EE-Objects as specified in JSR77.
>>But I'm not sure how we should implement some capabilities:
>>
>>What I've done thus far:
>>- I added a marker interface for JettyWebContainerStats extended from
>>WebContainerStats.  I updated JettyWebContainerStatsImpl to implement
>>both the JettyWebCOntainerStats interface and the GBean-LifeCycle.  I
>>updated the plan to add this gbean into the configuration. I also
>>updated the JettyContainerImpl to return true for isStatisticsProvider.
>>I haven't done the tomcat version yet, but it will follow the same
>>pattern.  I can begin collecting statistics from Jetty during the
>>initialization of the JettyWebContainerStatsImpl GBean and get the
>>necessary statistics information from the Jetty Server ... but of course
>>this has some performance implications (see below).
>>
>>Problems/Questions:
>>- First, am I staying true to your intended implementation?
>>- There doesn't seem to be an equivalent notion of enable/disable/reset
>>in the JSR77 Statistics Provider design.  I think I must be missing
>>something because this seems like an obvious requirement.  Without this
>>we would be collecting statistics for the web container continually and
>>thereby impacting performance.  I can also see why reset would be valuable.
>>- I still don't have an idea on how to collect similar stats data from
>>Tomcat without creating our own implementation to monitor and collect
>>the data.  Therefore, my first pass was going to be just getting Jetty
>>working with a message that this is not yet implemented for tomcat.  If
>>we get some more information on tomcat prior to V1 release we would add it.
>>
>>Given all that, the result to the end user would be pretty much
>>unchanged from what we currently have with the portlet that is
>>hard-wired for jetty only.  The one big difference (aside from the
>>structural improvements) would be that the enable/disable/reset would be
>>removed and we may be hitting performance problems if we do not extend
>>the JSR77 design (of course this is moot if I'm just missing it).
>>
>>So, as we approach V1, do you think we should spend time on this now or
>>should I focus on something else?
>>
>>Thanks,
>>Joe
>>
>>
>>--
>>Joe Bohn
>>joe.bohn@earthlink.net
>>
>>"He is no fool who gives what he cannot keep, to gain what he cannot
>>lose."   -- Jim Elliot
>>
> 
> 
> 

-- 
Joe Bohn
joe.bohn@earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message