You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jason Brittain <ja...@olliance.com> on 2000/11/30 03:48:33 UTC

New Valve Tester and NullValve

In the process of optimizing AccessLogValve, I came to the conclusion that
I needed a tester that would allow me to benchmark (and otherwise test) the
valve without needing to run all of Catalina -- I needed to isolate just the
valve so that I could get clean benchmark times.  So, I thought about 
writing
just a class that would let me instantiate the valve, and use it.  But, 
after
some looking at the code, I realized some things:

1) That it may not be easy to make the valve act the same as it would act
in a regular Catalina Container without making something that acts much
like a Container anyway.

2) Even if I could make something that acts like a Container, it
wouldn't really be a Container, so my custom class would only be
"faking it".
3) Maintaining a fake container to continue to be like the Catalina
Containers wouldn't be easy, and it would certainly be pointless.
4) Making a new class that really *was* a Container didn't look
that tough.
5) If I needed one of these, certainly someone else must have also
wanted one.  :)

So, I set out to write a generic Valve tester.

I wrote it, got it running, and used it for optimizing the
AccessLogValve.  Here's what I wrote:

org.apache.catalina.valves.ValveTesterBase.java
  This is the base abstract class that is a Container that uses the
  Valve you wish to test.
org.apache.catalina.valves.NullValve.java
  I needed this valve to be the basic functionality of the
  ValveTesterBase Container subclasses.  It does absolutely nothing
  other than return control to the caller.  This is good because it
  takes up basically no cpu time, and completes the Container's
  request pipeline.

Then, I wrote one subclass of ValveTesterBase:

org.apache.catalina.connector.http.AccessLogValveTester.java
  This class tests the AccessLogValve in one particular way, and
  has control over the environment in which the AccessLogValve
  operates.  I had to place this class in the http connector
  package only because the HttpRequestImpl and HttpResponseImpl
  classes are not declared public!  Should they be?

With the first two classes, anyone should be able to easily make
a valve tester that tests a valve in exactly the way they want to
test it.  The ValveTesterBase class is intentionally simple, and
small.  The AccessLogValveTester is a good example of a subclass
that uses it.

One idea I had about how ValveTesterBase could be improved is
by writing and integrating a request traffic generator of some
kind (maybe also abstract?) so that the request traffic can be
more like the characteristics of real web traffic, and thus be
a more real-world test of the valves.  I have not begun coding
this yet.  It will need to be multithreaded, though.

Also, in which package should this tester code reside, really?
I'm aprehensive about mixing the tester code in with the regular
Catalina code..

All feedback about this code is welcome!

Cheers.

-- 
Jason Brittain
Software Engineer, Olliance Inc.        http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org



Re: New Valve Tester and NullValve

Posted by Remy Maucherat <re...@apache.org>.
> Remy Maucherat wrote:
>
> > > Also, in which package should this tester code reside, really?
> >
> > org.apache.catalina.valves.tester ?
>
> Well, if the hi-tech stocks continue to dive, I guess we can all go get
jobs as
> plumbers, testing valves :-)

Oh, ok, it all makes sense now. You were planning your reconversion when you
designed Catalina ;)

> > Doing that will make it end up in the Catalina JAR, which is not a big
> > problem IMO, but perhaps it could be packaged separately. We could add a
> > src/test directory and put it in there.
> >
> > > I'm aprehensive about mixing the tester code in with the regular
> > > Catalina code..
> >
> > Well, as long as it builds and has no strange dependencies ...
>
> How about if we do this?  One thing that didn't get ported over to
Catalina yet
> is the test webapp that is in the 3.x workspace.  I'd like to bring that
over
> (although we might want to leverage the updated GTest task for Ant that is
in
> "jakarta-watchdog-4.0").  Would it make sense to add some stand-alone
testing
> infrastructure like Jason's test harness here as well?

Yes.

Actually, I'm planning on having a test suite for WebDAV (with an emphasis
on the DAV extensions - DAV ACL, Delata V, DASL) as part of Slide, based on
JUnit. Of course, there will be a server side part to this test suite
(packaged as a web app).
This test suite will be based of the new HTTP and WebDAV client library
which is part of Slide.

Is all that something similar to what you want ?

Remy


Re: New Valve Tester and NullValve

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Remy Maucherat wrote:

> > Also, in which package should this tester code reside, really?
>
> org.apache.catalina.valves.tester ?

Well, if the hi-tech stocks continue to dive, I guess we can all go get jobs as
plumbers, testing valves :-)

>
> Doing that will make it end up in the Catalina JAR, which is not a big
> problem IMO, but perhaps it could be packaged separately. We could add a
> src/test directory and put it in there.
>
> > I'm aprehensive about mixing the tester code in with the regular
> > Catalina code..
>
> Well, as long as it builds and has no strange dependencies ...
>

How about if we do this?  One thing that didn't get ported over to Catalina yet
is the test webapp that is in the 3.x workspace.  I'd like to bring that over
(although we might want to leverage the updated GTest task for Ant that is in
"jakarta-watchdog-4.0").  Would it make sense to add some stand-alone testing
infrastructure like Jason's test harness here as well?

>
> Remy

Craig



Re: New Valve Tester and NullValve

Posted by Remy Maucherat <re...@apache.org>.
> Also, in which package should this tester code reside, really?

org.apache.catalina.valves.tester ?
Doing that will make it end up in the Catalina JAR, which is not a big
problem IMO, but perhaps it could be packaged separately. We could add a
src/test directory and put it in there.

> I'm aprehensive about mixing the tester code in with the regular
> Catalina code..

Well, as long as it builds and has no strange dependencies ...

Remy