Re: Performance of tomcat 3.2.3
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] TC 3.2.3 Bug #1141
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
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
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: -- Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp13ConnectionHandler/ Parameter name=inet value=localhost/ Parameter name=port value=8009/ Parameter name=max_threads value=50/ Parameter name=max_spare_threads value=25/ Parameter name=min_spare_threads value=10/ /Connector -- 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
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
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: FORM-based authentication idea
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 a href= / or img 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 base tag in the head 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 base tag anyway, and relative URLs are prefered in many cases - I would say they are far more frequent than server-relative URLs ). Costin
[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 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
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
