DO NOT REPLY [Bug 25158] New: - Tomcat can't load sessions whose attributes refer the session instance
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=25158. 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=25158 Tomcat can't load sessions whose attributes refer the session instance Summary: Tomcat can't load sessions whose attributes refer the session instance Product: Tomcat 4 Version: 4.1.27 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When putting an instance into the session that has a non transient reference to the current session, storage on tomcat shutdown succeeds but on loading the session during tomcat startup fails with a java.io.StreamCorruptedException. (see attachment, which contains a sample app as well as a log file with debug=99) As an additional Note: when one tries to serialize the session instance into a ByteArrayOutputStream just before storage, there is no serialization error. This problem seems to be special to *loading*. Steps to reproduce: 0. optionally build the webapp 1. deploy the web application 2. start tomcat 3. access http://server/path/index.jsp 4. shutdown tomcat 5. start tomcat 6. check the log When the instance of class test.SessionBindingListener does *not* keep the reference to the session instance, the problem goes away. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25158] - Tomcat can't load sessions whose attributes refer the session instance
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=25158. 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=25158 Tomcat can't load sessions whose attributes refer the session instance --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 10:59 --- Created an attachment (id=9371) log file with error (debug=99), webapp to reproduce error - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ThreadPool logFull
I have Tomcat 4.1.24 + IIS 5 + JK2. After Tomcat had been running for about 22 hours, Tomcat stop responding to HTTP request. Even when I type http://localhost:8080/, it is not responding. The only log error is in stderr log file:org.apache.tomcat.util.threads.ThreadPool logFullSEVERE: All threads are busy, waiting. Please increase maxThreads or checkthe servlet status75 75Any ideas? Leandro Karam Quintas EBS Sistemas IncrediMail - Email has finally evolved - Click Here
DO NOT REPLY [Bug 25158] - Tomcat can't load sessions whose attributes refer the session instance
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=25158. 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=25158 Tomcat can't load sessions whose attributes refer the session instance [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 11:41 --- HttpSession does not extend Serializable so the assumption cannot be made that it can or cannot be persisted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.16
Remy Maucherat wrote: Shapira, Yoav wrote: Howdy, ballot Release 5.0.16 as Stable ? [ X ] Yes [ ] No /ballot Did my usual tests: examples, my applications (and their cactus/junit tests), manager webapp, links, docs, balancer. Since I have the required three votes, I'll move the binaries later today so they can be replicated before an official announcement is made. I'll pull them if there's a problem (somehow). About this, I plan to make the announcement later today, in about 12 hours. So if you don't agree with the release, it's time to vote ;-) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Jess Holle wrote: Tim Funk wrote: Section 5.5 of the spec: When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. The following events indicate that the servlet has satisfied the request and that the response object is to be closed: /.../ * The amount of content specified in the setContentLength method of the response has been written to the response. * That's what I figured. I'm just a bit uncertain about the corner/end case where nothing is to be written to the response, i.e. for a content-length of 0. It becomes clearer to me if I rephrase The amount /.../ has been written /.../ to the in this context supposedly equivalent At least the amount /.../ has been written /.../. Then the special case of 0 becomes: At least zero bytes have been written to the response. which is indisputably true, and thus the response object is to be closed. Dan Johnsson _ Dan Johnsson | Skerhetsarkitekt [EMAIL PROTECTED] | www.omegapoint.se tel 0709-15 88 43 | fax 08-517 008 29 Omegapoint AB - din skra punkt i tillvaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal server.xml
+1 I would even suggest distribute something like this as the ordinary server.xml, and rename the other as server-examples.xml. Why? I do most of my tomcat-work with initial users, i e either students taking classes or people doing their first installation. They are not helped by the rich server.xml as they do not yet grasp all the concepts. To them it would be a lot better to start with a small server.xml and then add features as they understand them. And the power-users? Well, they usually think the server.xml is cluttered with all those examples they already understand. So examples are great, but I think they should be elsewhere than in the production config file. Dan Johnsson Jeanfrancois Arcand wrote: +1 You can also remove the xmlValidation=false xmlNamespaceAware=false, since they are optionals. -- Jeanfrancois Shapira, Yoav wrote: Hi, IMHO the server.xml that comes with tomcat by default ($CATALINA_HOME/conf/server.xml) is nice in that it provides many comments and examples. But I think power users would appreciate a minimal version as well, so I've created one, as shown below. Should we distribute something like this, perhaps as $CATALINA_HOME/conf/server-minimal.xml? Server port=8005 shutdown=SHUTDOWN debug=0 Service name=Catalina Connector port=8080 maxThreads=150 minSpareThreads=1 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true / Engine name=Catalina defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_log. suffix=.txt timestamp=true/ /Host /Engine /Service /Server Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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] -- _ Dan Johnsson | Säkerhetsarkitekt [EMAIL PROTECTED] | www.omegapoint.se tel 0709-15 88 43 | fax 08-517 008 29 Omegapoint AB - din säkra punkt i tillvaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25160] New: - [PATCH] improve I18N for admintool
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=25160. 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=25160 [PATCH] improve I18N for admintool Summary: [PATCH] improve I18N for admintool Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I send admintools I18N improve patch for tomcat4.1.x. This patch improve more about I18N. This patch improve following problem: + The left frame wasn't internationalized. + Some of the word in right frame weren't internationalized. + Some one miss understand MessageResource.getString(java.lang.Locale locale, java.lang.String key ..) API. ex. resources.getString(mssage, locale); I modified English and Japanese ApplicationResources property files. However I don't know how can I tranlate for Esperanto. So I added TODO comment in ApplicationResources_es.properties. Please take following patch. http://yamaguch.sytes.net/~tora/tmp/tomcat5-admin-i18n.patch and + add ApplicationResources.properties http://yamaguch.sytes.net/~tora/tmp/ApplicationResources.properties * this file is delived from ApplicationResources_en.properties. + remove ApplicationResources_en.properties. One more ask here. SetCharacterEncodingFilter is commented. This means other than English people must modify web.xml for input thier own character. I would like to uncommend SetCharacterEncodingFilter and set default encoding to utf-8. utf-8 is upper compatible with iso-8859-1 and most of people won't be affected by utf-8. I would like to recommend it to conviniency for non English user. regards, Takashi Okamoto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal server.xml
Dan Johnsson wrote: +1 I would even suggest distribute something like this as the ordinary server.xml, and rename the other as server-examples.xml. Why? I do most of my tomcat-work with initial users, i e either students taking classes or people doing their first installation. They are not helped by the rich server.xml as they do not yet grasp all the concepts. To them it would be a lot better to start with a small server.xml and then add features as they understand them. And the power-users? Well, they usually think the server.xml is cluttered with all those examples they already understand. So examples are great, but I think they should be elsewhere than in the production config file. This does sound like vallid points. However, we would have to add an AJP connector to the mix so that the minimal config is out of the box compatible with the current default config. We would need a realm as well. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal server.xml
I am +1 on this as well. Again, I recommend removing the Logging tag. Tomcat's ability to log to many different places (Rolling logs for each web applications, etc...) is a good thing for an enterprise product, but most newbies just want to see the stack trace that corresponds with an error page they just saw. Without any Logging tags, all messages go to catalina.out just like the start up message says. Cheers, -bob On Wed, 2003-12-03 at 07:43, Remy Maucherat wrote: Dan Johnsson wrote: +1 I would even suggest distribute something like this as the ordinary server.xml, and rename the other as server-examples.xml. Why? I do most of my tomcat-work with initial users, i e either students taking classes or people doing their first installation. They are not helped by the rich server.xml as they do not yet grasp all the concepts. To them it would be a lot better to start with a small server.xml and then add features as they understand them. And the power-users? Well, they usually think the server.xml is cluttered with all those examples they already understand. So examples are great, but I think they should be elsewhere than in the production config file. This does sound like vallid points. However, we would have to add an AJP connector to the mix so that the minimal config is out of the box compatible with the current default config. We would need a realm as well. Rémy - 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 25162] New: - charset parameter in contentType header is always included
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=25162. 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=25162 charset parameter in contentType header is always included Summary: charset parameter in contentType header is always included Product: Tomcat 5 Version: 5.0.14 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I think, that this is a wrong idea to explicitly define a parameter charset for any contentType of Response. For examples: 1. I render a PDF document as a response of my servlet with contentType=application/pdf. Then the IE receives a header application/pdf;charset=ISO-8859-1 and it can't understand this content type. Even more, do you see, that this charset parameter is useless here? 2. I put into my JSP page a line like this: %@ page contentType=text/html;CHARSET=windows-1251 %. I use here an uppercase for CHARSET to avoid character encoding (transforming) of my JSP page by the engine, so it must use a system default encoding (I use this for multilanguage support in my application, that works with a database without unicode, and I didn't thinking about encoding, just gives this part for browser). The browser receives a header: text/html;CHARSET=windows-1251;charset=ISO-8859-1! Great! Conclusion: take back a control on the content type to the user, please! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Anyone, please ????
I have Tomcat 4.1.24 + IIS 5 + JK2. After Tomcat had been running for about 22 hours, Tomcat stop responding to HTTP request. Even when I type http://localhost:8080/, it is not responding. The only log error is in stderr log file: org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status75 75 Any ideas? Leandro Karam Quintas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25162] - charset parameter in contentType header is always included
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=25162. 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=25162 charset parameter in contentType header is always included [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 13:27 --- This is fixed in 5.0.16 which should be out any moment. *** This bug has been marked as a duplicate of 24970 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24970] - charset appended to content-type even if not text/*
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=24970. 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=24970 charset appended to content-type even if not text/* [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 13:27 --- *** Bug 25162 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal server.xml
Dan Johnsson wrote: I would even suggest distribute something like this as the ordinary server.xml, and rename the other as server-examples.xml. /.../ So examples are great, but I think they should be elsewhere than in the production config file. Remy Maucherat wrote: This does sound like vallid points. However, we would have to add an AJP connector to the mix so that the minimal config is out of the box compatible with the current default config. Sounds like a reasonable compromise to me. We would need a realm as well. Most probably: without one it will be hard for the beginners to use the manager app, something they definately want to do. (Or is it enough that the settings needed (realm, add user, etc) are described in the Management HOW-TO? Dan Johnsson _ Dan Johnsson | Säkerhetsarkitekt [EMAIL PROTECTED] | www.omegapoint.se tel 0709-15 88 43 | fax 08-517 008 29 Omegapoint AB - din säkra punkt i tillvaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimal server.xml
On logging: The suggested server-minimal.xml does only contain a Logging-tag that makes no use of the special features (thus only logging to catalina.out, making the tag redundant, nicht Wahr?). To compensate for the lack of out of the box features, we should add brief HOW-TO:s. I volunteer to do one on e g logging. Bob Herrmann wrote: I am +1 on this as well. Again, I recommend removing the Logging tag. Tomcat's ability to log to many different places (Rolling logs for each web applications, etc...) is a good thing for an enterprise product, but most newbies just want to see the stack trace that corresponds with an error page they just saw. Without any Logging tags, all messages go to catalina.out just like the start up message says. Cheers, -bob On Wed, 2003-12-03 at 07:43, Remy Maucherat wrote: Dan Johnsson wrote: +1 I would even suggest distribute something like this as the ordinary server.xml, and rename the other as server-examples.xml. Why? I do most of my tomcat-work with initial users, i e either students taking classes or people doing their first installation. They are not helped by the rich server.xml as they do not yet grasp all the concepts. To them it would be a lot better to start with a small server.xml and then add features as they understand them. And the power-users? Well, they usually think the server.xml is cluttered with all those examples they already understand. So examples are great, but I think they should be elsewhere than in the production config file. This does sound like vallid points. However, we would have to add an AJP connector to the mix so that the minimal config is out of the box compatible with the current default config. We would need a realm as well. Rémy - 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] -- _ Dan Johnsson | Säkerhetsarkitekt [EMAIL PROTECTED] | www.omegapoint.se tel 0709-15 88 43 | fax 08-517 008 29 Omegapoint AB - din säkra punkt i tillvaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Minimal server.xml
Howdy, Thanks for the feedback. I will add the AJP port 8009 connector for compatibility. I've taken out the Logger. See current version here: http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml Additional documentation is always welcome (outside this file). Please discuss and develop them on the user list, and once finalized we'll get them into CVS. Thanks, Yoav Shapira Millennium ChemInformatics -Original Message- From: Dan Johnsson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 8:53 AM To: Tomcat Developers List Subject: Re: Minimal server.xml On logging: The suggested server-minimal.xml does only contain a Logging-tag that makes no use of the special features (thus only logging to catalina.out, making the tag redundant, nicht Wahr?). To compensate for the lack of out of the box features, we should add brief HOW-TO:s. I volunteer to do one on e g logging. Bob Herrmann wrote: I am +1 on this as well. Again, I recommend removing the Logging tag. Tomcat's ability to log to many different places (Rolling logs for each web applications, etc...) is a good thing for an enterprise product, but most newbies just want to see the stack trace that corresponds with an error page they just saw. Without any Logging tags, all messages go to catalina.out just like the start up message says. Cheers, -bob On Wed, 2003-12-03 at 07:43, Remy Maucherat wrote: Dan Johnsson wrote: +1 I would even suggest distribute something like this as the ordinary server.xml, and rename the other as server-examples.xml. Why? I do most of my tomcat-work with initial users, i e either students taking classes or people doing their first installation. They are not helped by the rich server.xml as they do not yet grasp all the concepts. To them it would be a lot better to start with a small server.xml and then add features as they understand them. And the power-users? Well, they usually think the server.xml is cluttered with all those examples they already understand. So examples are great, but I think they should be elsewhere than in the production config file. This does sound like vallid points. However, we would have to add an AJP connector to the mix so that the minimal config is out of the box compatible with the current default config. We would need a realm as well. Rémy - 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] -- _ Dan Johnsson | Säkerhetsarkitekt [EMAIL PROTECTED] | www.omegapoint.se tel 0709-15 88 43 | fax 08-517 008 29 Omegapoint AB - din säkra punkt i tillvaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/conf server-minimal.xml
yoavs 2003/12/03 07:30:38 Modified:catalina/src/conf server-minimal.xml Log: Added AJP connector and user database Revision ChangesPath 1.2 +24 -0 jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml Index: server-minimal.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/server-minimal.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- server-minimal.xml2 Dec 2003 18:16:18 - 1.1 +++ server-minimal.xml3 Dec 2003 15:30:38 - 1.2 @@ -1,9 +1,33 @@ Server port=8005 shutdown=SHUTDOWN + GlobalNamingResources +!-- Used by Manager webapp -- +Resource name=UserDatabase auth=Container + type=org.apache.catalina.UserDatabase + description=User database that can be updated and saved +/Resource +ResourceParams name=UserDatabase + parameter +namefactory/name +valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value + /parameter + parameter +namepathaame/name +valueconf/tomcat-users.xml/value + /parameter +/ResourceParams + /GlobalNamingResources + Service name=Catalina Connector port=8080 / +!-- This is here for compatibility only, not required -- +Connector port=8009 protocol=AJP/1.3 / + Engine name=Catalina defaultHost=localhost Logger className=org.apache.catalina.logger.FileLogger / + + Realm className=org.apache.catalina.realm.UserDatabaseRealm + resourceName=UserDatabase / Host name=localhost appBase=webapps / /Engine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Anyone, please ????
I suppose upgrading 5 minor point releases to version 4.1.29 to see if the problem goes away didn't occur to you? -Original Message- From: L.Karam [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 6:10 AM To: [EMAIL PROTECTED] Subject: Anyone, please I have Tomcat 4.1.24 + IIS 5 + JK2. After Tomcat had been running for about 22 hours, Tomcat stop responding to HTTP request. Even when I type http://localhost:8080/, it is not responding. The only log error is in stderr log file: org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status75 75 Any ideas? Leandro Karam Quintas - 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]
Re: Need installation of Tomcat jakarta-tomcat-5.0.12 on Windows 98 - How to proceed?
Very easy: send mail to [EMAIL PROTECTED] ;-) -- Jeanfrancois Anamika . wrote: - Do you Yahoo!? Free Pop-Up Blocker - Get it now - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I would like to contribute to the jakarta-tomcat-connectors proje ct
How do I go about getting commit status to that project? Thanks -sean CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: I would like to contribute to the jakarta-tomcat-connectors project
Howdy, You start by discussing and sending patches to the list. Commit status possibly comes later. http://jakarta.apache.org/site/getinvolved.html Yoav Shapira Millennium ChemInformatics -Original Message- From: Scott, Sean [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 11:26 AM To: '[EMAIL PROTECTED]' Subject: I would like to contribute to the jakarta-tomcat-connectors project How do I go about getting commit status to that project? Thanks -sean CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - 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]
Re: I would like to contribute to the jakarta-tomcat-connectors proje ct
Scott, Sean wrote: How do I go about getting commit status to that project? Read: http://jakarta.apache.org/site/getinvolved.html Then: http://jakarta.apache.org/site/source.html#Patches ;-) -- Jeanfrancois Thanks -sean CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - 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]
RE: I would like to contribute to the jakarta-tomcat-connectors p roject
What if what I am proposing is an enhancement, not just a patch? -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 9:32 AM To: Tomcat Developers List Subject: RE: I would like to contribute to the jakarta-tomcat-connectors project Howdy, You start by discussing and sending patches to the list. Commit status possibly comes later. http://jakarta.apache.org/site/getinvolved.html Yoav Shapira Millennium ChemInformatics -Original Message- From: Scott, Sean [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 11:26 AM To: '[EMAIL PROTECTED]' Subject: I would like to contribute to the jakarta-tomcat-connectors project How do I go about getting commit status to that project? Thanks -sean CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - 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] CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: I would like to contribute to the jakarta-tomcat-connectors project
Howdy, Same thing for enhancements, patches, fixes, documentation, etc. Yoav Shapira Millennium ChemInformatics -Original Message- From: Scott, Sean [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 11:41 AM To: 'Tomcat Developers List' Subject: RE: I would like to contribute to the jakarta-tomcat-connectors project What if what I am proposing is an enhancement, not just a patch? -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 9:32 AM To: Tomcat Developers List Subject: RE: I would like to contribute to the jakarta-tomcat-connectors project Howdy, You start by discussing and sending patches to the list. Commit status possibly comes later. http://jakarta.apache.org/site/getinvolved.html Yoav Shapira Millennium ChemInformatics -Original Message- From: Scott, Sean [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 11:26 AM To: '[EMAIL PROTECTED]' Subject: I would like to contribute to the jakarta-tomcat-connectors project How do I go about getting commit status to that project? Thanks -sean CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - 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] CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5 Issue (not 5.0.16 specific!)
Dan Johnsson wrote: Jess Holle wrote: Tim Funk wrote: Section 5.5 of the spec: When a response is closed, the container must immediately flush all remaining content in the response buffer to the client. The following events indicate that the servlet has satisfied the request and that the response object is to be closed: /.../ * The amount of content specified in the setContentLength method of the response has been written to the response. * That's what I figured. I'm just a bit uncertain about the corner/end case where nothing is to be written to the response, i.e. for a content-length of 0. \ It becomes clearer to me if I rephrase The amount /.../ has been written /.../ to the in this context supposedly equivalent At least the amount /.../ has been written /.../. Then the special case of 0 becomes: At least zero bytes have been written to the response. which is indisputably true, and thus the response object is to be closed. I am absolutely in agreement that Tomcat is in line with the letter of the spec here. I just think that the a few more letter should really present as it seems inappropriate for a setContentLength(0) to commit a response. -- Jess Holle
[JK2 Enhancement] modify behavior when max_endpoints have been re ached
I have locally modified the head revision of the jk2 project and would like some feedback before submitting the enhancements for review. The change in behavior that we desired was that rather than returning an error when the max_connections for the endpoint cache were reached, the worker would wait for an endpoint to be returned to the cache. Consider the scenario where apache is configured to have lots ( lets say 900 ) of worker threads, but we want to limit the connections to tomcat to just a few ( lets say 15 ). Without the enhancement I am proposing, we had to configure the AJP connector in tomcat as follows. connection timeout = 1 ( problematic as testing using a slow connection would drop connections ), accept count 1000 ( needed so that we could queue up requests from apache ) max threads = 30 ( We determined that jdk/tomcat we spend more time waiting than working with more threads than this ) And configure jk2 not to limit the connections to tomcat. This configuration allowed us to handle the desired load. We test with 1000 virtual users, which maps to about 2000 real users for our tests. We could handle the load but the log files filled with error messages, apparently to JK2 its an error when tomcat closes the connection on its end. The test also had a couple hundred errors after about 1 page views. To implement this functionality I modified the jk_mutex_thread.c module to include a wait and a notify method (using the apr_thread_cond routines). I then modified the ajp13 worker to wait (forever) when the max_endpoints are reached. I also modified the jk2_worker_ajp13_done method to notify when an endpoint was returned to the cache. After load testing the resulting code, after close to 11000 page views we had 0 errors and response times remained at about .2 seconds (no slower than jk2 without my mods). I didnt add a wait timeout because I didnt feel in our case that an error should be returned to the client. But perhaps the option to specify a timeout could be useful to someone else. Comments? -sean CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25015] - CoyoteAdapter is breaking path info
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=25015. 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=25015 CoyoteAdapter is breaking path info --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 17:43 --- Remy, Is the way tomcat is now spec complient? According to the spec PathInfo: The part of the request path that is not part of the Context Path or the Servlet Path. It is either null if there is no extra path, or is a string with a leading ‘/’. so clearly if my url was http://localhost/appname/servletname/extra;a/path;b/info;c then if /appname is my context and /servletname is my servlet path then /extra;a/path;b/info;c should be my path info according to the spec (see SRV.4.4 and table 2) so if I submit a patch for this would you except this behavior? John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [JK2 Enhancement] modify behavior when max_endpoints have been reached
From: Scott, Sean I have locally modified the head revision of the jk2 project and would like some feedback before submitting the enhancements for review. The change in behavior that we desired was that rather than returning an error when the max_connections for the endpoint cache were reached, the worker would wait for an endpoint to be returned to the cache. To implement this functionality I modified the jk_mutex_thread.c module to include a wait and a notify method (using the apr_thread_cond routines). I then modified the ajp13 worker to wait (forever) when the max_endpoints are reached. I also modified the jk2_worker_ajp13_done method to notify when an endpoint was returned to the cache. -1 on mutex/wait approach. Using that we would reinvent the wheel. There is an excellent API in the APR-UTILS that will allow us to do a non-blocking approach. Take a look at apr_reslist API. Since we agreed to use the apr _and_ apr_util as mandatory, take a look at those. The reslist is meant to be used for such purposes. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25015] - CoyoteAdapter is breaking path info
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=25015. 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=25015 CoyoteAdapter is breaking path info --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 17:56 --- I say no. What if there are path parameters elsewhere ? You remove them ? It doesn't make any sense. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [JK2 Enhancement] modify behavior when max_endpoints have bee n reached
From: Scott, Sean I have locally modified the head revision of the jk2 project and would like some feedback before submitting the enhancements for review. The change in behavior that we desired was that rather than returning an error when the max_connections for the endpoint cache were reached, the worker would wait for an endpoint to be returned to the cache. To implement this functionality I modified the jk_mutex_thread.c module to include a wait and a notify method (using the apr_thread_cond routines). I then modified the ajp13 worker to wait (forever) when the max_endpoints are reached. I also modified the jk2_worker_ajp13_done method to notify when an endpoint was returned to the cache. -1 on mutex/wait approach. Using that we would reinvent the wheel. There is an excellent API in the APR-UTILS that will allow us to do a non-blocking approach. Take a look at apr_reslist API. Since we agreed to use the apr _and_ apr_util as mandatory, take a Being fairly new to this list... does this mean that you plan on doing away with the jk wrappers? Is apr fair game in any module? look at those. The reslist is meant to be used for such purposes. MT. These methods do in fact do the functionality that I require, however it doesnt appear that it is possible to achieve the current behavior which is to error out when the max_connections have been reached. However, I dont think returning an error is desirable behavior anyway. CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25015] - CoyoteAdapter is breaking path info
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=25015. 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=25015 CoyoteAdapter is breaking path info --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 18:04 --- I dont know how path parms are used normaly (personaly I have never seen them used except in our app) so I am not sure how they should be treated, but following the spec it seems the should be included in path info. I would like to get some feedback from others (hopefuly someone else out there uses them) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25015] - CoyoteAdapter is breaking path info
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=25015. 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=25015 CoyoteAdapter is breaking path info --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 18:23 --- getRequestURI will return the full URI, right (including all the parameters) ? I think if you need them, it is more consistent to work from that. Since parameters will need to be stripped out for mapping (you find the path info only after the mapping is done, so you can't (= hard) add back the parameters reliably), I don't see how it can be made to work automagically. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25015] - CoyoteAdapter is breaking path info
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=25015. 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=25015 CoyoteAdapter is breaking path info --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 18:26 --- Well the biggest problem right now is http://localhost/appname/servletname/extra;a/path;b/info;c then if /appname is my context and /servletname is my servlet path right now tomcat returns only /extra which is not right no matter how you look at it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any clue on this, please? Uploading large files - out of memory
Hi, any comment on this out of memory with large file upload? This error seems recurring to a bunch of users, but I'm wondering if it's a problem in the tomcat implementation, or if there are other layers to blame. Thanks for any light on this darkness, since I've a tight schedule on this issue... unfortunately.. cheers, fabrizio -- Forwarded message -- Date: Mon, 1 Dec 2003 14:36:57 +0100 (MET) From: Fabrizio Nesti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Uploading large files - out of memory exception Dear tomcat developers, I've noticed a problem while uploading files with tomcat 4.1.x. - When uploading large files (say larger than 10MB) tomcat throws an out of memory exception. - The problem can be avoided raising the memory allocation (as found in other similar messages, -Xms128m -Xmx512m) but this is not a solution, since it depends on the memory and just makes the limit higher. I do not know how the actual download works (we are using the EchoPoint fileupload component, for that matters) but it seems that the whole file is slurped in memory _before_ passing the request to a user servlet. Indeed it seems that our download component is never invoked (see the error below). Is there a configuration option to avoid this behavior, or there's nothing to do but limit the filesize? Thanks in advance for any clue and cheers, Fabrizio PS: The error: ... description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1040) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1151) at java.lang.Thread.run(Thread.java:536) root cause java.lang.OutOfMemoryError - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Any clue on this, please? Uploading large files - out of memory
Howdy, This belongs on the user, not dev, list. It's most likely a simple issue (not a bug) with you not allocating enough memory to the JVM. Please pursue this issue on the user list. Yoav Shapira Millennium ChemInformatics -Original Message- From: Fabrizio Nesti [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Any clue on this, please? Uploading large files - out of memory Hi, any comment on this out of memory with large file upload? This error seems recurring to a bunch of users, but I'm wondering if it's a problem in the tomcat implementation, or if there are other layers to blame. Thanks for any light on this darkness, since I've a tight schedule on this issue... unfortunately.. cheers, fabrizio -- Forwarded message -- Date: Mon, 1 Dec 2003 14:36:57 +0100 (MET) From: Fabrizio Nesti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Uploading large files - out of memory exception Dear tomcat developers, I've noticed a problem while uploading files with tomcat 4.1.x. - When uploading large files (say larger than 10MB) tomcat throws an out of memory exception. - The problem can be avoided raising the memory allocation (as found in other similar messages, -Xms128m -Xmx512m) but this is not a solution, since it depends on the memory and just makes the limit higher. I do not know how the actual download works (we are using the EchoPoint fileupload component, for that matters) but it seems that the whole file is slurped in memory _before_ passing the request to a user servlet. Indeed it seems that our download component is never invoked (see the error below). Is there a configuration option to avoid this behavior, or there's nothing to do but limit the filesize? Thanks in advance for any clue and cheers, Fabrizio PS: The error: ... description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic atio nFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil terC hain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal ve.j ava:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal ve.j ava:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24 17) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a:18 0) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV alve .java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav a:17 2) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:57 7) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve .jav a:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor. java :1040) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java :115 1) at java.lang.Thread.run(Thread.java:536) root cause java.lang.OutOfMemoryError - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any clue on this, please? Uploading large files - out of memory
Please followup to tomcat user. 1) Make sure that the app is using ServletRequest.getInputStream() 2) See the spec: 'SRV.4.1.1 When Parameters Are Available' -Tim Fabrizio Nesti wrote: Hi, any comment on this out of memory with large file upload? This error seems recurring to a bunch of users, but I'm wondering if it's a problem in the tomcat implementation, or if there are other layers to blame. Thanks for any light on this darkness, since I've a tight schedule on this issue... unfortunately.. cheers, fabrizio -- Forwarded message -- Date: Mon, 1 Dec 2003 14:36:57 +0100 (MET) From: Fabrizio Nesti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Uploading large files - out of memory exception Dear tomcat developers, I've noticed a problem while uploading files with tomcat 4.1.x. - When uploading large files (say larger than 10MB) tomcat throws an out of memory exception. - The problem can be avoided raising the memory allocation (as found in other similar messages, -Xms128m -Xmx512m) but this is not a solution, since it depends on the memory and just makes the limit higher. I do not know how the actual download works (we are using the EchoPoint fileupload component, for that matters) but it seems that the whole file is slurped in memory _before_ passing the request to a user servlet. Indeed it seems that our download component is never invoked (see the error below). Is there a configuration option to avoid this behavior, or there's nothing to do but limit the filesize? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [JK2 Enhancement] modify behavior when max_endpoints have been reached
-Original Message- From: Scott, Sean -1 on mutex/wait approach. Using that we would reinvent the wheel. There is an excellent API in the APR-UTILS that will allow us to do a non-blocking approach. Take a look at apr_reslist API. Since we agreed to use the apr _and_ apr_util as mandatory, take a Being fairly new to this list... does this mean that you plan on doing away with the jk wrappers? Is apr fair game in any module? Seems that I miss you here... look at those. The reslist is meant to be used for such purposes. MT. These methods do in fact do the functionality that I require, however it doesnt appear that it is possible to achieve the current behavior which is to error out when the max_connections have been reached. However, I dont think returning an error is desirable behavior anyway. That true. Unfortunately the reslist doesn't have the acquire timeout. That is the reason that I didn't try to implement that by myself. There is apr_queue api that has the trypop call returning APR_EAGAIN if there is no free entries. The only drawback is that this is static list giving the fixed number of connections. What we want is the initial number of connections with the peek limit, and that is what apr_reslist provides. If we persuade the apr guys to add the timeout option to apr_reslist, it would satisfy all our needs. I have a pending apr patch that resolves that issue, so hopefully this will get committed. If that doesn't pass (knowing how fast the guys are :-), we can simply duplicate the apr_reslist code using apr_thread_cond_timedwait with configurable timeout, where the value of zero would immediately return the server_busy. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any clue on this, please? Uploading large files - out of memory
I've heard mention on this list many times of these OutOfMemoryErrors not being bugs. I work on a Java app that experiences very high network traffic load, however, and it's been my experience that OutOfMemoryErrors are, in fact, always bugs regardless of how tempting it is to chalk it up to something else. What makes everyone so certain it's not a bug or multiple bugs? Since you don't get stack traces and at best can pin down the thread name for OutOfMemoryErrors, they take a lot of time to track down. In my experience, though, they tend to result from an unaccounted for degenerate request coming that causes the code to, well, consume all the available memory (i.e., a bug). -Adam Shapira, Yoav wrote: Howdy, This belongs on the user, not dev, list. It's most likely a simple issue (not a bug) with you not allocating enough memory to the JVM. Please pursue this issue on the user list. Yoav Shapira Millennium ChemInformatics -Original Message- From: Fabrizio Nesti [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Any clue on this, please? Uploading large files - out of memory Hi, any comment on this out of memory with large file upload? This error seems recurring to a bunch of users, but I'm wondering if it's a problem in the tomcat implementation, or if there are other layers to blame. Thanks for any light on this darkness, since I've a tight schedule on this issue... unfortunately.. cheers, fabrizio -- Forwarded message -- Date: Mon, 1 Dec 2003 14:36:57 +0100 (MET) From: Fabrizio Nesti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Uploading large files - out of memory exception Dear tomcat developers, I've noticed a problem while uploading files with tomcat 4.1.x. - When uploading large files (say larger than 10MB) tomcat throws an out of memory exception. - The problem can be avoided raising the memory allocation (as found in other similar messages, -Xms128m -Xmx512m) but this is not a solution, since it depends on the memory and just makes the limit higher. I do not know how the actual download works (we are using the EchoPoint fileupload component, for that matters) but it seems that the whole file is slurped in memory _before_ passing the request to a user servlet. Indeed it seems that our download component is never invoked (see the error below). Is there a configuration option to avoid this behavior, or there's nothing to do but limit the filesize? Thanks in advance for any clue and cheers, Fabrizio PS: The error: ... description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic atio nFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil terC hain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal ve.j ava:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal ve.j ava:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24 17) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a:18 0) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV alve .java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav a:17 2) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:57 7) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve .jav a:174) at
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardServer.java
amyroh 2003/12/03 10:53:15
Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
Log:
Fix bugzilla 25138 submitted by Takashi Okamoto [EMAIL PROTECTED].
Revision ChangesPath
1.23 +10 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java
Index: StandardServer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- StandardServer.java 2 Sep 2003 21:22:04 - 1.22
+++ StandardServer.java 3 Dec 2003 18:53:15 - 1.23
@@ -863,7 +863,7 @@
// Open an output writer for the new configuration file
PrintWriter writer = null;
try {
-writer = new PrintWriter(new FileWriter(config));
+writer = new PrintWriter(new OutputStreamWriter(new
FileOutputStream(config), UTF8));
} catch (IOException e) {
if (writer != null) {
try {
@@ -874,7 +874,8 @@
}
throw (e);
}
-
+
+writer.println(?xml version='1.0' encoding='utf-8'?);
writer.print(Context);
storeAttributes(writer, context);
writer.println();
@@ -1202,7 +1203,7 @@
// Open an output writer for the new configuration file
writer = null;
try {
-writer = new PrintWriter(new FileWriter(config));
+writer = new PrintWriter(new OutputStreamWriter(new
FileOutputStream(config), UTF8));
} catch (IOException e) {
if (writer != null) {
try {
@@ -1214,6 +1215,7 @@
throw (e);
}
+writer.println(?xml version='1.0' encoding='utf-8'?);
indent = 0;
}
@@ -1222,6 +1224,7 @@
for (int i = 0; i indent; i++) {
writer.print(' ');
}
+
writer.print(Context);
storeAttributes(writer, context);
writer.println();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25138] - [PATCH] Can't store web application context with admintool.
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=25138. 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=25138 [PATCH] Can't store web application context with admintool. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 18:54 --- The patch is applied. Thanks for the report and patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [JK2 Enhancement] modify behavior when max_endpoints have bee n reached
-Original Message- From: Scott, Sean -1 on mutex/wait approach. Using that we would reinvent the wheel. There is an excellent API in the APR-UTILS that will allow us to do a non-blocking approach. Take a look at apr_reslist API. Since we agreed to use the apr _and_ apr_util as mandatory, take a Being fairly new to this list... does this mean that you plan on doing away with the jk wrappers? Is apr fair game in any module? Seems that I miss you here... Meaning that the endpoint cache would no longer be a jk_objCache but be an apr reslist instead. look at those. The reslist is meant to be used for such purposes. MT. These methods do in fact do the functionality that I require, however it doesnt appear that it is possible to achieve the current behavior which is to error out when the max_connections have been reached. However, I dont think returning an error is desirable behavior anyway. That true. Unfortunately the reslist doesn't have the acquire timeout. That is the reason that I didn't try to implement that by myself. There is apr_queue api that has the trypop call returning APR_EAGAIN if there is no free entries. The only drawback is that this is static list giving the fixed number of connections. What we want is the initial number of connections with the peek limit, and that is what apr_reslist provides. If we persuade the apr guys to add the timeout option to apr_reslist, it would satisfy all our needs. I have a pending apr patch that resolves that issue, so hopefully this will get committed. If that doesn't pass (knowing how fast the guys are :-), we can simply duplicate the apr_reslist code using apr_thread_cond_timedwait with configurable timeout, where the value of zero would immediately return the server_busy. MT. Personally I dont see a problem with waiting for the next endpoint to be returned. CONFIDENTIALITY NOTICE - This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving in any manner. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any clue on this, please? Uploading large files - out of memory
Indeed I am not 100% sure of the real cause of the OOME below. However, as far as my request is concerned, it seems that the upload component that we use (Echopoint's one, quite cool) _could_ (and should) have used an InputStream. So this is enough for me to go bother them and no longer the tomcat-dev :). I was thinking that tomcat was the critical point, so I wrote here just to be sure. In case you need further testing please let me know, for the rest it's up to you tomcat developers... and... thanks for your good work. cheers, Fabrizio On Wed, 3 Dec 2003, Adam Fisk wrote: I've heard mention on this list many times of these OutOfMemoryErrors not being bugs. I work on a Java app that experiences very high network traffic load, however, and it's been my experience that OutOfMemoryErrors are, in fact, always bugs regardless of how tempting it is to chalk it up to something else. What makes everyone so certain it's not a bug or multiple bugs? Since you don't get stack traces and at best can pin down the thread name for OutOfMemoryErrors, they take a lot of time to track down. In my experience, though, they tend to result from an unaccounted for degenerate request coming that causes the code to, well, consume all the available memory (i.e., a bug). -Adam Shapira, Yoav wrote: Howdy, This belongs on the user, not dev, list. It's most likely a simple issue (not a bug) with you not allocating enough memory to the JVM. Please pursue this issue on the user list. Yoav Shapira Millennium ChemInformatics -Original Message- From: Fabrizio Nesti [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Any clue on this, please? Uploading large files - out of memory Hi, any comment on this out of memory with large file upload? This error seems recurring to a bunch of users, but I'm wondering if it's a problem in the tomcat implementation, or if there are other layers to blame. Thanks for any light on this darkness, since I've a tight schedule on this issue... unfortunately.. cheers, fabrizio -- Forwarded message -- Date: Mon, 1 Dec 2003 14:36:57 +0100 (MET) From: Fabrizio Nesti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Uploading large files - out of memory exception Dear tomcat developers, I've noticed a problem while uploading files with tomcat 4.1.x. - When uploading large files (say larger than 10MB) tomcat throws an out of memory exception. - The problem can be avoided raising the memory allocation (as found in other similar messages, -Xms128m -Xmx512m) but this is not a solution, since it depends on the memory and just makes the limit higher. I do not know how the actual download works (we are using the EchoPoint fileupload component, for that matters) but it seems that the whole file is slurped in memory _before_ passing the request to a user servlet. Indeed it seems that our download component is never invoked (see the error below). Is there a configuration option to avoid this behavior, or there's nothing to do but limit the filesize? Thanks in advance for any clue and cheers, Fabrizio PS: The error: ... description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applic atio nFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFil terC hain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVal ve.j ava:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal ve.j ava:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java: 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:24 17) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.jav a:18 0) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext. invo keNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherV alve .java:171) at
Re: [VOTE] 5.0.16
Note: 5.0.16 is almost identical to 5.0.15, but please test it anyway for regressions. ballot Release 5.0.16 as Stable ? [X] Yes [ ] No /ballot Amy As usual, if there's either a serious problem or a regression over previous builds, there will be a new build. Rémy - 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]
RE: Any clue on this, please? Uploading large files - out of memory
Howdy, I would throw out one more piece of advice: consider jakarta commons fileupload component. It is well-designed with respect to handling large files. As to the OutOfMemoryErrors are, in fact, always bugs claim -- well, that's the most amusing thing I've heard today ;) If they are bugs, find the buggy code. Yoav Shapira Millennium ChemInformatics -Original Message- From: Fabrizio Nesti [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 2:01 PM To: Tomcat Developers List Subject: Re: Any clue on this, please? Uploading large files - out of memory Indeed I am not 100% sure of the real cause of the OOME below. However, as far as my request is concerned, it seems that the upload component that we use (Echopoint's one, quite cool) _could_ (and should) have used an InputStream. So this is enough for me to go bother them and no longer the tomcat-dev :). I was thinking that tomcat was the critical point, so I wrote here just to be sure. In case you need further testing please let me know, for the rest it's up to you tomcat developers... and... thanks for your good work. cheers, Fabrizio On Wed, 3 Dec 2003, Adam Fisk wrote: I've heard mention on this list many times of these OutOfMemoryErrors not being bugs. I work on a Java app that experiences very high network traffic load, however, and it's been my experience that OutOfMemoryErrors are, in fact, always bugs regardless of how tempting it is to chalk it up to something else. What makes everyone so certain it's not a bug or multiple bugs? Since you don't get stack traces and at best can pin down the thread name for OutOfMemoryErrors, they take a lot of time to track down. In my experience, though, they tend to result from an unaccounted for degenerate request coming that causes the code to, well, consume all the available memory (i.e., a bug). -Adam Shapira, Yoav wrote: Howdy, This belongs on the user, not dev, list. It's most likely a simple issue (not a bug) with you not allocating enough memory to the JVM. Please pursue this issue on the user list. Yoav Shapira Millennium ChemInformatics -Original Message- From: Fabrizio Nesti [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Any clue on this, please? Uploading large files - out of memory Hi, any comment on this out of memory with large file upload? This error seems recurring to a bunch of users, but I'm wondering if it's a problem in the tomcat implementation, or if there are other layers to blame. Thanks for any light on this darkness, since I've a tight schedule on this issue... unfortunately.. cheers, fabrizio -- Forwarded message -- Date: Mon, 1 Dec 2003 14:36:57 +0100 (MET) From: Fabrizio Nesti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Uploading large files - out of memory exception Dear tomcat developers, I've noticed a problem while uploading files with tomcat 4.1.x. - When uploading large files (say larger than 10MB) tomcat throws an out of memory exception. - The problem can be avoided raising the memory allocation (as found in other similar messages, -Xms128m -Xmx512m) but this is not a solution, since it depends on the memory and just makes the limit higher. I do not know how the actual download works (we are using the EchoPoint fileupload component, for that matters) but it seems that the whole file is slurped in memory _before_ passing the request to a user servlet. Indeed it seems that our download component is never invoked (see the error below). Is there a configuration option to avoid this behavior, or there's nothing to do but limit the filesize? Thanks in advance for any clue and cheers, Fabrizio PS: The error: ... description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli c atio nFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi l terC hain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa l ve.j ava:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext . invo keNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java : 480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa l ve.j ava:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext . invo keNext(StandardPipeline.java:643) at
RE: [JK2 Enhancement] modify behavior when max_endpoints have been reached
From: Scott, Sean Seems that I miss you here... Meaning that the endpoint cache would no longer be a jk_objCache but be an apr reslist instead. Exactly! Personally I dont see a problem with waiting for the next endpoint to be returned. Theoretically the connection could reach the response timeout before the jk2 connection becomes available. So in any case the endpoint timeout has to be less then the connection timeout. Also its better to present the 'server busy' to the user then to enter in some endless loop. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any clue on this, please? Uploading large files - out of memory
I unfortunately don't have the time to step through each and every thread where these errors are occuring, although I wish I did. The question is, has someone done this? It's about the most tedious coding process I know of, so it just wouldn't surprise me if no one's actually done it. Do you know what threads these errors occur in? If so, do you know when they occur? Can you reproduce them? Clearly there are legitimate OOMEs, there just much rarer than the illegitimate ones. It's the legitimacy or illegitimacy that's tough to determine. I'm sure this process has happened, but then again, maybe not. -Adam Shapira, Yoav wrote: Howdy, I would throw out one more piece of advice: consider jakarta commons fileupload component. It is well-designed with respect to handling large files. As to the OutOfMemoryErrors are, in fact, always bugs claim -- well, that's the most amusing thing I've heard today ;) If they are bugs, find the buggy code. Yoav Shapira Millennium ChemInformatics -Original Message- From: Fabrizio Nesti [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 2:01 PM To: Tomcat Developers List Subject: Re: Any clue on this, please? Uploading large files - out of memory Indeed I am not 100% sure of the real cause of the OOME below. However, as far as my request is concerned, it seems that the upload component that we use (Echopoint's one, quite cool) _could_ (and should) have used an InputStream. So this is enough for me to go bother them and no longer the tomcat-dev :). I was thinking that tomcat was the critical point, so I wrote here just to be sure. In case you need further testing please let me know, for the rest it's up to you tomcat developers... and... thanks for your good work. cheers, Fabrizio On Wed, 3 Dec 2003, Adam Fisk wrote: I've heard mention on this list many times of these OutOfMemoryErrors not being bugs. I work on a Java app that experiences very high network traffic load, however, and it's been my experience that OutOfMemoryErrors are, in fact, always bugs regardless of how tempting it is to chalk it up to something else. What makes everyone so certain it's not a bug or multiple bugs? Since you don't get stack traces and at best can pin down the thread name for OutOfMemoryErrors, they take a lot of time to track down. In my experience, though, they tend to result from an unaccounted for degenerate request coming that causes the code to, well, consume all the available memory (i.e., a bug). -Adam Shapira, Yoav wrote: Howdy, This belongs on the user, not dev, list. It's most likely a simple issue (not a bug) with you not allocating enough memory to the JVM. Please pursue this issue on the user list. Yoav Shapira Millennium ChemInformatics -Original Message- From: Fabrizio Nesti [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Any clue on this, please? Uploading large files - out of memory Hi, any comment on this out of memory with large file upload? This error seems recurring to a bunch of users, but I'm wondering if it's a problem in the tomcat implementation, or if there are other layers to blame. Thanks for any light on this darkness, since I've a tight schedule on this issue... unfortunately.. cheers, fabrizio -- Forwarded message -- Date: Mon, 1 Dec 2003 14:36:57 +0100 (MET) From: Fabrizio Nesti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Uploading large files - out of memory exception Dear tomcat developers, I've noticed a problem while uploading files with tomcat 4.1.x. - When uploading large files (say larger than 10MB) tomcat throws an out of memory exception. - The problem can be avoided raising the memory allocation (as found in other similar messages, -Xms128m -Xmx512m) but this is not a solution, since it depends on the memory and just makes the limit higher. I do not know how the actual download works (we are using the EchoPoint fileupload component, for that matters) but it seems that the whole file is slurped in memory _before_ passing the request to a user servlet. Indeed it seems that our download component is never invoked (see the error below). Is there a configuration option to avoid this behavior, or there's nothing to do but limit the filesize? Thanks in advance for any clue and cheers, Fabrizio PS: The error: ... description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli c atio nFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi l terC hain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa l ve.j ava:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext
DO NOT REPLY [Bug 25178] New: - JspC does not always handle conversion of page import tag correctly
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=25178. 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=25178 JspC does not always handle conversion of page import tag correctly Summary: JspC does not always handle conversion of page import tag correctly Product: Tomcat 4 Version: Unknown Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Given a JSP page with a tag that looks like this: %@ page import= com.a.b.c.*, com.a.b.c.D, java.util.*, java.lang.*; % The generated java page ends up with this import statement import com.a.b.c.*; import com.a.b.c.D; import java.util.*; import java.lang.*; ; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.jsp.*; import org.apache.jasper.runtime.*; It looks like the carriage-return line feeds get passed through. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25178] - JspC does not always handle conversion of page import tag correctly
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=25178. 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=25178 JspC does not always handle conversion of page import tag correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 19:57 --- It should be a comma seperated list. Not semi-colon terminated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Any clue on this, please? Uploading large files - out of memory
Or, configuration. Consider what I ran into the last few weeks. We were doing very high load testing of Tomcat and getting the dreaded OutOfMemory error simply hitting the Tomcat examples. I immediately thought this to be bug as well. Well, after using OptimizeIt on the code, I found out that the culprit is that we were creating so many sessions that we used up all of the memory before we hit the session timeout. This is a tuning problem, not a bug. I could 1) Throw more memory at Tomcat (we had -Xmx256m) 2) Decrease the session timeout. The default is good in most cases of not-so-extreme traffic 3) Ponder on whether load testing 500-600 req/s, with each request being a completely new session is a valid test scenario. (Sometime it is: Think getting slash-dotted) I also think that a lot of the more bizarre OOM errors being reported on the user list currently, when reloading contexts for instance, have to do with the newer GC model of new/old/permanent generation divisions - the permanent generation is filling even though old and new have room to spare. This is also tuning. (Well, the user did say that Sun is doing a fix for that, so I guess it could be either) That all said, OptimizeIt is well worth the money spent. It vastly decreased the amount of time spent tracking down my OOM error. (After 3 or so days of staring at heap dumps, we just got OptimizeIt, and found the problem almost immediately). On Wed, 3 Dec 2003, Adam Fisk wrote: I've heard mention on this list many times of these OutOfMemoryErrors not being bugs. I work on a Java app that experiences very high network traffic load, however, and it's been my experience that OutOfMemoryErrors are, in fact, always bugs regardless of how tempting it is to chalk it up to something else. What makes everyone so certain it's not a bug or multiple bugs? Since you don't get stack traces and at best can pin down the thread name for OutOfMemoryErrors, they take a lot of time to track down. In my experience, though, they tend to result from an unaccounted for degenerate request coming that causes the code to, well, consume all the available memory (i.e., a bug). -Adam Shapira, Yoav wrote: Howdy, This belongs on the user, not dev, list. It's most likely a simple issue (not a bug) with you not allocating enough memory to the JVM. Please pursue this issue on the user list. Yoav Shapira Millennium ChemInformatics Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25178] - JspC does not always handle conversion of page import tag correctly
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=25178. 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=25178 JspC does not always handle conversion of page import tag correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 21:13 --- I removed the semi-colon at the end and repeated the test. The same result happens, except that the last import doesn't have a semi-colon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs index.xml
remm2003/12/03 13:39:33 Modified:docs index.html xdocsindex.xml Log: - Update index page. Revision ChangesPath 1.54 +4 -5 jakarta-tomcat-site/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- index.html25 Nov 2003 13:57:22 - 1.53 +++ index.html3 Dec 2003 21:39:33 - 1.54 @@ -173,7 +173,7 @@ /td td bgcolor=#a0ddf0 colspan= rowspan= valign=top align=left font color=#00 size=-1 face=arial,helvetica,sanserif -5.0.14 Beta +5.0.16 /font /td /tr @@ -213,7 +213,7 @@ /td/tr trtd blockquote -pstrongTomcat 5.x/strong is the upcoming major release of Tomcat, and +pstrongTomcat 5.x/strong is the current release of Tomcat, and builds upon the Tomcat 3.3 and Tomcat 4.1 codebases. The 5.x releases implement the strongServlet 2.4/strong and strongJSP 2.0/strong specifications./p @@ -250,9 +250,8 @@ Catalina) that is based on completely new architecture. The 4.x releases implement the strongServlet 2.3/strong and strongJSP 1.2/strong specifications./p -pstrongTomcat 4.1.x/strong. Tomcat 4.1, whose latest stable release -is listed above, is a refactoring of Tomcat 4.0.x, and contains significant -enhancements, including: +pstrongTomcat 4.1.x/strong. Tomcat 4.1 is a refactoring +of Tomcat 4.0.x, and contains significant enhancements, including: ul liJMX based administration features/li liJSP and Struts based administration web application/li 1.44 +4 -5 jakarta-tomcat-site/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-site/xdocs/index.xml,v retrieving revision 1.43 retrieving revision 1.44 diff -u -r1.43 -r1.44 --- index.xml 25 Nov 2003 13:56:10 - 1.43 +++ index.xml 3 Dec 2003 21:39:33 - 1.44 @@ -40,7 +40,7 @@ tr td2.4/2.0/td - td5.0.14 Beta/td + td5.0.16/td /tr tr @@ -61,7 +61,7 @@ subsection name=Tomcat 5.x -pstrongTomcat 5.x/strong is the upcoming major release of Tomcat, and +pstrongTomcat 5.x/strong is the current release of Tomcat, and builds upon the Tomcat 3.3 and Tomcat 4.1 codebases. The 5.x releases implement the strongServlet 2.4/strong and strongJSP 2.0/strong specifications./p @@ -93,9 +93,8 @@ implement the strongServlet 2.3/strong and strongJSP 1.2/strong specifications./p -pstrongTomcat 4.1.x/strong. Tomcat 4.1, whose latest stable release -is listed above, is a refactoring of Tomcat 4.0.x, and contains significant -enhancements, including: +pstrongTomcat 4.1.x/strong. Tomcat 4.1 is a refactoring +of Tomcat 4.0.x, and contains significant enhancements, including: ul liJMX based administration features/li liJSP and Struts based administration web application/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25178] - JspC does not always handle conversion of page import tag correctly
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=25178. 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=25178 JspC does not always handle conversion of page import tag correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-03 22:24 --- And how is this a bug? I believe javac would happily take the CR/LF after import without complain. The recommanded practice is to have a separate page directive for each import. You should be happy that Tomcat allow you to specify imports in a comma-separated list; other containers don't do this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/xdocs-faq version.xml
funkman 2003/12/03 15:41:03
Modified:docs/faq version.html
docs/faq/printer version.html
xdocs-faq version.xml
Log:
Update the FAQ that tomcat 5 is not alpha
Revision ChangesPath
1.8 +76 -76jakarta-tomcat-site/docs/faq/version.html
Index: version.html
===
RCS file: /home/cvs/jakarta-tomcat-site/docs/faq/version.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- version.html 26 Aug 2003 09:08:17 - 1.7
+++ version.html 3 Dec 2003 23:41:03 - 1.8
@@ -1,77 +1,77 @@
-htmlheadMETA http-equiv=Content-Type content=text/html;
charset=iso-8859-1titleTomcat FAQ - Which Version/titlemeta value=Tim Funk
name=authormeta value=[EMAIL PROTECTED] name=emailstyle
- dt { font-size : larger; font-weight : bold }
- dd {padding-bottom : 10px;}
-/style/headbody vlink=#525D76 alink=#525D76 link=#525D76
text=#00 bgcolor=#fftable cellspacing=4 width=100%
border=0!--PAGE HEADER--trtd colspan=2!--JAKARTA LOGO--a
href=http://jakarta.apache.org/;img border=0 alt=The Jakarta Project
align=left src=http://jakarta.apache.org//images/jakarta-logo.gif;/a!--PROJECT
LOGO--a href=http://jakarta.apache.org/tomcat/;img border=0 alt=
- Tomcat FAQ
- align=right src=../images/tomcat.gif/a/td/tr!--HEADER
SEPARATOR--trtd colspan=2hr size=1 noshade=/td/trtr!--LEFT SIDE
NAVIGATION--td nowrap=true valign=top
width=20%pstrongLinks/strong/pullia href=..Tomcat
Home/a/lilia href=index.htmlFAQ
Home/a/li/ulpstrongContents/strong/pullia
href=bugs.htmlBugs/a/lilia href=classnotfound.htmlClass Not
Found/a/lilia href=connectors.htmlConnectors/a/lilia
href=database.htmlDatabase/a/lilia
href=http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat/Howto;How do
I/a/lilia href=unix.htmlLinux / Unix/a/lilia
href=memory.htmlMemory/a/lilia href=meta.htmlMeta/a/lilia
href=misc.htmlMiscellaneous/a/lilia href=performance.htmlMonitoring /
Performance/a/lilia
href=http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat/Links;Other
Resources/a/lilia href=security.htmlSecurity/a/lilia
href=version.htmlWhich Version/a/lilia href=tomcatuser.htmlTomcat User
List/a/lilia href=windows.htmlWindows/a/li/ul/td!--RIGHT SIDE MAIN
BODY--td align=left valign=top width=80%table cellspacing=4 width=100%
border=0trtd nowrap=true valign=top align=lefth1Tomcat
FAQ/h1h2Which Version/h2/tdtd nowrap=true valign=top
align=rightsmalla href=printer/version.htmlimg alt=Printer Friendly
Version border=0 src=../images/printer.gifbrprint-friendlybrversion
-/a/small/td/tr/tabletable cellpadding=2
cellspacing=0 border=0trtd bgcolor=#525D76font
face=arial,helvetica.sanserif color=#ffa
name=PrefacestrongPreface/strong/a/font/td/trtrtdblockquote
- p
-This page discusses the differences between the different Tomcat versions.
-If you
-want to know more about which connector to use, see the
-a href=connectors.htmlConnectors/a section.
- /p
-/blockquote/td/tr/tabletable cellpadding=2 cellspacing=0
border=0trtd bgcolor=#525D76font face=arial,helvetica.sanserif
color=#ffa
name=QuestionsstrongQuestions/strong/a/font/td/trtrtdblockquote
- ul
-
- li
- a href=#which
- Which Tomcat version should I use?
- /a
- /li
-
- li
- a href=#when
-When will the next version be released?
- /a
- /li
-
- /ul
-/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
-
-b style=font-size: larger
- a name=whichWhich Tomcat version should I use?/a
-/b
-div style=padding-left : 20px;
-It depends on the version of the
-a href=http://java.sun.com/products/servlet/;Servlet API/a you need.
-
-ul
- liTomcat 3 supports the 2.2 API/li
- liTomcat 4 supports the 2.3 API/li
- liTomcat 5 supports the 2.4 API/li
-/ul
-
- Tomcat 5 is alpha quality. It isn't ready for production.
-brbr
-
- There are 2 flavors of Tomcat 4: 4.0.X and 4.1.X. The 4.1.x version is
- still slowly receiving new enhancements but this
- trend is subsiding while more attention is paid to Tomcat5.
- Version 4.0.X is only receiving security fixes. Both (4.0 and 4.1)
- are suitable for production. (YMMV).
- Version 4.1.X is significantly faster than 4.0.X.
-brbr
-
- Tomcat 3 I know nothing about with respect to performance and
- maintenance. AFAIK - it
- is still receiving security fixes. The
- a href=http://jakarta.apache.org/tomcat/;
- Tomcat home page /a should have the correct recommendation.
-/divbr
-
-
-b style=font-size: larger
-
Jboss 3.2.2/Tomcat4.1 Cert authentication is not good enough.
Hi All, Jboss 3.2.2 comes default as Tomcat 4.1 web container whose Cert Authentication does not work as Jetty's. Let me elaborate my problem and then will write my Fix. After certificate authentication, the application writers will want to get more information about the user other than just the principal name. In order to do this we have a service which returns information about the user when passed the authenticated principal. This means than the principal name needs to be something sensible ( currently userID in Jetty and Weblogic setup ) To fix above problem, i have created a wrapper which creates a principal and changed its name without changing the Object hashcode. This works fine. I am happy to send the patch, let me know whom do i send it to? thanks Krishna The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender.
[ANN] Apache Tomcat 5.0.16 Stable released
The Tomcat Team announces the immediate availability of Apache Tomcat 5.0.16 Stable. Please refer to the changelog for the list of changes. Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi Sources: http://jakarta.apache.org/site/sourceindex.cgi The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
