Re: Performance of tomcat 3.2.3

[Jeff Kilbride]

Also:

http://www.webperformanceinc.com/

Great program and very easy to set up fairly complex tests. I only wish it
was open source!  :(

(they do have a free trial period, though)

Thanks,
--jeff

- Original Message -
From: "Ryan Lubke" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 9:46 AM
Subject: Re: Performance of tomcat 3.2.3


> http://jakarta.apache.org/jmeter/index.html
>
> On Fri, 2001-11-16 at 12:16, Michael Jennings wrote:
> > Hi everyone,
> >
> > I'm working on a project for a client that involves a servlet engine
component. I suggested tomcat
> > since I am most familiar with it and it seems the most compliant servlet
engine around.
> > My client has mentioned concerns about tomcat's performance and now is
insisting on
> > using IBM websphere 4.0
> >
> > My suspicion is that tomcat's performance will be fine for this
application, but I would
> > like to have some hard numbers to back up my claim. Does anyone know of
any kind
> > of tool or code out there that can measure http and https performance?
> >
> > Thanks in advance.
> > -Mike Jennings
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] TC 3.2.3 Bug #1141

[Jeff Kilbride]

Hi Marc,

Sorry, it's #1114.

Thanks,
--jeff

- Original Message -
From: "Marc Saegesser" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, August 12, 2001 4:31 PM
Subject: RE: [PATCH] TC 3.2.3 Bug #1141


> I committed the patch.  Bugzilla 1141 isn't a Tomcat bug, could you please
> verify the bug number so I can mark is closed?
>
> Marc Saegesser
>
> > -Original Message-
> > From: Jeff Kilbride [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 09, 2001 4:13 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PATCH] TC 3.2.3 Bug #1141
> >
> >
> > I've wrapped the cookie creation in a try/catch to avoid having the
> > Exception kill the request. I also added some logging in the catch to
log
> > the original cookie header string. Maybe I'll be able to find out what's
> > going on...
> >
> > This is patched against the 3.2.3 final source.
> >
> > Thanks,
> > --jeff
> >
> >
> >
>

[PATCH] TC 3.2.3 Bug #1141

[Jeff Kilbride]

I've wrapped the cookie creation in a try/catch to avoid having the
Exception kill the request. I also added some logging in the catch to log
the original cookie header string. Maybe I'll be able to find out what's
going on...

This is patched against the 3.2.3 final source.

Thanks,
--jeff



--- RequestUtil.java.orig   Thu Aug  9 14:18:33 2001
+++ RequestUtil.javaThu Aug  9 14:31:31 2001
@@ -184,10 +184,23 @@
 
 String name = token.substring(0, i).trim();
 String value = token.substring(i+1, token.length()).trim();
-   // RFC 2109 and bug 
-   value=stripQuote( value );
-Cookie cookie = new Cookie(name, value);
-cookies.addElement(cookie);
+// RFC 2109 and bug 
+value=stripQuote( value );
+
+// Wrap the cookie creation in a try/catch to prevent bad
+// cookie names from killing the request -- Bug #1141
+try {
+Cookie cookie = new Cookie(name, value);
+cookies.addElement(cookie);
+}
+catch ( java.lang.IllegalArgumentException iae ) {
+
+// Log the original cookie header string, so we
+// can see what is causing this
+System.err.println(iae.getMessage() + "\n" +
+   "Cookie Header: " + cookieString);
+}
+
 } else {
 // we have a bad cookie just let it go
 }

Re: Binding to a single IP

[Jeff Kilbride]

I'm not sure about 3.3, but 3.2.x has an "inet" parameter for the
PoolTCPConnector class. This is from my server.xml:

--








--

Obviously, this is for my ajp13 connector, but I believe it would work the
same for the HttpConnectionHandler.

Hope this helps.

--jeff

- Original Message -
From: "Bojan Smojver" <[EMAIL PROTECTED]>
To: "Tomcat Dev List" <[EMAIL PROTECTED]>
Sent: Friday, August 03, 2001 6:04 PM
Subject: Binding to a single IP


> I've asked this question over on the Tomcat user list, but nobody
> replied...
>
> Can Tomcat (3.3) be bound to a single IP address (ie. just 127.0.0.1)?
>
> Bojan
>

Re: mod_jk.so-eapi vs mod_jk.so-noeapi

[Jeff Kilbride]

Sorry, I didn't notice the original message was cross-posted to the dev and
user lists. Didn't mean to post it here...

Thanks,
--jeff

- Original Message -----
From: "Jeff Kilbride" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 4:39 PM
Subject: Re: mod_jk.so-eapi vs mod_jk.so-noeapi


> Hi Vinay,
>
> EAPI means "extended API". You'll need to use mod_jk.so-eapi if you are
> using Apache with mod_ssl for SSL (https) support. If you are not using
> mod_ssl, you can use the mod_jk.so-noeapi.
>
> Thanks,
> --jeff
>
> - Original Message -
> From: "Vinay Menon" <[EMAIL PROTECTED]>
> To: "Tomcat Dev" <[EMAIL PROTECTED]>; "Tomcat User"
> <[EMAIL PROTECTED]>
> Sent: Monday, July 09, 2001 2:27 PM
> Subject: mod_jk.so-eapi vs mod_jk.so-noeapi
>
>
> > What exactly are these 2 so's? Why 2 of them and which one should one
use?
> >
> > Would appreciate if somebody could let me know!
> >
> > Thanks
> >
> > Vinay
> >
>

Re: mod_jk.so-eapi vs mod_jk.so-noeapi

[Jeff Kilbride]

Hi Vinay,

EAPI means "extended API". You'll need to use mod_jk.so-eapi if you are
using Apache with mod_ssl for SSL (https) support. If you are not using
mod_ssl, you can use the mod_jk.so-noeapi.

