DO NOT REPLY [Bug 21489] New: - Catalina-ant task: problem with config parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489 Catalina-ant task: problem with config parameter Summary: Catalina-ant task: problem with config parameter Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Assume my paths and supplied username/password are correct (they are), then running this ant task: target name=install description=Install web application install url=http://localhost:8080/manager; username=system password=password config=file://C:/Tomcat4.1/webapps/context.xml path=myapp war=file://myapp.war / /target results in: BUILD FAILED file:C:/projects/fanbase/build.xml:96: FAIL - Encountered exception java.io.IOException: java.net.UnknownHostException: C Changing config to: config=file:/C:/Tomcat4.1/webapps/context.xml Solves the problem. In other words, the file:// is not read properly in the first example. Worth noting maybe is that the real path I use to the context.xml contains spaces. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFC] Handling the '*' URL
Bill Barker wrote: This is really a Request-For-Comments, I'm not proposing anything. I'm looking into resolving Bug #21454. At the moment, requests for e.g: OPTIONS * HTTP/1.1 TRACE * HTTP/1.1 get properly handled by TC 5 (thanks to Keith's patch), buy passing them to DefaultServlet. However, the '*' URL is really a HTTP Protocol URL, so it seems to me that it really should be handled by the Connector instead of the Servlet. On the other hand, we have access to the rich Servlet-API implementations (Ok, so I don't in 3.3-land, but I can fake it ;-). So my problem is that I can't see the correct route to go here. Opinions? I'm only talking about OPTIONS here. TRACE is protocol specific for all URLs (but I don't care about it ;-) ). I think it should be handled by the servlet, because for example you can replace the default servlet by the WebDAV servlet, and then it should return the DAV methods. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Soft termination: a demonstration
If I understand correctly, you modify the bytecode to insert checks before it loops back ? Pretty cool. I haven't looked too much at the code - do you do it via a generic ClassLoader ? Are you interested to contribute this to tomcat, or it's just a demo ? I'm wondering if the JVM itself wouldn't be a better place to implement this functionality ( i.e. a safe implementation of Thread.stop() ) Costin lgis Rudys wrote: Greetings -- As I announces about a week ago, as a part of my research, I have developed a mechanism for terminating individual Tomcat webapps (at the context level) called soft termination. For your further enjoyment, I've taken the liberty of setting up a demo install of my soft termination system. The demo install is at: http://puppet.cs.rice.edu:8080/ In particular, the following URL runs an infinite loop that prints the current time each second (note it does this with a while(true) and no sleeps): http://puppet.cs.rice.edu:8080/examples/servlet/ExceptionExample And this URL prints the current system status of the machine in question (updated once per second): http://www.cs.rice.edu/~arudys/loadavg.html Every 10 seconds, termination of the examples webapp is triggered. Note that it is triggered by updating the modification date of the ExceptionExample.class file (forcing a reload which terminates the old webapp) and not from within Tomcat. Once again, links for downloading the code and to the journal article describing soft termination can be found off this site: http://www.cs.rice.edu/~arudys/software/#softterm And feel free to badger me with any questions you see fit. Enjoy. Be nice. Algis Rudys - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFC] Handling the '*' URL
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 11:29 PM Subject: Re: [RFC] Handling the '*' URL Bill Barker wrote: This is really a Request-For-Comments, I'm not proposing anything. I'm looking into resolving Bug #21454. At the moment, requests for e.g: OPTIONS * HTTP/1.1 TRACE * HTTP/1.1 get properly handled by TC 5 (thanks to Keith's patch), buy passing them to DefaultServlet. However, the '*' URL is really a HTTP Protocol URL, so it seems to me that it really should be handled by the Connector instead of the Servlet. On the other hand, we have access to the rich Servlet-API implementations (Ok, so I don't in 3.3-land, but I can fake it ;-). So my problem is that I can't see the correct route to go here. Opinions? I'm only talking about OPTIONS here. TRACE is protocol specific for all URLs (but I don't care about it ;-) ). I think it should be handled by the servlet, because for example you can replace the default servlet by the WebDAV servlet, and then it should return the DAV methods. At the moment (at least in TC 5, which is the only one that returns a 200 Response), this is handled by the Default-Servlet (which ever one is mapped to '/', which defaults to DefaultServlet) in the ROOT Context. So, the current response according to you is still wrong if I have the the 'webdav' Context installed. rfc-quote rfc=2616 section=9.2 If the Request-URI is an asterisk (*), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the * request is only useful as a ping or no-op type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or la ck thereof). /rfc-quote I'm starting to lean to putting this into the Connector, rather than sending it to the Servlet (who can't possibly give a server-wide answer). Note: I'm only interested in the case where the Request-URI.equals(*). All other cases will go to the Servlet. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21472] - JDBCRealm: Auth ok but Not Authorized
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21472. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21472 JDBCRealm: Auth ok but Not Authorized --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 07:40 --- thank you and sorry :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21489] - Catalina-ant task: problem with config parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489 Catalina-ant task: problem with config parameter --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 08:48 --- IMO this is not a bug. file://C:/Tomcat4.1/webapps/context.xml is wrong and the fact that browsers like IE can accept such URL is not important here. One or three slashes work (//, empty host name and leading slash from path). Ad spaces: you should be able to use + or %20. I guess this should be closed as invalid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21489] - Catalina-ant task: problem with config parameter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21489 Catalina-ant task: problem with config parameter --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 08:57 --- Why does the file:// format work for the war= attribute? Should that not also give an error then? And which format should then be used withing the context.xml for the docbase=xxx attribute? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build timed out - jk2
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-07-11/jakarta-tomcat-jk-native2.html
Buildfile: build.xml
init.taskdef:
guess.os:
[echo] build.properties i386.Linux
[echo] Linux:true Win32:${win32} Netware:${netware} Solaris:${solaris}
HPUX:${hpux}
init.win32.properties:
init.win32.mc:
init.win32:
init.netware:
init.os:
guess.server:
[echo] Apache2 /usr/local/apache2 true
[echo] Apache13 /usr true
[echo] IIS ${iis.home} ${iis.detect}
[echo] Iplanet ${iplanet.home} ${iplanet.detect}
[echo] AOLserver ${aolserver.home} ${aolserver.detect}
[echo] JNI true
init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk2
apache20:
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk2/apache2
[so] Compiling 42 out of 42
Compiling
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
/home/rubys/bin/timeout: timed out
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs-faq connectors.xml
funkman 2003/07/11 03:57:20 Modified:docs/faq connectors.html docs/faq/printer connectors.html xdocs-faq connectors.xml Log: Add q about jk2 config file location based on tomcat user conversation http://marc.theaimsgroup.com/?t=10578489323amp;r=1amp;w=2 Revision ChangesPath 1.5 +33 -0 jakarta-tomcat-site/docs/faq/connectors.html Index: connectors.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/connectors.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- connectors.html 11 Jul 2003 01:57:37 - 1.4 +++ connectors.html 11 Jul 2003 10:57:19 - 1.5 @@ -101,6 +101,14 @@ At boot, is order of start up (Apache vs Tomcat) important? /a /li +li + a href=#jkloc + JK2 doesn't seem to be using my settings in my + codeworkers2.properties/code file + such as creating the shm file or mapping the URIs listed to Tomcat, + what's wrong? + /a +/li /ul /p /blockquote/td/tr/tabletable cellpadding=2 cellspacing=0 border=0trtd bgcolor=#525D76font face=arial,helvetica.sanserif color=#ffa name=AnswersstrongAnswers/strong/a/font/td/trtrtdblockquote @@ -241,6 +249,31 @@ No. This way - either apache or tomcat can be restarted at any time independent of one another. /divbr + + b style=font-size: larger +a name=jkloc + JK2 doesn't seem to be using my settings in my + codeworkers2.properties/code file + such as creating the shm file or mapping the URIs listed to Tomcat, + what's wrong? +/a + /b + div style=padding-left : 20px; +JK2 is not finding your codeworkers2.properties/code file. +Specify it's location in your codehttpd.conf/code file by adding: + +brbr +code +JkSet config.file /full/system/path/to/workers2.properties +/code +brbr +a href=http://marc.theaimsgroup.com/?t=10578489323r=1w=2; +Thread which spawned this question. +/a + /divbr + + + /blockquote/td/tr/table/td/tr!--FOOTER SEPARATOR--trtd colspan=2hr size=1 noshade=/td/tr!--PAGE FOOTER--trtd colspan=2div align=centerfont size=-1 color=#525D76em 1.4 +33 -0 jakarta-tomcat-site/docs/faq/printer/connectors.html Index: connectors.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/printer/connectors.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- connectors.html 11 Jul 2003 01:57:39 - 1.3 +++ connectors.html 11 Jul 2003 10:57:20 - 1.4 @@ -100,6 +100,14 @@ At boot, is order of start up (Apache vs Tomcat) important? /a /li +li + a href=#jkloc + JK2 doesn't seem to be using my settings in my + codeworkers2.properties/code file + such as creating the shm file or mapping the URIs listed to Tomcat, + what's wrong? + /a +/li /ul /p /blockquote/td/tr/tabletable cellpadding=2 cellspacing=0 border=0trtd bgcolor=#525D76font face=arial,helvetica.sanserif color=#ffa name=AnswersstrongAnswers/strong/a/font/td/trtrtdblockquote @@ -240,6 +248,31 @@ No. This way - either apache or tomcat can be restarted at any time independent of one another. /divbr + + b style=font-size: larger +a name=jkloc + JK2 doesn't seem to be using my settings in my + codeworkers2.properties/code file + such as creating the shm file or mapping the URIs listed to Tomcat, + what's wrong? +/a + /b + div style=padding-left : 20px; +JK2 is not finding your codeworkers2.properties/code file. +Specify it's location in your codehttpd.conf/code file by adding: + +brbr +code +JkSet config.file /full/system/path/to/workers2.properties +/code +brbr +a href=http://marc.theaimsgroup.com/?t=10578489323r=1w=2; +Thread which spawned this question. +/a + /divbr + + + /blockquote/td/tr/table/td/tr!--FOOTER SEPARATOR--trtd colspan=2hr size=1 noshade=/td/tr!--PAGE FOOTER--trtd colspan=2div align=centerfont size=-1 color=#525D76em 1.4 +33 -0 jakarta-tomcat-site/xdocs-faq/connectors.xml Index: connectors.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/connectors.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- connectors.xml11 Jul 2003 01:57:39 - 1.3 +++ connectors.xml11 Jul 2003 10:57:20 - 1.4 @@ -114,6 +114,14 @@ At boot, is order of start up (Apache vs Tomcat) important?
Re: [RFC] Handling the '*' URL
Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, July 10, 2003 11:29 PM Subject: Re: [RFC] Handling the '*' URL Bill Barker wrote: This is really a Request-For-Comments, I'm not proposing anything. I'm looking into resolving Bug #21454. At the moment, requests for e.g: OPTIONS * HTTP/1.1 TRACE * HTTP/1.1 get properly handled by TC 5 (thanks to Keith's patch), buy passing them to DefaultServlet. However, the '*' URL is really a HTTP Protocol URL, so it seems to me that it really should be handled by the Connector instead of the Servlet. On the other hand, we have access to the rich Servlet-API implementations (Ok, so I don't in 3.3-land, but I can fake it ;-). So my problem is that I can't see the correct route to go here. Opinions? I'm only talking about OPTIONS here. TRACE is protocol specific for all URLs (but I don't care about it ;-) ). I think it should be handled by the servlet, because for example you can replace the default servlet by the WebDAV servlet, and then it should return the DAV methods. At the moment (at least in TC 5, which is the only one that returns a 200 Response), this is handled by the Default-Servlet (which ever one is mapped to '/', which defaults to DefaultServlet) in the ROOT Context. So, the current response according to you is still wrong if I have the the 'webdav' Context installed. rfc-quote rfc=2616 section=9.2 If the Request-URI is an asterisk (*), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the * request is only useful as a ping or no-op type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or la ck thereof). /rfc-quote I'm starting to lean to putting this into the Connector, rather than sending it to the Servlet (who can't possibly give a server-wide answer). Note: I'm only interested in the case where the Request-URI.equals(*). All other cases will go to the Servlet. In my reasoning, I was implying that I had the asumption that the default servlet of the root context was a fair representation of what the server could do. Both work for me :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12263] - response.sendRedirect won't send to Tomcat SSL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263 response.sendRedirect won't send to Tomcat SSL --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 12:16 --- We are having a similar issue. I assume that this has to do with the fact that Tomcat Coyote connector knows about proxyName and proxyPort attributes, however assumes always http for the proxy. If you are using a HTTPS reverse proxy (or as you, a Stronghold Apache frontend), the 302 redirect Location header receives the wrong full qualified URL. I didn't do any further investigation, but I suggest the solution of adding a proxyScheme attribute which by default is http, but can be overridden with https, the only alternative valid value. I also would change the Component of this bug, but I leave this to active developers to decide. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21502] New: - [PATCH]Manager doesn't use correct method to get number of active sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21502. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21502 [PATCH]Manager doesn't use correct method to get number of active sessions Summary: [PATCH]Manager doesn't use correct method to get number of active sessions Product: Tomcat 4 Version: 4.1.25 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The question is: Why turn a hashmap into an array just to take its length when you already have a method that returns the number of sessions? This will make the life of people who write session managers that DON'T store all the active sessions in memory easier. --- HTMLManagerServlet.java 2003-03-19 04:18:34.0 -0500 +++ HTMLManagerServlet.java 2003-07-08 09:22:04.0 -0400 @@ -403,7 +403,7 @@ (request.getContextPath() + /html/sessions?path= + displayPath); args[4] = -new Integer(context.getManager().findSessions().length); +new Integer(context.getManager().getActiveSessions()); writer.print(MessageFormat.format(APPS_ROW_DETAILS_SECTION,args)); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21503] New: - [PATCH] Need to add special emphasis for windows service to setting JAVA_HOME
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21503. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21503 [PATCH] Need to add special emphasis for windows service to setting JAVA_HOME Summary: [PATCH] Need to add special emphasis for windows service to setting JAVA_HOME Product: Tomcat 4 Version: 4.1.25 Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-4.1- doc/RUNNING.txt OS/Version: All Status: NEW Severity: Major Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you don't notice that you HAVE to set JAVA_HOME before tomcat is installed, tomcat will NOT work as a service. This will cause no end of pain because only one bug report even mentions this issue. Google did not reveal the fix. * Set an environment variable JAVA_HOME to the pathname of the directory - into which you installed the JDK release. + into which you installed the JDK release. WINDOWS NOTE: Tomcat will + NOT work as a service if this is not set prior to installing tomcat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12263] - response.sendRedirect won't send to Tomcat SSL
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12263 response.sendRedirect won't send to Tomcat SSL --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 12:31 --- I believe this is fixed in the upcoming 4.1.25. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21504] New: - Possible clash of workdirs where compile JSPs are stored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21504. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21504 Possible clash of workdirs where compile JSPs are stored Summary: Possible clash of workdirs where compile JSPs are stored Product: Tomcat 5 Version: 5.0.3 Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: Jasper2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Web application deployed at default context root (/) stores by default its compiled JSPs in $CATALINA_HOME/work/Catalina/localhost/_ subtree. This may cause trouble if anyone deploys another application to /_ context path as it will try to use the same directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RFC] Handling the '*' URL
Hi Bill, I am partial to handling it in the default servlet. I agree the root context can't speak definitively for all contexts, but I think it has a better chance of knowing a proper response than the connector. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED] | Sent: Friday, July 11, 2003 2:08 AM | To: Tomcat Developers List | Subject: [RFC] Handling the '*' URL | | | This is really a Request-For-Comments, I'm not proposing anything. I'm | looking into resolving Bug #21454. | | At the moment, requests for e.g: | OPTIONS * HTTP/1.1 | TRACE * HTTP/1.1 | get properly handled by TC 5 (thanks to Keith's patch), buy passing them to | DefaultServlet. However, the '*' URL is really a HTTP Protocol URL, so it | seems to me that it really should be handled by the Connector instead of the | Servlet. On the other hand, we have access to the rich Servlet-API | implementations (Ok, so I don't in 3.3-land, but I can fake it ;-). So my | problem is that I can't see the correct route to go here. | | Opinions? | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3614] - bug in manager webapp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3614. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3614 bug in manager webapp [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 14:26 --- The bu is not resolved, i'm using tomcat 4.1.18 and the bug is still active - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456 logs/context lost when restarting Context --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 14:34 --- Created an attachment (id=7244) new admin.war with : patch 21456 from tomcat332 + logRestart + contextsList sorted + contextsList with no cache - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456 logs/context lost when restarting Context --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 14:36 --- Created an attachment (id=7245) diff between this new version and the tomcat-332-nightlybuild-on-20030710 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16113. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16113 removing then replacing a jsp page continues to give a 404 --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 14:40 --- We're seeing it too. Very nasty. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21456] - logs/context lost when restarting Context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21456 logs/context lost when restarting Context [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 14:44 --- With the new version of admin.war I attach, this bug is resolved. For the patch, I took the code of restart in admin-tomcat3.3.2-nightlybuild-on-20030710 (less a new functionnality) and I add new things as : - context list sorted by host:path - a log with the user restarting context - and a button Return to Context List with Pragma=no-cache (instead of a http link). Thank you to William. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat job opportunity
Greetings.I work for an executive search firm in NY and am currently looking, on behalf of my client, for a Tomcat software engineering with a solid understanding of Tomcat internals. I can provide more details about the role and the client when we speak. I was hoping you or someone you know might be interested in speaking with me about this job opportunity. I appreciate your consideration in advance and hope to hear back from you soon. Thanks - Steven Steven Pincus R.W. Davis Co. 90 Park Avenue New York, NY 10016 Tel. (212)231-4400 ext. 216 Fax (212)993-8080 Cell (973)722-2163 [EMAIL PROTECTED] www.rwdavisco.com
Re: java Date related classes synchronization bottlenecks
David Cassidy said: I've done some tests with the below code hope this helps David, Could you give this version a try, and run it for 1 million iterations instead of just 10k? I'll be posting my results shortly for a couple of different machines shortly. The new version keeps the theoretical overall run time constant by keeping the overall amount of work the same while you vary the thread count. So if you supply arguments 1 and 1 million, and then 2 and 1 million, in the first case 1 thread will go through 1 million iterations, in the second case each of the two threads will only go throgh 500,000 iterations. Saves you division. ;-) Glenn, it would be interesting for you to modify the code to remove the synchronization issue and then re-run the quick benchmark. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
Here are the results from the last version of the TestDatePerf program I sent out. Below are the results from 3 different systems when run for 1 million iterations. Here's how I interpret the results: The program verifies the synchronization performance issue. Dual-CPU machines take a huge performance hit when going from 1-2 processes fighting for the same synchronized lock. The dual processor machine always performs worse than the single processor with more than 1 thread running and doesn't start catching up until 16 threads are running. I did a few test runs when running 2 threads and watching the output from top, I noticed that both CPUs were not kept busy (as expected). Out of curiosity, I also tweaked the progrom and took out the call to Timestamp.toString() and replaced it with some non-synchronized code. This code scaled almost perfectly when going from 1 to 2 threads on the dual-cpu systems (run-time cut very close to 1/2) and increasing the number of threads to 16 showed very little performance deviation over the 2 thread case. So it looks like the bottleneck is real and depending on CPU performance I would guess that you would start seeing when when you start making a few thousand calls a second to these methods. -Dave Each system ran the following: time java TestJavaPerf threads 100 with threads values of 1, 2, 4, 8, 16. All Linux systems on on kernel 2.4.20. It would interesting to see if recent 2.5.x kernels perform better as they reported have improved multi-thread performance in the latest development kernels. System 1: Duron 600MHz, Sun Java 1.4.2, RedHat Linux System 2: PIII 500MHz, Sun Java 1.4.2, RedHat Linux System 3: Dual PIII 500MHz, Sun Java 1.4.2, RedHat Linux System 4: Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX Sys# Threads Real User Sys 1160.3 59.6 0.2 1278.2 72.8 5.3 14 122.0 93.1 28.8 18 152.1 105.0 47.0 116 184.4 121.6 62.7 Sys# Threads Real User Sys 2180.5 80.2 0.3 22 108.0 111.2 3.2 24 177.2 141.5 34.4 28 290.1 200.3 88.5 216 325.2 220.0 103.9 Sys# Threads Real User Sys 3180.4 80.2 0.4 32 249.3 221.3 94.8 34 289.8 244.0 124.8 38 309.8 257.6 130.5 316 325.4 264.4 132.2 Sys# Threads Real User Sys 41 197.0 186.9 1.5 42 289.7 487.5 8.9 44 1148.9 996.9 267.0 48 1734.8 1086.0 284.3 416 1717.2 1058.4 284.8 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20663] - Cannot shutdown Tomcat gracefully
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20663. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20663 Cannot shutdown Tomcat gracefully --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 16:00 --- I also get it - right out of the box (only changed 8080 to 1080) The exceptin happens in PoolTcpEndpoint. I attach a truss of the java VM for the whole shutdown, in case someone is interested. It shows the socket being terminated without an explicit close() call. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20663] - Cannot shutdown Tomcat gracefully
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20663. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20663 Cannot shutdown Tomcat gracefully --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 16:02 --- Created an attachment (id=7248) Truss output of the SHUTDOWN of tomcat process - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: java Date related classes synchronization bottlenecks
David, I didn't see an attachment that time. Thanks as this is interesting stuff for Java development of any kind, not just Tomcat! Jamey James Courtney InPhonic, Inc. -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 8:34 AM To: [EMAIL PROTECTED] Subject: Re: java Date related classes synchronization bottlenecks David Cassidy said: I've done some tests with the below code hope this helps David, Could you give this version a try, and run it for 1 million iterations instead of just 10k? I'll be posting my results shortly for a couple of different machines shortly. The new version keeps the theoretical overall run time constant by keeping the overall amount of work the same while you vary the thread count. So if you supply arguments 1 and 1 million, and then 2 and 1 million, in the first case 1 thread will go through 1 million iterations, in the second case each of the two threads will only go throgh 500,000 iterations. Saves you division. ;-) Glenn, it would be interesting for you to modify the code to remove the synchronization issue and then re-run the quick benchmark. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Remy,
Jan Luehe wrote:
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE
(default) or FALSE: if TRUE, the output buffer size limit is set
to the output buffer size (current behaviour), and if FALSE, an
output buffer may grow infinitely.
Comments?
-1. The performance impact of chunking on the server side is zero. If
you client bench program is dumb and its performance degrades with
chunking, fine, but please keep this optimization for SunOne ;-) Your
change basically does an automatic DoS condition on the server (simply
request a big file and boom).
How about making the output buffer size limit configurable?
(A value of -1 could mean indefinite growth, if people know what they
are doing.)
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16113] - removing then replacing a jsp page continues to give a 404
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16113. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16113 removing then replacing a jsp page continues to give a 404 --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 17:36 --- I have a working patch for this bug; I'd appreciate help/advice from anyone more familiar with creating and submitting patches to the Tomcat team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in org.apache.catalina.authenticator.DigestAuthenticator
line 317: qop = removeQuotes(currentTokenValue); needs to be: qop = currentTokenValue; I was using the Tomcat 4.1.24 code as an example for Digest Authentication and discovered that the hashes weren't matching in my code. Since auth was being stripped to ut, the hashes were screwed up. I checked the RFC 2617 spec http://asg.web.cmu.edu/rfc/rfc2617.html#sec-3.5 and qop doesn't have quotes. I searched the list and couldn't find if this was discovered or not, so I decided to post here :) Adam Hathcock - This mail sent through IMP: http://horde.org/imp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21524] New: - Thread Leak
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21524. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21524 Thread Leak Summary: Thread Leak Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have isolated this problem in the CoyoteConnector thread pooling. Upon every HTTP request the thread count goes up and never gets cleaned by the GC. I am able to monitor this through the windows task manager (added thread count column). Tomcat initially starts with 45 threads; let the server run for 24 hours (about 70 to 80 HTTP requests) and the thread count is 230. This eventually results in server crash when the VM runs out of heap. Thread pool configuration is ...minProcessors=5 maxProcessors=25 acceptCount=10 enableLookups=false. Increasing JMV memory only delays the crash. This is turning out to be a serious problem in our production servers. Is there is work around? Server is running on windows-2000 SP3. Java version is 1.3.1_04-b02. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Fri, Jul 11, 2003 at 10:10:21AM -0700, James Courtney wrote:
I didn't see an attachment that time. Thanks as this is interesting
stuff for Java development of any kind, not just Tomcat!
Stupid me. Is attached now.
-Dave
import java.sql.*;
import java.util.*;
public class TestDatePerf
extends Thread
{
int iterations;
Timestamp date = null;
public TestDatePerf(int iterations) {
this.iterations = iterations;
date = new Timestamp(System.currentTimeMillis());
}
public void run() {
for (int i = 0; i iterations; i++) {
date.toString();
}
}
public static void main(String args[]) {
int threads = Integer.parseInt(args[0]);
int iterations = Integer.parseInt(args[1]);
for (int i = 0; i threads; i++) {
TestDatePerf tdp = new TestDatePerf((int)iterations/threads);
tdp.start();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Fri, Jul 11, 2003 at 08:57:54AM -0700, David Rees wrote: System 4: Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX I was mistaken about the CPU freq of this machine, it really has 2 R10k 180MHz CPUs, not 225MHz. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat job opportunity
Steven, I did modify Jasper (Tomcat's JSP engine) a couple years back to support scripting languages in the JSP scriptlets. Though I don't have intimate knowledge of the Tomcat internals, they are pretty well documented, I do use it, and this type of low-level development is my specialty (and my favorite ;)). Is the client looking for extensions, performance tweaks, web services integration, etc.? My cel. number is 314-537-6570. Thanks, Bob On Friday, July 11, 2003, at 10:40 AM, Steven Pincus wrote: Greetings.I work for an executive search firm in NY and am currently looking, on behalf of my client, for a Tomcat software engineering with a solid understanding of Tomcat internals. I can provide more details about the role and the client when we speak. I was hoping you or someone you know might be interested in speaking with me about this job opportunity. I appreciate your consideration in advance and hope to hear back from you soon. Thanks - Steven Steven Pincus R.W. Davis Co. 90 Park Avenue New York, NY 10016 Tel. (212)231-4400 ext. 216 Fax (212)993-8080 Cell (973)722-2163 [EMAIL PROTECTED] www.rwdavisco.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Trying to make a patch, confused by Tomcat's CVS setup
Hi, I have two patches for outstanding bugs of 4.1.24. I'm trying to pull down sources via CVS, both to make sure these patches are still needed, and to build the patch files themselves. I followed the instructions here: http://jakarta.apache.org/site/cvsindex.html I pulled out files tagged TOMCAT_4_1_24. But, when I happened to compare what I pulled down to what is in the 4.1.24 source archive distributed from the Tomcat site, I found radical differences. What am I doing wrong? IOW, what repository are the source release archives built from, and how can I get at it? P.S. On the file that I checked, the majority of the text was different, but the most interesting difference to me was at the top; I include it here in case it may this more clear. The first block is from the CVS checkout I did (labeled TOMCAT_4_1_24), the second is from the archive jakarta-tomcat-4.1.24-LE-jdk14.zip: 2,4c2,4 * $Header: /home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v 1.15 2002/05/16 00:41:26 kinman Exp $ * $Revision: 1.15 $ * $Date: 2002/05/16 00:41:26 $ --- * $Header: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v 1.12.2.6 2003/03/17 20:53:39 costin Exp $ * $Revision: 1.12.2.6 $ * $Date: 2003/03/17 20:53:39 $
Re: [RFC] Handling the '*' URL
Well, it seems that the consensus is for the default servlet. That's where I'll make the changes for 3.3. - Original Message - From: Keith Wannamaker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, July 11, 2003 5:35 AM Subject: RE: [RFC] Handling the '*' URL Hi Bill, I am partial to handling it in the default servlet. I agree the root context can't speak definitively for all contexts, but I think it has a better chance of knowing a proper response than the connector. Keith | -Original Message- | From: Bill Barker [mailto:[EMAIL PROTECTED] | Sent: Friday, July 11, 2003 2:08 AM | To: Tomcat Developers List | Subject: [RFC] Handling the '*' URL | | | This is really a Request-For-Comments, I'm not proposing anything. I'm | looking into resolving Bug #21454. | | At the moment, requests for e.g: | OPTIONS * HTTP/1.1 | TRACE * HTTP/1.1 | get properly handled by TC 5 (thanks to Keith's patch), buy passing them to | DefaultServlet. However, the '*' URL is really a HTTP Protocol URL, so it | seems to me that it really should be handled by the Connector instead of the | Servlet. On the other hand, we have access to the rich Servlet-API | implementations (Ok, so I don't in 3.3-land, but I can fake it ;-). So my | problem is that I can't see the correct route to go here. | | Opinions? | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
- Original Message -
From: Jan Luehe [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, July 11, 2003 10:11 AM
Subject: Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Remy,
Jan Luehe wrote:
Currently, the limit up to which the size of an
org.apache.coyote.tomcat5.OutputBuffer may grow is identical to the
original buffer size:
public OutputBuffer(int size) {
bb = new ByteChunk(size);
bb.setLimit(size);
...
cb = new CharChunk(size);
cb.setLimit(size);
}
As a result of this, if the response does not fit in the output
buffer, the buffer is flushed, and the response does no longer include
a Content-Length header. Instead, it includes a Transfer-Encoding
header whose value is chunked:
Transfer-Encoding: chunked
It may be useful (e.g., for some benchmarks such as TPC-W) to be able
to configure a connector such that the buffer size of its responses
grows infinitely, in which case the above setLimit calls would not
occur and the response would always include a Content-Length header,
no matter how big.
I am proposing a CoyoteConnector attribute outLimited (I am open to
other naming suggestions), whose possible values may be TRUE
(default) or FALSE: if TRUE, the output buffer size limit is set
to the output buffer size (current behaviour), and if FALSE, an
output buffer may grow infinitely.
Comments?
-1. The performance impact of chunking on the server side is zero. If
you client bench program is dumb and its performance degrades with
chunking, fine, but please keep this optimization for SunOne ;-) Your
change basically does an automatic DoS condition on the server (simply
request a big file and boom).
How about making the output buffer size limit configurable?
(A value of -1 could mean indefinite growth, if people know what they
are doing.)
I also dislike the proposal, but since it's configurable, and off by default
I can limit myself to -0. The biggest problem I see is that if people know
what they are doing, then they would never dream of enabling the option :).
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21529] New: - Bug in org.apache.catalina.authenticator.DigestAuthenticator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21529. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21529 Bug in org.apache.catalina.authenticator.DigestAuthenticator Summary: Bug in org.apache.catalina.authenticator.DigestAuthenticator Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: All Status: UNCONFIRMED Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] line 317: qop = removeQuotes(currentTokenValue); needs to be: qop = currentTokenValue; I was using the Tomcat 4.1.24 code as an example for Digest Authentication and discovered that the hashes weren't matching in my code. Since auth was being stripped to ut, the hashes were screwed up. I checked the RFC 2617 spec http://asg.web.cmu.edu/rfc/rfc2617.html#sec-3.5 and qop doesn't have quotes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
