Servlet Problems Uprgrading from Tomcat 3.2.x to Tomcat 4.1.18
I am a newbie at Tomcat and Java so please forgive me if I am about to ask some stupid question that everyone should no when working in this environment. Our customer has asked me to upgrade their Tomcat installation from 3.2.4 to 4.1.18. This environment is on Windows 2000. I first installed Tomcat 4.1.18, from binary, and made my necessary changes in server.xml and web.xml for the new system to see the servlet directory and classes. The default home page comes up just fine but when I use the test page to hit the class I get the following error: Error executing remote method java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.net.MalformedURLException: no protocol: Files/Apache/Tomcat This class uses RMI to call a listener to complete the process. I am using Sun's Java SDK 1.4.1. I have recompiled the classes with the libraries pointing to the $CATALINA_HOME\common\lib so it knows about the new activation.jar and servlet.jar. I also set the classpath in the runtime of the background listener program to use these same jar's (this application attaches to the RMI on the standard port) Here is my webapps web.xml file. I did not make any changes to this for the upgrade nor did I write it originally. ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app context-param param-nameceRmiUrl/param-name param-valuermi://localhost:1099/communicationengine.httpmodule.Receive r/param-value descriptionRMI URI that is used to post incoming messages to CE /description /context-param servlet servlet-name snoop /servlet-name servlet-class SnoopServlet /servlet-class !-- init-param param-namefoo/param-name param-valuebar/param-value /init-param -- /servlet servlet servlet-name servletToJsp /servlet-name servlet-class servletToJsp /servlet-class /servlet servlet servlet-nameHTTP Servlet/servlet-name servlet-classServletHttpPostReceiver/servlet-class init-param param-nameceRmiUrl/param-name param-valuermi://localhost:1099/communicationengine.httpmodule.Receive r/param-value /init-param /servlet servlet servlet-nameHTTPS Servlet/servlet-name servlet-classServletHttpSSLPostReceiver/servlet-class init-param param-nameceRmiUrl/param-name param-valuermi://localhost:1099/communicationengine.httpmodule.Receive r/param-value /init-param /servlet servlet-mapping servlet-name snoop /servlet-name url-pattern /snoop /url-pattern /servlet-mapping servlet-mapping servlet-name snoop /servlet-name url-pattern *.snp /url-pattern /servlet-mapping servlet-mapping servlet-name servletToJsp /servlet-name url-pattern /servletToJsp /url-pattern /servlet-mapping taglib taglib-uri http://java.apache.org/tomcat/examples-taglib /taglib-uri taglib-location /WEB-INF/jsp/example-taglib.tld /taglib-location /taglib security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/jsp/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint I appreciate any help or insight someone can give me into getting this
RE: Servlet Problems Uprgrading from Tomcat 3.2.x to Tomcat 4.1.18
Sorry, I found another person had asked this same question and my problem was the same. I had a space in the directory structure for the Tomcat installation. Matt -Original Message- From: Matt Frame [mailto:[EMAIL PROTECTED] Sent: Monday, February 24, 2003 2:33 PM To: 'Tomcat Users List' Subject: Servlet Problems Uprgrading from Tomcat 3.2.x to Tomcat 4.1.18 I am a newbie at Tomcat and Java so please forgive me if I am about to ask some stupid question that everyone should no when working in this environment. Our customer has asked me to upgrade their Tomcat installation from 3.2.4 to 4.1.18. This environment is on Windows 2000. I first installed Tomcat 4.1.18, from binary, and made my necessary changes in server.xml and web.xml for the new system to see the servlet directory and classes. The default home page comes up just fine but when I use the test page to hit the class I get the following error: Error executing remote method java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.net.MalformedURLException: no protocol: Files/Apache/Tomcat This class uses RMI to call a listener to complete the process. I am using Sun's Java SDK 1.4.1. I have recompiled the classes with the libraries pointing to the $CATALINA_HOME\common\lib so it knows about the new activation.jar and servlet.jar. I also set the classpath in the runtime of the background listener program to use these same jar's (this application attaches to the RMI on the standard port) Here is my webapps web.xml file. I did not make any changes to this for the upgrade nor did I write it originally. ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app context-param param-nameceRmiUrl/param-name param-valuermi://localhost:1099/communicationengine.httpmodule.Receive r/param-value descriptionRMI URI that is used to post incoming messages to CE /description /context-param servlet servlet-name snoop /servlet-name servlet-class SnoopServlet /servlet-class !-- init-param param-namefoo/param-name param-valuebar/param-value /init-param -- /servlet servlet servlet-name servletToJsp /servlet-name servlet-class servletToJsp /servlet-class /servlet servlet servlet-nameHTTP Servlet/servlet-name servlet-classServletHttpPostReceiver/servlet-class init-param param-nameceRmiUrl/param-name param-valuermi://localhost:1099/communicationengine.httpmodule.Receive r/param-value /init-param /servlet servlet servlet-nameHTTPS Servlet/servlet-name servlet-classServletHttpSSLPostReceiver/servlet-class init-param param-nameceRmiUrl/param-name param-valuermi://localhost:1099/communicationengine.httpmodule.Receive r/param-value /init-param /servlet servlet-mapping servlet-name snoop /servlet-name url-pattern /snoop /url-pattern /servlet-mapping servlet-mapping servlet-name snoop /servlet-name url-pattern *.snp /url-pattern /servlet-mapping servlet-mapping servlet-name servletToJsp /servlet-name url-pattern /servletToJsp /url-pattern /servlet-mapping taglib taglib-uri http://java.apache.org/tomcat/examples-taglib /taglib-uri taglib-location /WEB-INF/jsp/example-taglib.tld /taglib-location /taglib security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/jsp/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE
mod_jk Ajp13 and Tomcat 3.2.X
I am working on Tuning our Apache 2.0, mod_jk-2.0.42, Tomcat 3.2.3 on Win2K config In all I have read, I never have seen that you can set minProcessors, maxProcessors, and acceptCount in the Tomcat 3.2.3 server.xml like: Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp13ConnectionHandler/ Parameter name=port value=8009/ Parameter name=minProcessors value=10/ Parameter name=maxProcessors value=100/ Parameter name=acceptCount value=15/ /Connector I did that and the system degraded conciderably. If I remove them I do better, like this: Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp13ConnectionHandler/ Parameter name=port value=8009/ /Connector What do the minProcessors, maxProcessors, and acceptCount default to in this config? Can I use explictly set minProcessors, maxProcessors, and acceptCount in Tomcat 3.2.3? Guidelines? Chad -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Tomcat 3.2.x version differences
Hello. At http://jakarta.apache.org/tomcat/index.html, I was looking at the following: The 3.2.1 release, like 3.1.1, was a security patch. Version 3.2.2 fixed a large number of bugs and all known specification compliance issues. Version 3.2.3 was a security update that closes a serious security hole. Version 3.2.4 is a minor bug fix release. In a nutshell, 3.2.1 is not available at http://jakarta.apache.org/site/binindex.html 3.2.4 is. 1) Are the Windows binaries of 3.2.1 available somewhere? 2) Is there a document which spells out the differences between 3.2.1 and 3.2.4 ? Thank you, Michael = Michael Finney 719-572-1577 (H) Sun Certified Programmer for the Java 2 Platform Sun Certified Developer for the Java 2 Platform Sun Certified Web Component Developer for J2EE Platform Co-founder of PPJDG - http://www.ppjdg.org Co-founder of cosAgile - Colorado Springs XP Users Group - http://www.yahoogroups.com/group/cosAgile __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Possible problem: ajp13 on Tomcat 3.2.x - need help
We are using Apache 1.3.26 and Tomcat 3.2.2. We've seen some clients to be hanging Apache on SSL read. The cause of this hang seems to be network/TCP/IP issue. The read will eventually times out. When it times out, here's where the problem starts. Tomcat seems to be grabbing some buffer that contains partial data of the previous request and call a servlet with it. The servlet will throw an exception because the data is bad. Here are the details (you will need to pull up the code to see what I mean). When Apache read times out, mod_jk's jk_ajp13_worker.c::read_into_msg_buff() will return error. mod_jk will drop its connection to Tomcat and retry (up to JK_RETRIES times - see the service() function). In the retry, the HTTP header gets resent to Tomcat. When Tomcat receives this header, it will eventually call Ajp13ConnectorRequest::decodeRequest(). This method will attempt to read more data from mod_jk (the call to con.receive()). This call will fail because mod_jk has yet again drop the connection (in its 2nd retry to call read_into_msg_buff() fails). Since this call (con.receive()) fails, the attribute blen is never set to the content-length of this request. Instead, blen has the value of the content-length of the previous request. Because the call to con.receive() fails, the method decodeRequest() will return -1. The caller to decodeRequest, Ajp13ConnectionHandler::processConnection(), doesn't check the error code and it proceeds to call the servlet. The servlet will issue a read and it will eventually call Ajp13ConnectorRequest::doRead(). In doRead(), I dumped some values of the variables. pos is always 0. blen is some number. The problem happens when blen is less than the length of the buffer (variable len). The method will copy some data from bodyBuff, which is a left-over from previous request. Note, I checked the source code for Tomcat 3.2.4. It doesn't seem to be fixed yet. We may not have the luxury to upgrade to Tomcat 3.3 yet. So I am attempting to fix this, but I have a question: Why does Ajp13ConnectionHandler::processConnection() not check the error code from decodeRequest()? It seems to me like if it gets an error in decodeRequest(), it should not call the service() method which calls the servlet. thanks, shinta -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 3.2.x
I'm curious as to whether this problem is just me. I haven't seen any mention of anyone else running into this problem. However, what I'm experiencing (it doesn't happen in Tomcat 4.0.x), but I still need to get things working under Tomcat 3.2.x is: 1. deploy the war file 2. restart tomcat 3. attempt to run the application Where the problem lies is in the jar/zip files that are in the $TOMCAT_HOME/webapps/appname/WEB-INF/lib directory. Some don't get loaded at all, and others only get partially loaded. For the ones that only partially get loaded, even if I extract them into the classes directory, I still run into the same roadblock. This phenomenon occurs under both Tomcat 3.2.3 and Tomcat 3.2.1. I can move my jar/zip files into the system lib directory, but then my servlets are foobar; Tomcat won't find them anymore. Thanks in advance for any help or answers you might have. P.S. Any properties files I have won't get loaded from the WEB-INF/classes directory either...I have to put those into the $TOMCAT_HOME/classes directory. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.2.x
I use tomcat 3.2.4 and haven't noticed this problem. Not sure about the earlier versions of 3.2.x. Brandon -Original Message- From: Daniel Bruce Lynes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 11:13 AM To: [EMAIL PROTECTED] Subject: Tomcat 3.2.x I'm curious as to whether this problem is just me. I haven't seen any mention of anyone else running into this problem. However, what I'm experiencing (it doesn't happen in Tomcat 4.0.x), but I still need to get things working under Tomcat 3.2.x is: 1. deploy the war file 2. restart tomcat 3. attempt to run the application Where the problem lies is in the jar/zip files that are in the $TOMCAT_HOME/webapps/appname/WEB-INF/lib directory. Some don't get loaded at all, and others only get partially loaded. For the ones that only partially get loaded, even if I extract them into the classes directory, I still run into the same roadblock. This phenomenon occurs under both Tomcat 3.2.3 and Tomcat 3.2.1. I can move my jar/zip files into the system lib directory, but then my servlets are foobar; Tomcat won't find them anymore. Thanks in advance for any help or answers you might have. P.S. Any properties files I have won't get loaded from the WEB-INF/classes directory either...I have to put those into the $TOMCAT_HOME/classes directory. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.2.x
I was under the impression that you need to rename your zip files to jar files to get Tomcat 3.2 to load them. At least that's what I have noticed in using Tomcat 3.2 with JBuilder. Robert Nocera New England Open Solutions www.neosllc.com You supply the Vision. We will do the rest. -Original Message- From: Daniel Bruce Lynes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 12:13 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.2.x I'm curious as to whether this problem is just me. I haven't seen any mention of anyone else running into this problem. However, what I'm experiencing (it doesn't happen in Tomcat 4.0.x), but I still need to get things working under Tomcat 3.2.x is: 1. deploy the war file 2. restart tomcat 3. attempt to run the application Where the problem lies is in the jar/zip files that are in the $TOMCAT_HOME/webapps/appname/WEB-INF/lib directory. Some don't get loaded at all, and others only get partially loaded. For the ones that only partially get loaded, even if I extract them into the classes directory, I still run into the same roadblock. This phenomenon occurs under both Tomcat 3.2.3 and Tomcat 3.2.1. I can move my jar/zip files into the system lib directory, but then my servlets are foobar; Tomcat won't find them anymore. Thanks in advance for any help or answers you might have. P.S. Any properties files I have won't get loaded from the WEB-INF/classes directory either...I have to put those into the $TOMCAT_HOME/classes directory. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Caching Login Info in Tomcat 3.2.x
Hi, I would like Tomcat avoiding to access the DB for EVERY ACCESS to a reserved page. I think the best way to do this (apart from upgrading to Tomcat 4.0 !!) is to store the login info, or maybe just a flag I'm authenticated, in the session object. Does anyone already made something similar ? Should I only redefine methods in my Realm object ? Is there some security issue I'm not taking care of ?? Thanks Renato
Re: Caching Login Info in Tomcat 3.2.x
If you are using container-managed authentication (the system that comes with Tomcat, that is configured for each Realm in the file server.xml), then the user roles and passwords are already automatically cached for each session (the isUserInrole() function and other similar functions do not trigger database accesses every time). If, on the other hand, you are authenticating the users with you own authentication system, then you could cache the authentication information in a session object (this is exactly what Tomcat does by default). Then, all private pages would check if the session object exists and if the user has been authenticated before displaying the private information. The only publicly visible key to this object is the session id, so all security problems could come from this session key being known to intermediate parties. Depending from the security level required by your application, you could consider setting lower expiration times for the session (or even explicitly expiring the session once some user operations have been successfully completed, with setMaxInactiveInterval()), or protecting the http communication with SSL. Andre de Jesus Renato Romano wrote: Hi, I would like Tomcat avoiding to access the DB for EVERY ACCESS to a reserved page. I think the best way to do this (apart from upgrading to Tomcat 4.0 !!) is to store the login info, or maybe just a flag I'm authenticated, in the session object. Does anyone already made something similar ? Should I only redefine methods in my Realm object ? Is there some security issue I'm not taking care of ?? Thanks Renato -- André de Jesus [EMAIL PROTECTED] TEKTIX - Consultoria em Sistemas de Informação, L.da http://www.tektix.com
RE: Caching Login Info in Tomcat 3.2.x
-Original Message- From: André de Jesus [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 02, 2001 9:03 AM To: [EMAIL PROTECTED] Subject: Re: Caching Login Info in Tomcat 3.2.x If you are using container-managed authentication (the system that comes with Tomcat, that is configured for each Realm in the file server.xml), then the user roles and passwords are already automatically cached for each session (the isUserInrole() function and other similar functions do not trigger database accesses every time). Actually that is not correct. The JdbcRealm class that is provided with Tomcat does do a database connection for each request. It never stores authentication information. The provided class could be modified to provide the caching requested, but you would have to recode the Realm (which isn't a big deal). There is only a security risk if you store passwords unencrypted in memory and someone has enough access to your system to perform a memory dump (and then the intelligence of look at the dump and find the Map, List, or array of authentication credentials). The biggest problem to watch out for is removing cached information - it a user changes their password and then exits the application (either explicitly or implicitly) then you need to make sure that their cached information is removed before they come back and try to use their new password. If, on the other hand, you are authenticating the users with you own authentication system, then you could cache the authentication information in a session object (this is exactly what Tomcat does by default). Then, all private pages would check if the session object exists and if the user has been authenticated before displaying the private information. The only publicly visible key to this object is the session id, so all security problems could come from this session key being known to intermediate parties. Depending from the security level required by your application, you could consider setting lower expiration times for the session (or even explicitly expiring the session once some user operations have been successfully completed, with setMaxInactiveInterval()), or protecting the http communication with SSL. Andre de Jesus Renato Romano wrote: Hi, I would like Tomcat avoiding to access the DB for EVERY ACCESS to a reserved page. I think the best way to do this (apart from upgrading to Tomcat 4.0 !!) is to store the login info, or maybe just a flag I'm authenticated, in the session object. Does anyone already made something similar ? Should I only redefine methods in my Realm object ? Is there some security issue I'm not taking care of ?? Thanks Renato -- André de Jesus [EMAIL PROTECTED] TEKTIX - Consultoria em Sistemas de Informação, L.da http://www.tektix.com
R: Caching Login Info in Tomcat 3.2.x
And what about just storing an I'm authenticated flag in the session, associated with the username (which is already there...) ? This way I have no problems about password changes... Therefore, i think password is already stored clearly in the session object as the attribute j_password, isn't it ? -Messaggio originale- Da: Randy Layman [mailto:[EMAIL PROTECTED]] Inviato: martedì 2 ottobre 2001 14.34 A: [EMAIL PROTECTED] Oggetto: RE: Caching Login Info in Tomcat 3.2.x -Original Message- From: André de Jesus [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 02, 2001 9:03 AM To: [EMAIL PROTECTED] Subject: Re: Caching Login Info in Tomcat 3.2.x If you are using container-managed authentication (the system that comes with Tomcat, that is configured for each Realm in the file server.xml), then the user roles and passwords are already automatically cached for each session (the isUserInrole() function and other similar functions do not trigger database accesses every time). Actually that is not correct. The JdbcRealm class that is provided with Tomcat does do a database connection for each request. It never stores authentication information. The provided class could be modified to provide the caching requested, but you would have to recode the Realm (which isn't a big deal). There is only a security risk if you store passwords unencrypted in memory and someone has enough access to your system to perform a memory dump (and then the intelligence of look at the dump and find the Map, List, or array of authentication credentials). The biggest problem to watch out for is removing cached information - it a user changes their password and then exits the application (either explicitly or implicitly) then you need to make sure that their cached information is removed before they come back and try to use their new password. If, on the other hand, you are authenticating the users with you own authentication system, then you could cache the authentication information in a session object (this is exactly what Tomcat does by default). Then, all private pages would check if the session object exists and if the user has been authenticated before displaying the private information. The only publicly visible key to this object is the session id, so all security problems could come from this session key being known to intermediate parties. Depending from the security level required by your application, you could consider setting lower expiration times for the session (or even explicitly expiring the session once some user operations have been successfully completed, with setMaxInactiveInterval()), or protecting the http communication with SSL. Andre de Jesus Renato Romano wrote: Hi, I would like Tomcat avoiding to access the DB for EVERY ACCESS to a reserved page. I think the best way to do this (apart from upgrading to Tomcat 4.0 !!) is to store the login info, or maybe just a flag I'm authenticated, in the session object. Does anyone already made something similar ? Should I only redefine methods in my Realm object ? Is there some security issue I'm not taking care of ?? Thanks Renato -- André de Jesus [EMAIL PROTECTED] TEKTIX - Consultoria em Sistemas de Informação, L.da http://www.tektix.com
Security issues with Tomcat 3.2.x
Hi. I'm using Jakarta Tomcat 3.2.2 with Apache 1.3.20 / mod_jk (Linux) and I have some security-related questions: 1) I've read 3.2.3 is the latest available version for 3.2.x branch and that it covers a security issue. What's about this security issue and where could I read more about this issue? Could it be the 2001-07-02: Apache Tomcat Cross-Site Scripting Vulnerability (http://www.securityfocus.com/vdb/bottom.html?vid=2982)? 2) Is there any patch or is it planned a future release to cover the 2001-08-16: Jakarta Tomcat 3.2.1 Error Message Information Disclosure Vulnerability issue? (http://www.securityfocus.com/vdb/bottom.html?vid=3199) 3) The following is a security issue I'm experiencing. It may be a configuration error made by myself or perhaps some bug? I need some help. Let's suppose you have a working .jsp page: http://www.foo.com/bar/home.jsp. Then if you use the following url the .jsp source is showed instead of beeing executed by Tomcat: http://www.foo.com/\bar/home.jsp. This is the way I'm using to mount the context (excerpt from mod_jk.conf file): Alias /bar /usr/local/tomcat/webapps/bar JkMount /bar/*.jsp ajp13 JkMount /bar/*.xml ajp13 JkMount /bar/servlet/* ajp13 Location /bar/WEB-INF/ AllowOverride None deny from all /Location Location /bar/META-INF/ AllowOverride None deny from all /Location Am I missing something or the \ trick is a bug? Any workaround? Thanks in advance! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** [EMAIL PROTECTED] ~~~
Re: WAR file behavior and Tomcat 3.2.x
Greetings, I read a document which it tolds that or we put our application already expanded, or by using a WAR file when TOMCAT is started, it will automatically expand the web application archive file into its unpacked form. I didn't know that there was a unpackWARfiles option! Where should I get a manual with all these options documented? thanks... -- psalazar/ - Original Message - From: Darrell Porter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 11, 2001 11:54 PM Subject: RE: WAR file behavior and Tomcat 3.2.x REPOST as I REALLY need help on this... I've read the documentation. I've added the unpackWARfiles=FALSE to my server.xml Why is Tomcat still unpacking the WAR file into the WEBAPPS directory? Should it not simply be unpacking files to WORK as it needs them? I had heard that it was possible to encrypt or password-protect the WAR file but I can find no instructions on configuring Tomcat to access these encrypted files. Any sources? Thanks Darrell Porter Only a man who can not conquer his deficiencies feels the need to convince the world he has none.
Re: WAR file behavior and Tomcat 3.2.x
Greetings, I read a document which it tolds that or we put our application already expanded, or by using a WAR file when TOMCAT is started, it will automatically expand the web application archive file into its unpacked form. I didn't know that there was a unpackWARfiles option! Where should I get a manual with all these options documented? thanks... -- psalazar/ - Original Message - From: Darrell Porter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 11, 2001 11:54 PM Subject: RE: WAR file behavior and Tomcat 3.2.x REPOST as I REALLY need help on this... I've read the documentation. I've added the unpackWARfiles=FALSE to my server.xml Why is Tomcat still unpacking the WAR file into the WEBAPPS directory? Should it not simply be unpacking files to WORK as it needs them? I had heard that it was possible to encrypt or password-protect the WAR file but I can find no instructions on configuring Tomcat to access these encrypted files. Any sources? Thanks Darrell Porter Only a man who can not conquer his deficiencies feels the need to convince the world he has none.
Re: WAR file behavior and Tomcat 3.2.x [problem replying]
Sorry, I have replied to the list two times because I was getting all my emails delivered with this message: The original message was received at Tue, 12 Jun 2001 05:55:23 -0700 (PDT) from localhost [127.0.0.1] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 550 User unknown) - Transcript of session follows - ... while talking to inbound.namezero.com.criticalpath.net.: RCPT To:[EMAIL PROTECTED] 550 User unknown 550 5.1.1 [EMAIL PROTECTED]... User unknown Hope this problem can be solved soon! Sorry for my duplicated messages, again... psalazar/ - Original Message - From: pedro salazar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 3:38 PM Subject: Re: WAR file behavior and Tomcat 3.2.x Greetings, I read a document which it tolds that or we put our application already expanded, or by using a WAR file when TOMCAT is started, it will automatically expand the web application archive file into its unpacked form. I didn't know that there was a unpackWARfiles option! Where should I get a manual with all these options documented? thanks... -- psalazar/ - Original Message - From: Darrell Porter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 11, 2001 11:54 PM Subject: RE: WAR file behavior and Tomcat 3.2.x REPOST as I REALLY need help on this... I've read the documentation. I've added the unpackWARfiles=FALSE to my server.xml Why is Tomcat still unpacking the WAR file into the WEBAPPS directory? Should it not simply be unpacking files to WORK as it needs them? I had heard that it was possible to encrypt or password-protect the WAR file but I can find no instructions on configuring Tomcat to access these encrypted files. Any sources? Thanks Darrell Porter Only a man who can not conquer his deficiencies feels the need to convince the world he has none.
RE: WAR file behavior and Tomcat 3.2.x
REPOST as I REALLY need help on this... I've read the documentation. I've added the unpackWARfiles=FALSE to my server.xml Why is Tomcat still unpacking the WAR file into the WEBAPPS directory? Should it not simply be unpacking files to WORK as it needs them? I had heard that it was possible to encrypt or password-protect the WAR file but I can find no instructions on configuring Tomcat to access these encrypted files. Any sources? Thanks Darrell Porter Only a man who can not conquer his deficiencies feels the need to convince the world he has none.
WAR file behavior and Tomcat 3.2.x
REPOST as I REALLY need help on this... I've read the documentation. I've added the unpackWARfiles=FALSE to my server.xml Why is Tomcat still unpacking the WAR file into the WEBAPPS directory? Should it not simply be unpacking files to WORK as it needs them? I had heard that it was possible to encrypt or password-protect the WAR file but I can find no instructions on configuring Tomcat to access these encrypted files. Any sources? Thanks Darrell Porter Only a man who can not conquer his deficiencies feels the need to convince the world he has none.
WAR file behavior and Tomcat 3.2.x
I've read the documentation. I've added the unpackWARfiles=FALSE to my server.xml Why is Tomcat still unpacking the WAR file into the WEBAPPS directory? Should it not simply be unpacking files to WORK as it needs them? I had heard that it was possible to encrypt or password-protect the WAR file but I can find no instructions on configuring Tomcat to access these encrypted files. Any sources? Thanks Darrell Porter Only a man who can not conquer his deficiencies feels the need to convince the world he has none.
Re: 2 Critical Problems with Tomcat 3.2.x
Andrew I am having a similar white screen problem with Tomcat 3.1 on a production system. One of the JSPs works fine, there is nothing wrong with the code, it has gone through some fairly rigorous testing. However, every couple of days, the JSP white screens. I've spent some time looking into it, and initially I thought there was something wrong with the JSP, not being able to open database connections (our database wasn't configured to allow a high number of connections), however, this isn't the problem. You mentioned in one of your emails that you were able to reproduce the problem. Can you tell me how you did this, as we have had difficulty reproducing it. We've tried pointing stress test tools at the particular JSP to no effect. We are running tomcat under Red hat linux 6.2 with JDK 1.3. We use Apache, JServ and Tomcat. Any thoughts/help on this would be appreciated. I'm going to try modifying our max_threads settings and see if that gets us anywhere, but info on reproducing this would be invaluable. Regards, Ronan
Re: 2 Critical Problems with Tomcat 3.2.x
I experienced TC 3.2.1 white screen problem!. I found bug #1006 of TC 3.2.1 and I upgraded TC 3.2.2b3 and white screen problem never happened. I recommend you should upgrade TC 3.2.2.. And if your application uses session, check your session timeout. If timeout is too long, your JVM may use too big memory! Good luck to you! On Sat, 27 Apr 2024, Andrew McDonald wrote: Thanks Bill for chasing this up, I really didn't want to repost. I was thinking of posting to the tomcat-dev list wrt these problems but I believe tomcat-user is the more appropriate list for discussing these sorts of issues. I thought I better give a few more data points: - Last night I set the logging to FATAL on the tomcat.log, etc. I read on the tomcat-dev list that having it set on DEBUG is potentially dangerous: the logger may not be able to keep up under extreme load. - I was almost *convinced* that I was running across bug #1006 too! However after installing tc 3.2.2b2 the problem remained. - Jeff Kilbride suggested I try to cap the max_threads etc of the thread pool, which may help. I will be trying this soon (but not today: Fridays are bad days to modify production systems) We need a solution to this and are willing to help in whatever way we can. We are testing commercial alternatives such as JRun and BEA despite my reluctance: Apart from these 2 critical problems I think Tomcat is great and I love OSS projects such as this. I'm expected to get this fixed through whatever means possible so any suggestions would be appreciated. Cheers AndyM Bill Graham wrote: I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During this time the box is fine, and to solve it temporarily I just need to kill all the java processes and restart Tomcat. This problem occurs regardless of JVM and the version of the Linux Kernel doesn't seem to make a difference. It happens once or twice a week. Assistance with either of these problems would be greatly appreciated. Number 2 is the really important one but information regarding number 1 would be great as well. Of course if you need more information please get back to me. Oh, and btw, yes I realise that running
Re: 2 Critical Problems with Tomcat 3.2.x
Indeed. The documentation I've found doesn't seem to clarify this :( but I'll be testing and posting results here on the list. Cheers AndyM Jeff Kilbride wrote: Hi Andy, Sorry, I was assuming you were using Tomcat with Apache. I'm not sure if you can configure thread pooling the same way in standalone mode or not. The configurations I was talking about were for the PoolTCPConnector class, I believe. It's worth a look, but I'm not sure it will apply in your case. Thanks, --jeff - Original Message - From: Andrew McDonald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, April 26, 2024 10:23 PM Subject: Re: 2 Critical Problems with Tomcat 3.2.x Thank you very much for the advice Jeff. I'll have a go at that. We *are* using a thread pool to run threads that make connections to our database but we have Tomcat in standalone mode. The Tomcat documentation describes setting the max_threads, etc of the ajpv12 connector but i'd suppose the other connectors would have the same/similar syntax. Cheers AndyM Jeff Kilbride wrote: I saw something on the dev list about Tomcat's default thread limit and how, under load, Apache processes could get stuck waiting for a Tomcat thread to become available. Have you changed any of the threading defaults in your server.xml file? Check out the Tomcat Users Guide here: http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/index.html and do a find for the phrase max_threads. It shows you how to configure min, max, and spare threads in Tomcat's thread pool and talks about the default values. If you up these values, maybe that will help. Thanks, --jeff - Original Message - From: Bill Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 26, 2001 11:50 AM Subject: RE: 2 Critical Problems with Tomcat 3.2.x I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During
Re: 2 Critical Problems with Tomcat 3.2.x
Hi there! Thank you very much for your report on the white screen problem. There seems to have been a lot of work on the web connector since I used it last and I was hoping that this problem was resolved. This is great news if I experience the same behaviour you have. Time for some testing! Thanks for the advice re: session timeouts. yes, we do use sessions. I don't believe we are going OOM but it's certainly worth investigating. I will keep you all posted. Best wishes. Cheers AndyM Kim Jong Tae wrote: I experienced TC 3.2.1 white screen problem!. I found bug #1006 of TC 3.2.1 and I upgraded TC 3.2.2b3 and white screen problem never happened. I recommend you should upgrade TC 3.2.2.. And if your application uses session, check your session timeout. If timeout is too long, your JVM may use too big memory! Good luck to you! On Sat, 27 Apr 2024, Andrew McDonald wrote: Thanks Bill for chasing this up, I really didn't want to repost. I was thinking of posting to the tomcat-dev list wrt these problems but I believe tomcat-user is the more appropriate list for discussing these sorts of issues. I thought I better give a few more data points: - Last night I set the logging to FATAL on the tomcat.log, etc. I read on the tomcat-dev list that having it set on DEBUG is potentially dangerous: the logger may not be able to keep up under extreme load. - I was almost *convinced* that I was running across bug #1006 too! However after installing tc 3.2.2b2 the problem remained. - Jeff Kilbride suggested I try to cap the max_threads etc of the thread pool, which may help. I will be trying this soon (but not today: Fridays are bad days to modify production systems) We need a solution to this and are willing to help in whatever way we can. We are testing commercial alternatives such as JRun and BEA despite my reluctance: Apart from these 2 critical problems I think Tomcat is great and I love OSS projects such as this. I'm expected to get this fixed through whatever means possible so any suggestions would be appreciated. Cheers AndyM Bill Graham wrote: I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached
Re: 2 Critical Problems with Tomcat 3.2.x
Hi Andy, Sorry, I was assuming you were using Tomcat with Apache. I'm not sure if you can configure thread pooling the same way in standalone mode or not. The configurations I was talking about were for the PoolTCPConnector class, I believe. It's worth a look, but I'm not sure it will apply in your case. Thanks, --jeff - Original Message - From: Andrew McDonald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, April 26, 2024 10:23 PM Subject: Re: 2 Critical Problems with Tomcat 3.2.x Thank you very much for the advice Jeff. I'll have a go at that. We *are* using a thread pool to run threads that make connections to our database but we have Tomcat in standalone mode. The Tomcat documentation describes setting the max_threads, etc of the ajpv12 connector but i'd suppose the other connectors would have the same/similar syntax. Cheers AndyM Jeff Kilbride wrote: I saw something on the dev list about Tomcat's default thread limit and how, under load, Apache processes could get stuck waiting for a Tomcat thread to become available. Have you changed any of the threading defaults in your server.xml file? Check out the Tomcat Users Guide here: http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/index.html and do a find for the phrase max_threads. It shows you how to configure min, max, and spare threads in Tomcat's thread pool and talks about the default values. If you up these values, maybe that will help. Thanks, --jeff - Original Message - From: Bill Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 26, 2001 11:50 AM Subject: RE: 2 Critical Problems with Tomcat 3.2.x I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During this time the box is fine, and to solve it temporarily I just need to kill all the java processes and restart Tomcat. This problem occurs regardless of JVM and the version of the Linux Kernel doesn't seem to make a difference. It happens once or twice a week. Assistance
RE: 2 Critical Problems with Tomcat 3.2.x
I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During this time the box is fine, and to solve it temporarily I just need to kill all the java processes and restart Tomcat. This problem occurs regardless of JVM and the version of the Linux Kernel doesn't seem to make a difference. It happens once or twice a week. Assistance with either of these problems would be greatly appreciated. Number 2 is the really important one but information regarding number 1 would be great as well. Of course if you need more information please get back to me. Oh, and btw, yes I realise that running Compaq desktops in production isn't the best idea ;) That will be attended to. Thanks in advance Cheers -- Andrew McDonaldWe cannot reason ourselves out of our basic Systems Administration irrationality. All we can do is learn the art HOTcopper Australia of being irrational in a reasonable way. http://www.hotcopper.com.au - Huxley
Re: 2 Critical Problems with Tomcat 3.2.x
I saw something on the dev list about Tomcat's default thread limit and how, under load, Apache processes could get stuck waiting for a Tomcat thread to become available. Have you changed any of the threading defaults in your server.xml file? Check out the Tomcat Users Guide here: http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/index.html and do a find for the phrase max_threads. It shows you how to configure min, max, and spare threads in Tomcat's thread pool and talks about the default values. If you up these values, maybe that will help. Thanks, --jeff - Original Message - From: Bill Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 26, 2001 11:50 AM Subject: RE: 2 Critical Problems with Tomcat 3.2.x I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During this time the box is fine, and to solve it temporarily I just need to kill all the java processes and restart Tomcat. This problem occurs regardless of JVM and the version of the Linux Kernel doesn't seem to make a difference. It happens once or twice a week. Assistance with either of these problems would be greatly appreciated. Number 2 is the really important one but information regarding number 1 would be great as well. Of course if you need more information please get back to me. Oh, and btw, yes I realise that running Compaq desktops in production isn't the best idea ;) That will be attended to. Thanks in advance Cheers -- Andrew McDonaldWe cannot reason ourselves out of our basic Systems Administration irrationality. All we can do is learn the art HOTcopper Australia of being irrational in a reasonable way. http://www.hotcopper.com.au - Huxley
Re: 2 Critical Problems with Tomcat 3.2.x
Thank you very much for the advice Jeff. I'll have a go at that. We *are* using a thread pool to run threads that make connections to our database but we have Tomcat in standalone mode. The Tomcat documentation describes setting the max_threads, etc of the ajpv12 connector but i'd suppose the other connectors would have the same/similar syntax. Cheers AndyM Jeff Kilbride wrote: I saw something on the dev list about Tomcat's default thread limit and how, under load, Apache processes could get stuck waiting for a Tomcat thread to become available. Have you changed any of the threading defaults in your server.xml file? Check out the Tomcat Users Guide here: http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/index.html and do a find for the phrase max_threads. It shows you how to configure min, max, and spare threads in Tomcat's thread pool and talks about the default values. If you up these values, maybe that will help. Thanks, --jeff - Original Message - From: Bill Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 26, 2001 11:50 AM Subject: RE: 2 Critical Problems with Tomcat 3.2.x I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During this time the box is fine, and to solve it temporarily I just need to kill all the java processes and restart Tomcat. This problem occurs regardless of JVM and the version of the Linux Kernel doesn't seem to make a difference. It happens once or twice a week. Assistance with either of these problems would be greatly appreciated. Number 2 is the really important one but information regarding number 1 would be great as well. Of course if you need more information please get back to me. Oh, and btw, yes I realise that running Compaq desktops in production isn't the best idea ;) That will be attended to. Thanks in advance Cheers -- Andrew McDonaldWe cannot reason ourselves out of our basic Systems Administration irrationality. All we can do is learn the art HOTcopper Australia of being irrational in a reasonable way. http
Re: 2 Critical Problems with Tomcat 3.2.x
Thanks Bill for chasing this up, I really didn't want to repost. I was thinking of posting to the tomcat-dev list wrt these problems but I believe tomcat-user is the more appropriate list for discussing these sorts of issues. I thought I better give a few more data points: - Last night I set the logging to FATAL on the tomcat.log, etc. I read on the tomcat-dev list that having it set on DEBUG is potentially dangerous: the logger may not be able to keep up under extreme load. - I was almost *convinced* that I was running across bug #1006 too! However after installing tc 3.2.2b2 the problem remained. - Jeff Kilbride suggested I try to cap the max_threads etc of the thread pool, which may help. I will be trying this soon (but not today: Fridays are bad days to modify production systems) We need a solution to this and are willing to help in whatever way we can. We are testing commercial alternatives such as JRun and BEA despite my reluctance: Apart from these 2 critical problems I think Tomcat is great and I love OSS projects such as this. I'm expected to get this fixed through whatever means possible so any suggestions would be appreciated. Cheers AndyM Bill Graham wrote: I've also been experienceing a lot of the Number 2 problem described where Tomcat stops responding to http requests and I can't figure out what's causing it. I've been able to reproduce the problem with multiple VMs on both Linux and Solaris machines. I applied the patch for Tomcat bug #1006 and the hanging still occurs. I haven't come across any responses to Andy's first post so I thought I'd ask again. Anyone have any idea what's causing this? thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew McDonald Sent: Sunday, April 22, 2001 10:56 PM To: [EMAIL PROTECTED] Subject: 2 Critical Problems with Tomcat 3.2.x Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During this time the box is fine, and to solve it temporarily I just need to kill all the java processes and restart Tomcat. This problem occurs regardless of JVM and the version of the Linux Kernel doesn't seem to make a difference. It happens once or twice a week. Assistance with either of these problems would be greatly appreciated. Number 2 is the really important one but information regarding number 1 would be great as well. Of course if you need more information please get back to me. Oh, and btw, yes I realise that running Compaq desktops in production isn't the best idea ;) That will be attended to. Thanks in advance Cheers -- Andrew McDonaldWe cannot reason ourselves out of our basic Systems Administration irrationality. All we can do is learn the art HOTcopper Australia of being irrational in a reasonable way. http://www.hotcopper.com.au
2 Critical Problems with Tomcat 3.2.x
Hi there, First I'd like to thank the developers for a great product. Tomcat is a nice piece of software. And like all great OSS, very easy to raise a purchase order for ;) Thanks guys. Unfortunately I have run into a couple of serious show-stoppers when deploying TC in production. A bit of background: We have been running various incarnations of JServ and Tomcat over the past 12 months or so. We have 3 Application Servers: Two Compaq Deskpro PII/450s and one PIII/500 with 128MB Ram each. They are running Linux, kernel is 2.2.19, glibc-2.1.3. We are currently running various incarnations of TC3.2.x We run a Stock Trading Forum, which is made up of Servlets and JSPs. You can see it at http://www.hotcopper.com.au if you're interested at all. We are one of the most hit websites in Australia according to www.top100.com.au. We have tested Tomcat with the Solaris 1.3 JVM, IBM 1.3 JVM and Blackdown 1.3 JVM (FCS). I'm happiest with Blackdown. It *seems* to have the best performance. On to the problems: 1. We dubbed this one The Apache White Screen problem. We connected Tomcat to various versions of Apache =1.14 in the standard way (mod_jk.so) Symptom: People using Internet Explorer to browse our site will intermittently get a white/ blank screen instead of results from our application. When this happens, we believe the request doesn't even enter the java code, so it may be a problem with the connector. I seem to recall (sorry this was about 8 months ago) Apache returning a 304 or a 302. I haven't re-tested this in a while, I was just wondering whether people were aware of this problem in the past and had already looked into it and possibly fixed it. Our solution was to run Tomcat standalone, which seemed to solve this issue. 2. We dubbed this one The 132 Thread Problem, even though it doesn't always happen with 132 threads; sometimes 128, 130, or if using the Blackdown JVM, 134. (wierd). We use NATIVE threads. Symptom: Tomcat stops responding to http requests after a certain number (~132) of threads is reached. When this happens it will either deadlock or segfault. During this time the box is fine, and to solve it temporarily I just need to kill all the java processes and restart Tomcat. This problem occurs regardless of JVM and the version of the Linux Kernel doesn't seem to make a difference. It happens once or twice a week. Assistance with either of these problems would be greatly appreciated. Number 2 is the really important one but information regarding number 1 would be great as well. Of course if you need more information please get back to me. Oh, and btw, yes I realise that running Compaq desktops in production isn't the best idea ;) That will be attended to. Thanks in advance Cheers -- Andrew McDonaldWe cannot reason ourselves out of our basic Systems Administration irrationality. All we can do is learn the art HOTcopper Australia of being irrational in a reasonable way. http://www.hotcopper.com.au - Huxley
Is it possible to use JNDI in Tomcat 3.2.x
Hi I was trying to use JNDI in Tomcat and I didn't get anywhere. My servlet should connect to EJB that is in another server on different machine. I know that it's possible to use JNDI in Tomcat 4 beta, but there isn't any documentation and I don't have time to experiment. Is there any documentation for using JNDI in Tomcat 3.2.x or 4 beta? Any link? Any sample code? Thanks in advance. Denis Kranjcec