Thanks,
--jeff

- Original Message -
From: "Vinay Menon" <[EMAIL PROTECTED]>
To: "Tomcat Dev" <[EMAIL PROTECTED]>; "Tomcat User"
<[EMAIL PROTECTED]>
Sent: Monday, July 09, 2001 2:27 PM
Subject: mod_jk.so-eapi vs mod_jk.so-noeapi


> What exactly are these 2 so's? Why 2 of them and which one should one use?
>
> Would appreciate if somebody could let me know!
>
> Thanks
>
> Vinay
>

Re: FORM-based authentication idea

[Jeff Kilbride]

FWIW, I ran into this problem with users bookmarking the login page and
returning to it without trying to access a protected resource. In the
current implementation in 3.2.2, I don't think you can prevent that, can
you?

After being authenticated, the user was being dropped into the directory
that contained my login.jsp. I found the easiest solution was to have my
login.jsp in it's own directory with an index.jsp that simply redirects to
the appropriate page inside my protected resource. Took me about a minute to
implement and it works well.

Craig, from your previous posts I am under the impression that the current
implementation for form-based logins uses a sendRedirect() -- which is why
you can see and bookmark the URL for your login.jsp page (3.2.2). Is this
correct? Is that going to change to use RequestDispatcher.forward() in the
future? If so, that should solve the bookmarking problem.

Thanks,
--jeff

P.S. -- I always use server-relative links, but I'm a programmer! :o)  My
designers using Dreamweaver always send me files with relative links...

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 4:48 PM
Subject: Re: FORM-based authentication idea


> On Thu, 21 Jun 2001, Craig R. McClanahan wrote:
>
> > > If the login page would be displayed all the  or  in
the
> > > login page will be treated by the browser as relative to
> > > /mywebapp/private, while the login page can be somewhere else.
> > >
> >
> > The form login page should use server-relative URLs, or a  tag
> > in the  section.  That way, the initial display of the login page
> > will work correctly even on a container that does (what amounts to) a
> > RequestDispatcher.forward() to the login page.
>
> Should != must.
>
> AFAIK there is no restriction on what is allowed in a login page - except
> the use of special name for the action and variables.
>
> That mean a page using relative URLs is legal, and the container must deal
> with it. ( I don't know too many pages using the  tag anyway, and
> relative URLs are prefered in many cases - I would say they are far more
> frequent than server-relative URLs ).
>
>
> Costin
>

Re: [PATCH] TC 3.2.2 Timestamp format in Logger.java

[Jeff Kilbride]

Someone was kind enough to point out that I should be using the unified
format for diff, so here's the patch again in that format.

Thanks,
--jeff

- Original Message -
From: "Jeff Kilbride" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 31, 2001 7:29 PM
Subject: [PATCH] TC 3.2.2 Timestamp format in Logger.java


> Hi All,
>
> This is my first attempt at using diff and submitting a patch, so I chose
> something *extremely* simple.
>
> Logger.java in TC 3.2.2 has the timestamp format using a 12-hour clock
with
> no am/pm designation, so it's difficult to tell afternoon from early
morning
> times ( 03 could mean 3am or 3pm). This annoyed me enough when looking at
my
> log files to make me want to learn how to submit a patch!
>
> Please let me know if this is in the right format or if I'm missing
anything
> that should be included in future patch submissions.
>
> Thanks,
> --jeff
>
>


--- Logger.java.origThu Jul  6 17:20:17 2000
+++ Logger.java Thu May 31 21:15:38 2001
@@ -411,9 +411,9 @@
 protected boolean timestampRaw = false;
 
 /**
- * The timestamp format string, default is "-MM-dd hh:mm:ss"
+ * The timestamp format string, default is "-MM-dd HH:mm:ss"
  **/
-protected String timestampFormat = "-MM-dd hh:mm:ss";
+protected String timestampFormat = "-MM-dd HH:mm:ss";
 
 protected SimpleDateFormat timestampFormatter
= new SimpleDateFormat(timestampFormat);

[PATCH] TC 3.2.2 Timestamp format in Logger.java

[Jeff Kilbride]

Hi All,

This is my first attempt at using diff and submitting a patch, so I chose
something *extremely* simple.

Logger.java in TC 3.2.2 has the timestamp format using a 12-hour clock with
no am/pm designation, so it's difficult to tell afternoon from early morning
times ( 03 could mean 3am or 3pm). This annoyed me enough when looking at my
log files to make me want to learn how to submit a patch!

Please let me know if this is in the right format or if I'm missing anything
that should be included in future patch submissions.

Thanks,
--jeff



414c414
<  * The timestamp format string, default is "-MM-dd hh:mm:ss"
---
>  * The timestamp format string, default is "-MM-dd HH:mm:ss"
416c416
< protected String timestampFormat = "-MM-dd hh:mm:ss";
---
> protected String timestampFormat = "-MM-dd HH:mm:ss";

Logger.java -- TC 3.2.1/3.2.2b3

[Jeff Kilbride]

I noticed when looking through my log files that 
the default timestamp format for logging is based on a 12-hour clock, as opposed 
to a 24-hour clock. I would meekly suggest changing this by changing Line 416 of 
Logger.java in TC 3.2.1/3.2.2b3 from:
 
protected String timestampFormat = "-MM-dd 
hh:mm:ss"; 
 
to:
 
protected String timestampFormat = "-MM-dd 
HH:mm:ss";
 
I know it's configurable in the server.xml file, 
but I thought it would be nice to change the default. The other option would be 
to add the AM/PM designator to the current format:
 
protected String timestampFormat = "-MM-dd 
hh:mm:ss a";
 
Thanks,
--jeff