Re: Catalina and Valve versus Interceptor

[Costin Manolache <co...@eng.sun.com>]

Roy Wilson wrote:

> In an earlier email, Criag McClanahan noted that the Valve mechanism "has lower
> runtime overhead than the current Tomcat approach (RequestInterceptors)".

And in many emails I noted the reverse :-)

> I've seen Craig's JavaOne slide presentation and dug up a reference to the Valve
> design pattern in an RM-ODP document (forgot what acronym stands for), but
> nothing I could get a handle on (but that's just me :-)). Two questions:
>
> (1) Who collected the overhead data, where, (more-or-less) how, etc.?

I did a number of experiments ( using Catalina and tomcat ), but Catalina
is not ready ( and tomcat doesn't have yet any real optimization that takes
advantage of the Interceptor ), so my data may be wrong.

My claim that Valves are slower is based on the way pipes operates,
on the fact that they tend to create more objects and have a longer
execution path, and the fact that Interceptors are easier to
optimize ( because the various chains are smaller and typed, instead
of a generic invoke() ). Another argument was based on the
2 parsing alghoritms ( in valve the parsing is done step by step,
while Interceptors the whole parsing can be done at once, using
trees or something else. Of course, Craig added a hack where
parsing is not done using the Valve mechanism - or that's what
it looks like  ).

As far as I know there has been no discussion about this except Craig's
assertions - there has been a lot of talk about how valves are simpler.
( and I agree they look simpler ).

> (2) What source provides (IYHO) the most direct and detailed description of the
> valve pattern? I wonder if I'm not making this more difficult than it is: the
> JavaOne slide suggests a pipeline (of sorts).

I can answer for Interceptors - you can look at Chain of Responsability
and Strategy.

Valve seems to be a pipeline, but I couldn't find any pattern ( at least
not in the Gamma,etc book ). Of course, Craig may give you more details.


> (3) The debate between Valve versus Interceptor could be (as someone else noted,
> partially) framed in terms of performance. Of course, the throughput and
> response of the pipeline critically depends on the request mix (Hennessy,
> Gibson, etc.) as well as the characteristics of the implementing  hardware. The
> idea that the Valve is going to be realized in hard/firmware (if I read the
> JavaOne slides correctly) suggests some studies have already been done. If so,
> can they be looked at (assuming sanitizing is needed)?

All my experiments ( and my maybe flawed common sense ) suggest the reverse.
The Interceptor model is used ( with a different interface, of course) in IIS,
NES, Apache, and it seems they are reasonably fast servers. Jigsaw is not
always a very fast server.

I don't know about Valves in hard/firmware , but
Interceptors map very well to Apache hooks, IIS filters and NES SAFs
( after all that was the model I had in mind when I started it),
and I do plan to add wrappers and use the native ones ( and of course,
if someone will write a hard/firmware accelerator I hope it will
do it  first for Apache or NES, so probably tomcat will be the first
to benefit. :-)

Most of this will be resolved soon - when Craig feels Catalina is
complete. Probably tomcat will have some of the new code
in place by then and a simple comparison will be enough (
I'll add collection-based alternative interceptors for JDK1.2,
so the current code will remain 1.1 compatible but you will
be able to confiugure the faster ones).


Costin