VOTE: Bugrat a viable alternative to Bugzilla?

[Nick Bauman <ni...@yahoo.com>]

Thanks, Dina;

Could we have a vote from the community on BugRat?
What do you all think?

I'm wrangling a chroot environment in conjunction with
thttpd on a server right now to help allieviate the
security and bandwidth problem(s) of Bugzilla
specifically for you reading this email. And I _just
_got perl and thttpd to work under the chroot and now,
even after all that, praise the skys, a servlet-based
bug reporting tool sure would be great.

I would prefer to see something that doesn't need a
crazy chroot environment, (as much fun as it has been
to set up) so my vote it +1 for bugrat.

It has one thing missing that bugzilla has: the
ability to attach a patch as a downloadable file,
which I think is kinda nice. But that's just me.

http://www.gjt.org/servlets/BugRatReport/ReportForm

--- Dima Nechitaylenko <ad...@wdcb.ru> wrote:
> Hello,
> 
> I was going to bring up the subject of bug tracking
> software once
> again from a new point of view. I've read a lively
> discussion of
> the topic of bugzilla security and in this respect I
> want to turn
> my question into a suggestion as well. 
> 
> See, I was installing a package called BugRat,
> http://www.gjt.org/pkg/bugrat/
> and had problems with org.gjt.mm.mysql.Driver class
> under tomcat.
> Now, I wanted to ask everybody if they had ever
> tried bugrat, but,
> I understand I first have to introduce this
> Java/MySQL bug tracking
> tool to those of you, who talk only about one
> cgd-based tool and
> another non-existent yet. Go check it out, I know it
> works fine
> with JServ, but I need to start it under tomcat and
> I want help in
> this. 
> 
> Thanks for your time.
> 
> take care,
> Dima
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tomcat-dev-help@jakarta.apache.org
> 


=====
# Nick Bauman
# Technical Programmer
# http://webhelp.com
# real software, real code, real time

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail � Free email you can access from anywhere!
http://mail.yahoo.com/

Catalina versus Tomcat II?

[Roy Wilson <de...@bellatlantic.net>]

Craig and Costin have both contributed documentation that I find very interesting and
helpful, even though I'm certain I don't fully appreciate either document. But that's
never stopped me before ... :-)

I suspect the answer to my questions below are already embedded in the documents that
Criag and Costin have created (or the multitude of additional documents have not yet
read/understood). It may also be that the questions I'm about to ask don't make sense
or that everybody else knows the answer already but me. But that's never stopped me
before ... :-)

Craig and Costin seem to appeal to very different sources of evidence. For Craig,
empty method call is a critical measure of performance (and dys-functionality? :-)),
while for Costin empty method call overhead is a non-issue. Craig's analysis is
convincing, but then so is Costin's. It looks to this outsider that both Craig and
Costin are informally applying Amdahl's law, but doing so in different ways and
coming up with very different design-related conclusions.

