Ah, there it is...thanks! Mark, any idea why sometimes the GlobalRequestProcessor appears with the ObjectName:
Catalina:name="http-nio-80",type=GlobalRequestProcessor ...and other times it shows up as: Catalina:type=GlobalRequestProcessor,name="http-nio-80" ? Thanks, Dan On Wed, May 18, 2011 at 8:34 AM, Mark Thomas <ma...@apache.org> wrote: > On 18/05/2011 13:21, Dan Checkoway wrote: > > Gotcha...yeah, it would be trivial to slap an AtomicLong counter in a > > filter, but I'd hate to double the synchronization hit if tomcat already > has > > this counter available centrally. > > > > I'd like to hear an authoritative answer from the tomcat devs, if > possible, > > as to whether tomcat is already doing this centrally, and maybe just not > > exposing it? > > GlobalRequestProcessor (one per connector) is the best you'll get. > > Mark > > > > > Dan > > > > On Wed, May 18, 2011 at 7:45 AM, Jess Holle <je...@ptc.com> wrote: > > > >> I've done a servlet request filter for this and many other such things. > >> > >> I've always been a bit surprised by how little of this data Tomcat > collects > >> -- but that's fine as one can do a servlet request filter that will work > in > >> any servlet engine and collect everything you want. > >> > >> That said, collecting some of this information becomes a lot more > >> challenging with asynchronous requests, which is something I've not yet > >> tackled. For instance, it's easy to track the CPU usage for each > >> synchronous request (obviously from the servlet filter on down in the > call > >> stack, not counting the Tomcat calls before/after this), but not so easy > for > >> an asynchronous request... > >> > >> -- > >> Jess Holle > >> > >> > >> On 5/18/2011 6:31 AM, Dan Checkoway wrote: > >> > >>> I've messed around a bit, and I figured out a more reliable way to do > >>> it...but it's pretty nasty. Basically I'm iterating and grabbing the > >>> "requestCount" attribute from all of the RequestProcessor mbeans, and > just > >>> tallying them up. > >>> > >>> Like I said, it's nasty, since you need to know the max possible # of > >>> RequestProcessor beans, there are "gaps" in the sequence, etc. I'm > hoping > >>> there's an easier way to get just a single JMX-exposed attribute > >>> representing total requestCount. > >>> > >>> Possible? Wish list item...open a bugzilla ticket? > Bueller...Bueller...? > >>> :-) > >>> > >>> Dan > >>> > >>> On Tue, May 17, 2011 at 4:22 AM, Dan Checkoway<dchecko...@gmail.com> > >>> wrote: > >>> > >>> I'm looking for advice on the most reliable& efficient way to track > >>>> tomcat > >>>> throughput...preferably via JMX. I've written a simple app that uses > JMX > >>>> to > >>>> grab the "completedTaskCount" attribute on the Executor. My > assumption > >>>> was > >>>> that the Executor's completedTaskCount would be a fairly accurate way > to > >>>> watch, in real-time, the number of HTTP requests served...and a heck > of a > >>>> lot simpler than just counting access log lines. Basically the app > grabs > >>>> the completedTaskCount every 10 seconds and does a simple "how many > more > >>>> since the last time I checked" rate calculation. > >>>> > >>>> But what I think I'm seeing is that the Executor's completedTaskCount > >>>> grows > >>>> at a rate higher than the actual number of HTTP requests being served. > >>>> So > >>>> I'm wondering...is a shared Executor being used for purposes other > than > >>>> just > >>>> serving requests, and if so, what other types of tasks are being > >>>> executed? > >>>> > >>>> Is there any other attribute exposed by JMX that might be a more > reliable > >>>> way of counting actual HTTP requests served? Is there a simpler way > of > >>>> accomplishing the same goal that doesn't involve access log analysis? > >>>> > >>>> Thanks, > >>>> Dan > >>>> > >>>> > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
