geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Management API for Web Server Statistics
Date Wed, 23 Nov 2005 15:52:14 GMT
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
>

Mime
View raw message