Once upon a time (in a faraway place, etc.) I worked on a project where a bunch of
extremely smart and skilled people used state o' the art tools to construct an MS/SO
Office-like software suite that required ten minutes to log on. Some people -
including me - think that it would be good to get performance considerations closer
to design (but that's tough to do, unless you want to spend lots of money on tools
that some people see as having questionable value at design time.  Their papers
suggest that Costin and Craig are eager to consider performance upfront rather than
after the fact.

As a naive lurker who has fiddled/diddled in performance design, measurement and
modeling, it seems to me that there may be a couple of elephants in the room that
have not yet been (or maybe don't need to be) addressed. I'm only doing a crude
sketch here:

1. How will performance be defined?

Average service time (S)? Server end-to-end? Tomcat/Catalina end-to-end? Per method?

Average hardware/software/data utilization (U)?

Average throughput (L)? Server/Tomcat/Catalina?

Average response time (R = S/(1-U))? Server end-to-end? Tomcat/Catalina end-to-end?

Average waiting time (W)? Server/Tomcat/Catalina?

Are/were there targets for these performance quantities? Costin mentioned getting
(average?) response time within 20% of that observed when static pages are involved.

Of course, all these quantities depend on how many customers (N) are using
Server/Tomcat/Catalina during a period of time T. The performance quantities can be
calculated from operational data. This brings me to the next question.

2. How will performance be measured?

There are always a variety of performance tools, some better or worse at each of the
above senses of performance. I have seen but not yet studied a web page on Java
performance.  There are also commercial tools available and usually some
developed/used by vendors (like Sun).  How did Costin generate his empirical data?
Can those empirical data be reported? Did/can Costin/Craig or someone else (like me?)
do an operational analysis?

3. What will be the workload against which performance will be assessed?

The answer to this is probably a lot like the answer(s) to the previous question.

Re: Catalina and Valve versus Interceptor

["Craig R. McClanahan" <Cr...@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)".
>
> 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.?
>

It's based on an analysis of the actual implementation of the design
patterns for RequestInterceptor and Valve.  The key differences related
to performance are the number of method calls that are required to
implement a given piece of filtering functionality, and the mechanisms
required to maintain per-request state information when required by a
particular requirement.

Besides the performance issue, there are important differences in the
range of functionality that can be implemented using the two approaches,
and some problems in the current implementation of RequestInterceptors
in Tomcat 3.2.  These latter problems have nothing to do with the design
issues involved, but significantly affect the functionality of request
interceptors in the current version of Tomcat -- they can be fixed by
improving the implementation of request interception processing in the
core Tomcat classes.

The actual discussion is quite long, so I will be posting it as a
document in the CVS source tree.  As soon as that's done (later today),
I will post a URL that uses CVSWeb to retrieve it directly.

>
> (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).
>

There are a couple of comments about the origin of the Valves concept in
the discussion to be posted (see above).  You will see a very similar
concept implemented in Nic Ferrier's GNU-Paperclips servlet container, 
and a more limited form of Valves in any servlet container that
implements "servlet chaining" the way that JWS did it.

>From the perspective of an individual valve, the pipeline is in fact the
correct analogy.  There will be examples of some simple filter
implementations (using both RequestInterceptor and Valve) in the
document -- plus, you should look at the Catalina source code for the
cases where Valves have already been included for common functionality. 
In particular, check out:

    org.apache.tomcat.Valve -- the API contract all Valves must obey

    org.apache.tomcat.Pipeline -- the API contract implemented by
	Containers that want to have a pipeline of associated
	valves.  This is implemented by the default base container
	for classes, so it's there for any Container
        implementation to use.

    org.apache.tomcat.security -- This package contains Valve
	implementations that perform the required authentication
	processing for the BASIC, DIGEST, and FORM authentication
	methods defined by the servlet 2.2 specification.
        The default code that configures a web application picks
	the correct authenticator for apps that want one
	(including none at all for apps that do not need this
        feature, so there is zero runtime overhead unless you ask
	for it).

    org.apache.tomcat.valves -- A convenient base class for your
	own valves (ValveBase), plus some useful simple valves:
        * AccessLogValve -- produces web server style access logs
	  so that you can run your hit count analysis programs
	  even when using Catalina stand alone.  (You would not
	  use this when running behind Apache, because
	  Apache will create the log file for you).
        * RemoteAddrValve -- performs access restrictions based
	  on the IP address of the remote client.
        * RemoteHostValve -- performs access restrictions based
	  on the hostname of the remote client.


>
> (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)?
>

I don't know of any scenarios where the Valve pattern, or any other
design pattern, is planned to be implemented in hardware by itself.

My reference to embedded devices is that you might have a device that
needs to present a user interface for its administration and management
(example:  a network router).  In that case you might want to embed a
servlet container (and the corresponding application) in the control
software for that device.

>
> Roy Wilson
> designrw@bellatlantic.net
>

Craig McClanahan

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

Catalina and Valve versus Interceptor

[Roy Wilson <de...@bellatlantic.net>]

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

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.?

(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).

(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)?

Roy Wilson
designrw@bellatlantic.net

Re: Catalina Documentation

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Diether Samaey wrote:

> I'm looking for some more detailed (software developer) documentation
> on the Catalina architecture.  All I have right now is Craig's presentation
> for JavaOne and the documentation which comes with the source files.
>
> Any pointers to other documents would be greatly appreciated.  :)
>

In the directory "proposals/catalina/docs" there is a (somewhat dated)
"index.html" file that describes some of the original thinking behind
the
proposal, and forms the basis of what I presented along with the JavaOne
presentation.  In addition, the "proposals/catalina/docs/config"
directory
contains the beginnings of reference documentation about all of the
configuration opportunities you have in server.xml -- again it's not
complete,
but it's a substantial start.

That's about it at the moment.  But you may also find the Javadoc
comments for
the Catalina source code to be useful (use "./build.sh javadoc" from the
proposals/catalina directory).  There is quite a lot of discussion of
the
contracts that the various components must obey buried in the API docs.

>
> Thanks,
>
> Diether
>

Craig

Catalina Documentation

[Diether Samaey <di...@alcatel.be>]

I'm looking for some more detailed (software developer) documentation
on the Catalina architecture.  All I have right now is Craig's presentation
for JavaOne and the documentation which comes with the source files.

Any pointers to other documents would be greatly appreciated.  :)

