You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2005/11/23 15:44:59 UTC
Management API for Web Server Statistics
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
Re: Management API for Web Server Statistics
Posted by Joe Bohn <jo...@earthlink.net>.
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 <jo...@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
Re: Management API for Web Server Statistics
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <jo...@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
>