Thanks,

Diether

Re: Bugrat a viable alternative to Bugzilla?

[Geoff Soutter <ge...@whitewolf.com.au>]

> Could we have a vote from the community on BugRat?
> What do you all think?

Nick, I've never used it, but I'd say if you're willing to set up a stopgap
on your own machine till the all-singing, all-dancing (;-) scarab arrives,
you can set up pretty much anything you want. We don't got an alternative at
the moment, so it'll probably be adopted anyway, assuming it's half decent
to use.

geoff

Re: VOTE: Bugrat a viable alternative to Bugzilla?

[Costin Manolache <cm...@yahoo.com>]

I don't understand what's the point of this vote -
if you want to volunteer and install bugrat on your own system,
and provide this service to the community - please
do it, right now we don't have any bug tracking system.

If someone else do the same for bugzila - well, then we'll
have to choose. I never used bugrat, but I would love to have
to choose.

If your vote is about installing something on jakarta.apache.org -
you should ask the server admin, not us. In general the security
policy of a site and the software that is installed is not subject to
vote.

Costin



Nick Bauman wrote:

> Thanks, Dina;
>
> Could we have a vote from the community on BugRat?
> What do you all think?
>
> I'm wrangling a chroot environment in conjunction with
> thttpd on a server right now to help allieviate the
> security and bandwidth problem(s) of Bugzilla
> specifically for you reading this email. And I _just
> _got perl and thttpd to work under the chroot and now,
> even after all that, praise the skys, a servlet-based
> bug reporting tool sure would be great.
>
> I would prefer to see something that doesn't need a
> crazy chroot environment, (as much fun as it has been
> to set up) so my vote it +1 for bugrat.
>
> It has one thing missing that bugzilla has: the
> ability to attach a patch as a downloadable file,
> which I think is kinda nice. But that's just me.
>
> http://www.gjt.org/servlets/BugRatReport/ReportForm
>
> --- Dima Nechitaylenko <ad...@wdcb.ru> wrote:
> > Hello,
> >
> > I was going to bring up the subject of bug tracking
> > software once
> > again from a new point of view. I've read a lively
> > discussion of
> > the topic of bugzilla security and in this respect I
> > want to turn
> > my question into a suggestion as well.
> >
> > See, I was installing a package called BugRat,
> > http://www.gjt.org/pkg/bugrat/
> > and had problems with org.gjt.mm.mysql.Driver class
> > under tomcat.
> > Now, I wanted to ask everybody if they had ever
> > tried bugrat, but,
> > I understand I first have to introduce this
> > Java/MySQL bug tracking
> > tool to those of you, who talk only about one
> > cgd-based tool and
> > another non-existent yet. Go check it out, I know it
> > works fine
> > with JServ, but I need to start it under tomcat and
> > I want help in
> > this.
> >
> > Thanks for your time.
> >
> > take care,
> > Dima
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tomcat-dev-help@jakarta.apache.org
> >
>
> =====
> # Nick Bauman
> # Technical Programmer
> # http://webhelp.com
> # real software, real code, real time
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail – Free email you can access from anywhere!
> http://mail.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: VOTE: Bugrat a viable alternative to Bugzilla?

[Jon Stevens <jo...@latchkey.com>]

on 7/19/2000 9:35 PM, "Nick Bauman" <ni...@yahoo.com> wrote:

> Could we have a vote from the community on BugRat?
> What do you all think?

-1 for previous reasons.

-jon