Re: Tomcat to Apache connection dies
Martin Gainty wrote: pls post the mod_jk.log Thank you for taking an interest.. Unfortunately the log is empty.. Rainer suggested that I needed to set the log level or that something was wrong in that area as well. John.. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP: Threads sitting forever in getConnection()?
You should set the maxWait parameter. On Sun, Mar 16, 2008 at 5:29 PM, rohitmp <[EMAIL PROTECTED]> wrote: > HI All, > I too am facing the same issue. > But in contrast i have my resource setup in context.xml only > But still tomcat is waiting indefinitely to to get a connection. > > My context file is as below > > > >type="javax.sql.DataSource" username="schot" password="tiger" >driverClassName="org.gjt.mm.mysql.Driver" > url="jdbc:mysql://localhost:3306/myDb" >maxActive="100" maxIdle="30"/> > > > > the relevant thread dump is as follows > > "http-8080-Processor2" daemon prio=10 tid=0x08374800 nid=0xef4 > in Object.wait() [0xae069000..0xae069e30] > java.lang.Thread.State: WAITING (on object monitor) >at java.lang.Object.wait(Native Method) >- waiting on <0xaf619100> (a > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool) >at java.lang.Object.wait(Object.java:485) >at org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.borrowObject > (GenericObjectPool.java:810) >- locked <0xaf619100> (a > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool) >at org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection > (PoolingDataSource.java:96) >at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection > (BasicDataSource.java:880) >at com.bhagin.vaanee.util.DBConnection.init > (DBConnection.java:64) >at > com.bhagin.vaanee.authorisation.AttributeBeanSetter.fngetSessionAttributeBean > (AttributeBeanSetter.java:42) >at org.apache.jsp.authorize_jsp._jspService > (authorize_jsp.java:116) >at org.apache.jasper.runtime.HttpJspBase.service( > HttpJspBase.java:98) >at javax.servlet.http.HttpServlet.service > (HttpServlet.java:803) >at org.apache.jasper.servlet.JspServletWrapper.service > (JspServletWrapper.java:331) >at org.apache.jasper.servlet.JspServlet.serviceJspFile > (JspServlet.java:329) >at org.apache.jasper.servlet.JspServlet.service > (JspServlet.java:265) >at javax.servlet.http.HttpServlet.service > (HttpServlet.java:803) >at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter > (ApplicationFilterChain.java:269) >at org.apache.catalina.core.ApplicationFilterChain.doFilter > (ApplicationFilterChain.java:188) >at org.apache.catalina.core.StandardWrapperValve.invoke > (StandardWrapperValve.java:213) >at org.apache.catalina.core.StandardContextValve.invoke > (StandardContextValve.java:174) >at org.apache.catalina.core.StandardHostValve.invoke > (StandardHostValve.java:127) >at org.apache.catalina.valves.ErrorReportValve.invoke( > ErrorReportValve.java:117) >at org.apache.catalina.core.StandardEngineValve.invoke > (StandardEngineValve.java:108) >at org.apache.catalina.connector.CoyoteAdapter.service > (CoyoteAdapter.java:151) >at org.apache.coyote.http11.Http11Processor.process > (Http11Processor.java:874) >at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler. > processConnection(Http11BaseProtocol.java:665) >at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket > (PoolTcpEndpoint.java:528) >at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt > (LeaderFollowerWorkerThread.java:81) >at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run > (ThreadPool.java:689) >at java.lang.Thread.run(Thread.java:619) > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Bernardo Cattapan [EMAIL PROTECTED]
Re: Making the most of 8G of RAM
there is a recorded webinar called "Inside the Java Virtual Machine" http://www.covalent.net/services/training/webinars.html it's one hour spent demystifying all you need to know about the JVM memory usage, once you've understood that, you'll have a very different perspective on -Xmx Filip Stephen Nelson-Smith wrote: Hi, I have a new machine with 8G of RAM, running a 32 bit 2.6 kernel (CentOS 5). It is running an application inside 4.1.37 with Java 1.4.2. Given that we only have a 32 bit address space, is it fair to say that I can't use more than 2G of RAM for my Java virtual machine? I tried to prove this with: export CATALINA_OPTS="-server -Xms2512m -Xmx2512m" but so far I've not seen memory usage go over 1G. What's the best way to make to most of the RAM? S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat to Apache connection dies
pls post the mod_jk.log M- - Original Message - From: "John Moore" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Monday, March 17, 2008 8:10 PM Subject: Re: Tomcat to Apache connection dies > Rainer Jung wrote: > > > > Which connector do you use? The usual Coyote (Jav) connector, or the > > native APR connector (also called tcnative)? > Hmm.. good question.. I follow the directions, compile and it (make > install) puts the mod_jk.so in the ../apache/modules directory. I would > guess it is the native since I compile the code in the ../native > directory. Guess I did not pickup that there was a difference.. > > What should I be doing..? > > > > >> Actually I do.. Here is that setting from my server.xml > >> > >> > >> >> enableLookups="false" > >> redirectPort="8443" > >> protocol="AJP/1.3" > >> connectionTimeout="6" > >> maxThreads="750" > >> debug="0" /> > >> > >> Is there anything else here that needs changing..? > > > > Hmmm, maybe set connectionTimeout to 60 instead of 6. > > Otherwise TC and mod_jk don't use the same timeout (I think you had 10 > > minutes ofr mod_jk). This will not be the reason for your strange > > observation, but it should reduce the CLOSE_WAIT connections during > > normal operations. > Just to be clear.. > > The Tomcat Connector setting for port 8009 of "connectionTimeout" should > equal the worker.properties setting of: > > connection_pool_timeout > > or > > connect_timeout > > ? > > > > > I would run a cron job, that writes out the netstat statistics for > > 8009 (how many connections in which state, including LISTEN etc.) once > > a minute to get an idea, if you run into something extreme immediately > > before the LISTEN dies. > Ok.. I work on setting that "trap" up... > > > > The previous hint about taking thread dumps once the problem is there > > is still valid. That way we can check from the inside of the JVM, if > > the accept thread is gone. But we still won't know why. > > > > Any interesting log items on the TC side? OutOfMemory errors? > > No, not generally.. I have had one "OutOfMemory" error several weeks ago > that I never could "explain", but that is the first that did not showed > up in the catalina.out logs AS a problem.. > > > > Those port 3050 connections are DB connections or something similar I > > suppose? > Correct.. Firebird. > > Thanks, I really appreciate the suggestions.. I'll post back to this > thread once I get some results based on your suggestions.. > > John.. > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat to Apache connection dies
Rainer Jung wrote: Which connector do you use? The usual Coyote (Jav) connector, or the native APR connector (also called tcnative)? Hmm.. good question.. I follow the directions, compile and it (make install) puts the mod_jk.so in the ../apache/modules directory. I would guess it is the native since I compile the code in the ../native directory. Guess I did not pickup that there was a difference.. What should I be doing..? Actually I do.. Here is that setting from my server.xml Is there anything else here that needs changing..? Hmmm, maybe set connectionTimeout to 60 instead of 6. Otherwise TC and mod_jk don't use the same timeout (I think you had 10 minutes ofr mod_jk). This will not be the reason for your strange observation, but it should reduce the CLOSE_WAIT connections during normal operations. Just to be clear.. The Tomcat Connector setting for port 8009 of "connectionTimeout" should equal the worker.properties setting of: connection_pool_timeout or connect_timeout ? I would run a cron job, that writes out the netstat statistics for 8009 (how many connections in which state, including LISTEN etc.) once a minute to get an idea, if you run into something extreme immediately before the LISTEN dies. Ok.. I work on setting that "trap" up... The previous hint about taking thread dumps once the problem is there is still valid. That way we can check from the inside of the JVM, if the accept thread is gone. But we still won't know why. Any interesting log items on the TC side? OutOfMemory errors? No, not generally.. I have had one "OutOfMemory" error several weeks ago that I never could "explain", but that is the first that did not showed up in the catalina.out logs AS a problem.. Those port 3050 connections are DB connections or something similar I suppose? Correct.. Firebird. Thanks, I really appreciate the suggestions.. I'll post back to this thread once I get some results based on your suggestions.. John.. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Help with TomCat 6.0 & SSI
> From: Steve Major [mailto:[EMAIL PROTECTED] > Subject: Re: Help with TomCat 6.0 & SSI > > Does this mean I need to revert to putting it in my server.xml? No, it means you've got something else wrong. Make sure your webapp's directory structure is correct by comparing it to the manager and host-manager webapps that come with Tomcat 6.0 (both of which are privileged). Once that's verified, install Lambda Probe (www.lambdaprobe.org) and bring up Tomcat. Browse to the Lambda Probe app (usually http://localhost:8080/probe), click on your webapp name in the left column, then the Context descriptor box on the right side. Make sure your element is shown correctly. If that's all correct, then you may have to fiddle with the conf/catalina.policy file, but I don't think that should be necessary. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making the most of 8G of RAM
On Mon, Mar 17, 2008 at 11:21 PM, Caldarale, Charles R <[EMAIL PROTECTED]> wrote: > > From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] > > How about running eg 3 x xen vms? The machine seems rarely pushed for > > CPU, and with 3 vms I could load balance across them. > > Why bother with xen? If you have work enough for three Tomcats, just > run them all on one copy of the OS. What does the additional complexity > buy you? We only run one app, but it is heavily used. I couldn't easily point different groups of users to different virtual hosts, but I could fairly easily balance across 3 vms using mod_proxy_ajp. As I write that I realise I could do that on one OS, of course, so I am not sure I see the benefit any more, as you say. > - Chuck S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making the most of 8G of RAM
If one of your webapps could use a faster database or filesystem, you might look into using a ramdisk. Any program that needs 8gb of RAM to run seems suspect. Large amounts of data should be abstracted through the filesystem and dealt with as files. On Mon, Mar 17, 2008 at 4:21 PM, Caldarale, Charles R <[EMAIL PROTECTED]> wrote: > > From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] > > Subject: Re: Making the most of 8G of RAM > > > > > I plan to test running with a newer JVM shortly. I have been told by > > the developers that the application needs to run under 1.4.2. We > > shall see. > > Unless the app uses the keyword "enum" or the JSPs aren't in packages, I > doubt you'll find any problems. > > > > How about running eg 3 x xen vms? The machine seems rarely pushed for > > CPU, and with 3 vms I could load balance across them. > > Why bother with xen? If you have work enough for three Tomcats, just > run them all on one copy of the OS. What does the additional complexity > buy you? > > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > - > > > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help with TomCat 6.0 & SSI
Thanks, my webapp has neither a META-INF directory or a context.xml file anywhere in it's directory structure. I tried creating a META- INF/context.xml in my webapp's root directory, but that didn't work. I still get: Servlet of class org.apache.catalina.servlets.SSIServlet is privileged and cannot be loaded by this web application. Does this mean I need to revert to putting it in my server.xml? On Mar 17, 2008, at 3:47 PM, Caldarale, Charles R wrote: From: Steve Major [mailto:[EMAIL PROTECTED] Subject: Re: Help with TomCat 6.0 & SSI Thanks very much, I believe I want an entry in my context.xml something like: No, do not put elements in server.xml; that is strongly discouraged, and persists only for compatibility with older levels. Your element should go into your webapp's META-INF/ context.xml file, but without the path and docBase attributes. Your webapp should be placed in webapps, not server/webapps (that directory doesn't exist in Tomcat 6). Don't forget to uncomment the for the ssi servlet in conf/web.xml. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e- mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making the most of 8G of RAM
> From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] > Subject: Re: Making the most of 8G of RAM > > I plan to test running with a newer JVM shortly. I have been told by > the developers that the application needs to run under 1.4.2. We > shall see. Unless the app uses the keyword "enum" or the JSPs aren't in packages, I doubt you'll find any problems. > How about running eg 3 x xen vms? The machine seems rarely pushed for > CPU, and with 3 vms I could load balance across them. Why bother with xen? If you have work enough for three Tomcats, just run them all on one copy of the OS. What does the additional complexity buy you? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making the most of 8G of RAM
On Mon, Mar 17, 2008 at 10:53 PM, Caldarale, Charles R <[EMAIL PROTECTED]> wrote: > > but so far I've not seen memory usage go over 1G. > > There is (or at least was) a bug in the Sun 1.4.2 JVM that didn't do the > arithmetic right when heap sizes were over 2GB due to treating some > unsigned values as signed. You really should move up to a much more > current JVM. I plan to test running with a newer JVM shortly. I have been told by the developers that the application needs to run under 1.4.2. We shall see. > Put in a 64-bit OS and a 64-bit JVM. While you're at it, try running a > newer Tomcat. Yes indeed. All what I am planning to do. In the meantime I have to get the most out of what I have, while I work out what combination of JVM / Tomcat / OS will work with the application, and while I get the dev team to rewrite code that won't work. > If you must stick with a 32-bit environment, you could run multiple > Tomcats, one for each webapp you have, assuming you have more than one. How about running eg 3 x xen vms? The machine seems rarely pushed for CPU, and with 3 vms I could load balance across them. > - Chuck S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Making the most of 8G of RAM
> From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] > Subject: Making the most of 8G of RAM > > Given that we only have a 32 bit address space, is it fair to say that > I can't use more than 2G of RAM for my Java virtual machine? Most 32-bit Linux systems will give you 3GB of virtual space (not RAM - don't confuse the two) per process. Some of this is taken up by various process and thread structures, along with code and non-heap data. Consequently, there's considerably less than 3GB available for the heap. > but so far I've not seen memory usage go over 1G. There is (or at least was) a bug in the Sun 1.4.2 JVM that didn't do the arithmetic right when heap sizes were over 2GB due to treating some unsigned values as signed. You really should move up to a much more current JVM. > What's the best way to make to most of the RAM? Put in a 64-bit OS and a 64-bit JVM. While you're at it, try running a newer Tomcat. If you must stick with a 32-bit environment, you could run multiple Tomcats, one for each webapp you have, assuming you have more than one. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making the most of 8G of RAM
Stephen Nelson-Smith a écrit : Hi, I have a new machine with 8G of RAM, running a 32 bit 2.6 kernel (CentOS 5). It is running an application inside 4.1.37 with Java 1.4.2. Given that we only have a 32 bit address space, is it fair to say that I can't use more than 2G of RAM for my Java virtual machine? I tried to prove this with: export CATALINA_OPTS="-server -Xms2512m -Xmx2512m" but so far I've not seen memory usage go over 1G. What's the best way to make to most of the RAM? S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Not fair to say that. The maximum space depends on several factor (see mailing list archives, this has already been discussed). To get most of your 8G machine, I recommend 64bits OS + 64bits jvm. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Making the most of 8G of RAM
Hi, I have a new machine with 8G of RAM, running a 32 bit 2.6 kernel (CentOS 5). It is running an application inside 4.1.37 with Java 1.4.2. Given that we only have a 32 bit address space, is it fair to say that I can't use more than 2G of RAM for my Java virtual machine? I tried to prove this with: export CATALINA_OPTS="-server -Xms2512m -Xmx2512m" but so far I've not seen memory usage go over 1G. What's the best way to make to most of the RAM? S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat to Apache connection dies
Hi John, John Moore schrieb: Rainer Jung wrote: Please have a look at your mod_jk log file and look for '[error]' messages. Around the error messages there should also be additional info messages giving some mor einfo about the root cause. mod_jk.log is empty. VERY strange. Set JkLogLevel to info. When using 1.2.26: It should at least log the version number during startup. If it doesn't, then there's already a logging problem to fix. OK, you could switch to mod_jk 1.2.26 so we don't have to check against any old bugs. 1.2.26 is now 3 months old and no major new bugs are known. OK, I'll do that this weekend.. That sounds really weird. If you stop and start Apache httpd and Tomcat (i.e. all processes completely stopped, wait a few seconds and then started freshly), those processes should not have any more knowledge of previous problems. That is what I would have thought.. no joy...I attached the netstat output so you can see all of the lines for yourself.. Hope that helps.. There is no LISTEN for 8009 in this output. So once you get into this state we wouldn't expect mod_jk to be able to reach Tomcat with new connections anymore. Why do we get into such a situation? Since you are using a 64Bit VM, I really don't know :( Which connector do you use? The usual Coyote (Jav) connector, or the native APR connector (also called tcnative)? Possibly related information: netstat -np --tcp reports dozens of "dead" connections to port 8009, like the following samples: (count in parens to save space here): tcp0 0 127.0.0.1:8009 127.0.0.1:48461 SYN_RECV- (13) tcp0 6 127.0.0.1:48459 127.0.0.1:8009 FIN_WAIT1 - (3) tcp6 0 :::127.0.0.1:8009 :::127.0.0.1:48191 CLOSE_WAIT - (50) The CLOSE_WAIT most likely come from the fact, that you use a connect_timeout (that's fine) for mod_jk, but have no connectionTimeout on teh Toncat side. Set connectionTimeout in the Tomcat sidfe in the AJP connector to 60 (milliseconds). Actually I do.. Here is that setting from my server.xml Is there anything else here that needs changing..? Hmmm, maybe set connectionTimeout to 60 instead of 6. Otherwise TC and mod_jk don't use the same timeout (I think you had 10 minutes ofr mod_jk). This will not be the reason for your strange observation, but it should reduce the CLOSE_WAIT connections during normal operations. The SYN_RECV seem to indicate, that your Tomcat is not able to accept any more connections. Two possible reasons: - all threads in the thread pool of your AJP connector (Tomcat side) are already connected with httpd and no more threads are left. E.g. in your case it could be, that 50 threads are connected and maybe the size of your thread pool is 50? - you got an exception during creation of a new thread for the pool, and as a consequence your Tomcat is not listening any more. Can you see the LISTEN for 8009 in netstat? If no, the most likely cause is, that your JVM exceeded the number of threads that it can create (most 32 Bit JVMs: something between 400 and 500). This is a 64 bit system and using 64 bit JVM... I was seeing this problem also on a 32 bit system and had hoped that the 64 bit JVM would give me more "margin of error", apparently not. (See attached netstat output) If the problem happens again: check to see, if you can telnet to the TC port (telnet localhost 8009). If no, then mod_jk also has no chance of connecting to the Tomcat and we must find out, why Tomcat doesn't accept any more connections. In that case a thread dump of the Tomcat java process is helpful (kill -QUIT, result goes to catalin.out). Good suggestion, I'll give that a try.. Thanks for all of the other suggestions, I made those changes immediately, and I'll upgrade the connector this weekend. If you are anyone else have some ideas for me to try, I would REALLY appreciate it.. I would run a cron job, that writes out the netstat statistics for 8009 (how many connections in which state, including LISTEN etc.) once a minute to get an idea, if you run into something extreme immediately before the LISTEN dies. The previous hint about taking thread dumps once the problem is there is still valid. That way we can check from the inside of the JVM, if the accept thread is gone. But we still won't know why. Any interesting log items on the TC side? OutOfMemory errors? Those port 3050 connections are DB connections or something similar I suppose? Thanks again.. John.. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat to Apache connection dies
Rainer Jung wrote: Please have a look at your mod_jk log file and look for '[error]' messages. Around the error messages there should also be additional info messages giving some mor einfo about the root cause. mod_jk.log is empty. OK, you could switch to mod_jk 1.2.26 so we don't have to check against any old bugs. 1.2.26 is now 3 months old and no major new bugs are known. OK, I'll do that this weekend.. That sounds really weird. If you stop and start Apache httpd and Tomcat (i.e. all processes completely stopped, wait a few seconds and then started freshly), those processes should not have any more knowledge of previous problems. That is what I would have thought.. no joy...I attached the netstat output so you can see all of the lines for yourself.. Hope that helps.. Possibly related information: netstat -np --tcp reports dozens of "dead" connections to port 8009, like the following samples: (count in parens to save space here): tcp0 0 127.0.0.1:8009 127.0.0.1:48461 SYN_RECV- (13) tcp0 6 127.0.0.1:48459 127.0.0.1:8009 FIN_WAIT1 - (3) tcp6 0 :::127.0.0.1:8009 :::127.0.0.1:48191 CLOSE_WAIT - (50) The CLOSE_WAIT most likely come from the fact, that you use a connect_timeout (that's fine) for mod_jk, but have no connectionTimeout on teh Toncat side. Set connectionTimeout in the Tomcat sidfe in the AJP connector to 60 (milliseconds). Actually I do.. Here is that setting from my server.xml Is there anything else here that needs changing..? The SYN_RECV seem to indicate, that your Tomcat is not able to accept any more connections. Two possible reasons: - all threads in the thread pool of your AJP connector (Tomcat side) are already connected with httpd and no more threads are left. E.g. in your case it could be, that 50 threads are connected and maybe the size of your thread pool is 50? - you got an exception during creation of a new thread for the pool, and as a consequence your Tomcat is not listening any more. Can you see the LISTEN for 8009 in netstat? If no, the most likely cause is, that your JVM exceeded the number of threads that it can create (most 32 Bit JVMs: something between 400 and 500). This is a 64 bit system and using 64 bit JVM... I was seeing this problem also on a 32 bit system and had hoped that the 64 bit JVM would give me more "margin of error", apparently not. (See attached netstat output) If the problem happens again: check to see, if you can telnet to the TC port (telnet localhost 8009). If no, then mod_jk also has no chance of connecting to the Tomcat and we must find out, why Tomcat doesn't accept any more connections. In that case a thread dump of the Tomcat java process is helpful (kill -QUIT, result goes to catalin.out). Good suggestion, I'll give that a try.. Thanks for all of the other suggestions, I made those changes immediately, and I'll upgrade the connector this weekend. If you are anyone else have some ideas for me to try, I would REALLY appreciate it.. Thanks again.. John.. Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 127.0.0.1:8009 127.0.0.1:48461 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48457 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48455 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48449 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48459 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48460 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48456 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48450 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48448 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48452 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48454 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48451 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48458 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48453 SYN_RECV- tcp0 0 127.0.0.1:8009 127.0.0.1:48447 SYN_RECV- tcp0 0 207.137
Re: API call to reload Tomcat web application
Sorry I didn't mean to say ActionServlet or ModuleConfig objects...these are
struts based objects.. more generally, from within a Tomcat web
application... how do you access the Context object?
Thanks
Jamie
jamieb wrote:
>
> Hi There
>
> I had a look at Tomcat's Manager application the reload(..) function
> reveals a hint:
> ..
> Context context = (Context) host.findChild(path);
> ..
> context.reload();
>
> This should do the trick? Any idea on how to get the tomcat context
> object... from ActionServlet or ModuleConfig objects...? I am not familar
> with Tomcat's object model.
>
> Many thanks
>
> Jamie
>
>
> /**
> * Reload the web application at the specified context path.
> *
> * @param writer Writer to render to
> * @param path Context path of the application to be restarted
> */
> protected void reload(PrintWriter writer, String path) {
>
> if (debug >= 1)
> log("restart: Reloading web application at '" + path + "'");
>
> if ((path == null) || (!path.startsWith("/") && path.equals("")))
> {
> writer.println(sm.getString("managerServlet.invalidPath",
> RequestUtil.filter(path)));
> return;
> }
> String displayPath = path;
> if( path.equals("/") )
> path = "";
>
> try {
> Context context = (Context) host.findChild(path);
> if (context == null) {
> writer.println(sm.getString
>("managerServlet.noContext",
>RequestUtil.filter(displayPath)));
> return;
> }
> // It isn't possible for the manager to reload itself
> if (context.getPath().equals(this.context.getPath())) {
> writer.println(sm.getString("managerServlet.noSelf"));
> return;
> }
> context.reload();
> writer.println
> (sm.getString("managerServlet.reloaded", displayPath));
> } catch (Throwable t) {
> log("ManagerServlet.reload[" + displayPath + "]", t);
> writer.println(sm.getString("managerServlet.exception",
> t.toString()));
> }
>
> }
>
>
> Pid-2 wrote:
>>
>> jamieb wrote:
>>> Hi
>>>
>>> Thanks for the tip. While I am very grateful for your advice, I am not
>>> sure
>>> I like either of the approaches. I was hoping just to call a Tomcat API
>>> function directly from my web application.
>>
>> Tomcat provides an API, in the form of JMX.
>>
>>> Is'nt there a method called restart() or something?
>>
>> I'm not aware of one, have you found one in the docs?
>>
>>> JMX seems like overkill since I do not need to
>>> control the application remotely. The application doing the calling is
>>> the
>>> application that needs to be restarted itself. Any further ideas?
>>
>> You haven't elaborated on how you're connecting to the box, but a simple
>> JMX app could be run from the command line, or another webapp on the
>> same server.
>>
>> I'd suggest that you would be better off if a different app called the
>> restart, as you'll never be able to recover (or notify afterwards) from
>> a failure if the app itself is down.
>>
>> p
>>
>>
>>
>>
>>> Thanks
>>> Jamie
>>>
>>>
>>> Pid-2 wrote:
jamieb wrote:
> Hi there
>
> I am busy implementing an auto update facility for a Tomcat web
> application.
> As part of the auto update process, the auto update code needs to
> unpack
> the
> changed class files and reload the Tomcat web application.
>
> I am aware that you can configure Tomcat to automatically reload the
> web
> application when class files are changed. I've decided against the use
> of
> this functionality for fear of unscheduled service disruption.
>
> My question: Is recommended way for a web application to apply an
> update
> to
> itself and restart itself? Is there an API call to reload the current
> Tomcat
> web application from within that application?
If app auto-reload facilities are switched off, you should be able to
replace WAR files safely*, and then use the built in JMX stuff to
restart the webapp in question.
(* If you're doing it from a remote location, be sure to send it to a
safe directory /then/ do an internal copy to replace the file, rather
than directly uploading to the target web app dir. Failed or slow
uploads won't cause problems then.)
You can also use the included Tomcat Ant tasks, I think, (see
bin/catalina-tasks.xml)
See also:
http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html
http://tomcat.apache.org/tomcat-6.0-doc/mbeans-descriptor-howto.html
The Tomcat manager app uses JMX AFAIK, so you could examine the
Re: API call to reload Tomcat web application
Hi There
I had a look at Tomcat's Manager application the reload(..) function
reveals a hint:
..
Context context = (Context) host.findChild(path);
..
context.reload();
This should do the trick? Any idea on how to get the tomcat context
object... from ActionServlet or ModuleConfig objects...? I am not familar
with Tomcat's object model.
Many thanks
Jamie
/**
* Reload the web application at the specified context path.
*
* @param writer Writer to render to
* @param path Context path of the application to be restarted
*/
protected void reload(PrintWriter writer, String path) {
if (debug >= 1)
log("restart: Reloading web application at '" + path + "'");
if ((path == null) || (!path.startsWith("/") && path.equals(""))) {
writer.println(sm.getString("managerServlet.invalidPath",
RequestUtil.filter(path)));
return;
}
String displayPath = path;
if( path.equals("/") )
path = "";
try {
Context context = (Context) host.findChild(path);
if (context == null) {
writer.println(sm.getString
("managerServlet.noContext",
RequestUtil.filter(displayPath)));
return;
}
// It isn't possible for the manager to reload itself
if (context.getPath().equals(this.context.getPath())) {
writer.println(sm.getString("managerServlet.noSelf"));
return;
}
context.reload();
writer.println
(sm.getString("managerServlet.reloaded", displayPath));
} catch (Throwable t) {
log("ManagerServlet.reload[" + displayPath + "]", t);
writer.println(sm.getString("managerServlet.exception",
t.toString()));
}
}
Pid-2 wrote:
>
> jamieb wrote:
>> Hi
>>
>> Thanks for the tip. While I am very grateful for your advice, I am not
>> sure
>> I like either of the approaches. I was hoping just to call a Tomcat API
>> function directly from my web application.
>
> Tomcat provides an API, in the form of JMX.
>
>> Is'nt there a method called restart() or something?
>
> I'm not aware of one, have you found one in the docs?
>
>> JMX seems like overkill since I do not need to
>> control the application remotely. The application doing the calling is
>> the
>> application that needs to be restarted itself. Any further ideas?
>
> You haven't elaborated on how you're connecting to the box, but a simple
> JMX app could be run from the command line, or another webapp on the
> same server.
>
> I'd suggest that you would be better off if a different app called the
> restart, as you'll never be able to recover (or notify afterwards) from
> a failure if the app itself is down.
>
> p
>
>
>
>
>> Thanks
>> Jamie
>>
>>
>> Pid-2 wrote:
>>> jamieb wrote:
Hi there
I am busy implementing an auto update facility for a Tomcat web
application.
As part of the auto update process, the auto update code needs to
unpack
the
changed class files and reload the Tomcat web application.
I am aware that you can configure Tomcat to automatically reload the
web
application when class files are changed. I've decided against the use
of
this functionality for fear of unscheduled service disruption.
My question: Is recommended way for a web application to apply an
update
to
itself and restart itself? Is there an API call to reload the current
Tomcat
web application from within that application?
>>> If app auto-reload facilities are switched off, you should be able to
>>> replace WAR files safely*, and then use the built in JMX stuff to
>>> restart the webapp in question.
>>>
>>> (* If you're doing it from a remote location, be sure to send it to a
>>> safe directory /then/ do an internal copy to replace the file, rather
>>> than directly uploading to the target web app dir. Failed or slow
>>> uploads won't cause problems then.)
>>>
>>>
>>>
>>> You can also use the included Tomcat Ant tasks, I think, (see
>>> bin/catalina-tasks.xml)
>>>
>>> See also:
>>>
>>> http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html
>>> http://tomcat.apache.org/tomcat-6.0-doc/mbeans-descriptor-howto.html
>>>
>>> The Tomcat manager app uses JMX AFAIK, so you could examine the source
>>> code if you wanted to customise your own utility.
>>>
>>>
>>> p
>>>
>>>
>>>
>>>
Much appreciate
Jamie
>>>
>>> -
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>
>
> ---
RE: UTF-8 encoding problems
thanks, will try the TcpMon -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 4:10 PM To: Tomcat Users List Subject: Re: UTF-8 encoding problems Thompson,Roger wrote: > I saw that--All it really says is to set URIEncoding="UTF-8" the tips > say to use POST-- cannot do in a RESTful service. Have you actually tried the test? Did it work? If you read the sample code it also points to a number of other things the service needs to do in terms of setting encoding etc. If the test works and your service doesn't then either you haven't configured the service properly, there is a bug in the framework or the filters are causing problems. I fixed a whole bunch of encoding issues a while back and there haven't been any bugs since. That isn't to say there aren't any - just that the odds of this being a Tomcat problem are pretty slim. You might want to take a look at TcpMon from the Apache Axis project. I have found it very useful when debugging similar issues. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UTF-8 encoding problems
Thompson,Roger wrote: I saw that--All it really says is to set URIEncoding="UTF-8" the tips say to use POST-- cannot do in a RESTful service. Have you actually tried the test? Did it work? If you read the sample code it also points to a number of other things the service needs to do in terms of setting encoding etc. If the test works and your service doesn't then either you haven't configured the service properly, there is a bug in the framework or the filters are causing problems. I fixed a whole bunch of encoding issues a while back and there haven't been any bugs since. That isn't to say there aren't any - just that the odds of this being a Tomcat problem are pretty slim. You might want to take a look at TcpMon from the Apache Axis project. I have found it very useful when debugging similar issues. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDBC access logging
Hello, I'm not certain if this message is more correctly posted to the TC dev list but I think this is more of an end user of TC kind of question... I'd like to use a database to consolidate my access logs (many servers). 1. Performance impact? I don't know if the Valve have any ability to process asynchronously. 2. I have extra columns in my log files right now (some cookies are logged onto the end as well as headers from a load balancer). How do I recompile the Valve so that I can test it out? (this might be for the dev list...) 3. I notice the columns on the table create have very small values (for instance, user is just 15 characters -- there's no set limit to my knowledge in the HTTP spec (I see a line limitation length of the base64 as being 76 chars per line but it's certainly not 15). I would like to enlarge these to be more generous so truncations don't occur. Does anyone foresee any problems? thanks, greg - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Help with TomCat 6.0 & SSI
> From: Steve Major [mailto:[EMAIL PROTECTED] > Subject: Re: Help with TomCat 6.0 & SSI > > Thanks very much, I believe I want an entry in my context.xml > something like: > >docBase="/usr/local/tomcat/server/webapps/myapplication"> > No, do not put elements in server.xml; that is strongly discouraged, and persists only for compatibility with older levels. Your element should go into your webapp's META-INF/context.xml file, but without the path and docBase attributes. Your webapp should be placed in webapps, not server/webapps (that directory doesn't exist in Tomcat 6). Don't forget to uncomment the for the ssi servlet in conf/web.xml. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help with TomCat 6.0 & SSI
Thanks very much, I believe I want an entry in my context.xml something like: Thanks again for getting me in the right direction. -Steve On Mar 17, 2008, at 2:59 PM, Mark Thomas wrote: Steve Major wrote: I don't have a servlets-ssi.renametojar file nor an existing servlets-ssi.jar. I downloaded various versions of 6.0.x and it doesn't appear to be a part of any of those archives. I can only find that file in archives of TomCat 5.5. You can ignore this. The classes you need are part of the standard distro. 2) I'm unsure about this part of the How To: "Only Contexts which are marked as privileged may use SSI features (see the privileged property of the Context element)." http://tomcat.apache.org/tomcat-6.0-doc/config/context.html Search for privileged. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat to Apache connection dies
Hi John, John Moore schrieb: Problem: The communication via mod_jk between Apache and Tomcat appears to suddenly become "exhausted" and cease to be available. Please have a look at your mod_jk log file and look for '[error]' messages. Around the error messages there should also be additional info messages giving some mor einfo about the root cause. Versions: apache-tomcat-5.5.23.tar.gz httpd-2.0.59.tar.gz tomcat-connectors-1.2.21-src.tar.gz managerx-5.5-1.7.2 CentOS 4.6 (final) OK, you could switch to mod_jk 1.2.26 so we don't have to check against any old bugs. 1.2.26 is now 3 months old and no major new bugs are known. Symptom: Apache suddenly reports that the "service is unavailable" when trying to serve a context from Tomcat. Frequency: Generally about once a month. It also can happen quicker if ManagerX is used with any frequency. I have about 10 different webapps running. Restarting Tomcat does nothing, Restarting both Apache and Tomcat does nothing.. ONLY rebooting the machine will get everything back working. That sounds really weird. If you stop and start Apache httpd and Tomcat (i.e. all processes completely stopped, wait a few seconds and then started freshly), those processes should not have any more knowledge of previous problems. Possibly related information: netstat -np --tcp reports dozens of "dead" connections to port 8009, like the following samples: (count in parens to save space here): tcp0 0 127.0.0.1:8009 127.0.0.1:48461 SYN_RECV- (13) tcp0 6 127.0.0.1:48459 127.0.0.1:8009 FIN_WAIT1 - (3) tcp6 0 :::127.0.0.1:8009 :::127.0.0.1:48191 CLOSE_WAIT - (50) The CLOSE_WAIT most likely come from the fact, that you use a connect_timeout (that's fine) for mod_jk, but have no connectionTimeout on teh Toncat side. Set connectionTimeout in the Tomcat sidfe in the AJP connector to 60 (milliseconds). The SYN_RECV seem to indicate, that your Tomcat is not able to accept any more connections. Two possible reasons: - all threads in the thread pool of your AJP connector (Tomcat side) are already connected with httpd and no more threads are left. E.g. in your case it could be, that 50 threads are connected and maybe the size of your thread pool is 50? - you got an exception during creation of a new thread for the pool, and as a consequence your Tomcat is not listening any more. Can you see the LISTEN for 8009 in netstat? If no, the most likely cause is, that your JVM exceeded the number of threads that it can create (most 32 Bit JVMs: something between 400 and 500). If the problem happens again: check to see, if you can telnet to the TC port (telnet localhost 8009). If no, then mod_jk also has no chance of connecting to the Tomcat and we must find out, why Tomcat doesn't accept any more connections. In that case a thread dump of the Tomcat java process is helpful (kill -QUIT, result goes to catalin.out). and NO established connections even when attempting to access a service on Tomcat I attempted to work on various settings in the worker.properties file under the assumption that this is the key area to try and solve the problem based on a number of messages here and at other venues. I'm assuming I still do not have it right, but have exhausted my understanding of the causes.. worker.properties: worker.list=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.cachesize=30 Although we still respect that old name "cachesize", it got deprecated in the meantime and since you work with Apache httpd we recommend to drop this. The maximum connection pool size will be automatically adjusted w.r.t. the number of threads per Apache httpd process. worker.ajp13.socket_timeout=120 See if it helps to drop the socket_timeout. worker.ajp13.connection_pool_timeout=600 worker.ajp13.connect_timeout=7000 worker.ajp13.prepost_timeout=7000 worker.ajp13.reply_timeout=6 All OK. worker.ajp13.recycle_timeout=120 Again deprecated. Replaced by connection_pool_timeout above. Remove. See: http://tomcat.apache.org/connectors-doc/reference/workers.html worker.ajp13.retries=3 Anyone have some suggestions as to how to solve this problem.. It is rendering my production machines nearly useless.. > Thank You! John.. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: UTF-8 encoding problems
I saw that--All it really says is to set URIEncoding="UTF-8" the tips say to use POST-- cannot do in a RESTful service. -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 2:58 PM To: Tomcat Users List Subject: Re: UTF-8 encoding problems Thompson,Roger wrote: > WHere else besides the connector definition in the server.xml, should I look to find this. The implementor of the SRW/U code is convinced that the problem is in tomcat some where as he does not get this same error. http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q4 Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat to Apache connection dies
Problem: The communication via mod_jk between Apache and Tomcat appears to suddenly become "exhausted" and cease to be available. Versions: apache-tomcat-5.5.23.tar.gz httpd-2.0.59.tar.gz tomcat-connectors-1.2.21-src.tar.gz managerx-5.5-1.7.2 CentOS 4.6 (final) Symptom: Apache suddenly reports that the "service is unavailable" when trying to serve a context from Tomcat. Frequency: Generally about once a month. It also can happen quicker if ManagerX is used with any frequency. I have about 10 different webapps running. Restarting Tomcat does nothing, Restarting both Apache and Tomcat does nothing.. ONLY rebooting the machine will get everything back working. Possibly related information: netstat -np --tcp reports dozens of "dead" connections to port 8009, like the following samples: (count in parens to save space here): tcp0 0 127.0.0.1:8009 127.0.0.1:48461 SYN_RECV- (13) tcp0 6 127.0.0.1:48459 127.0.0.1:8009 FIN_WAIT1 - (3) tcp6 0 :::127.0.0.1:8009 :::127.0.0.1:48191 CLOSE_WAIT - (50) and NO established connections even when attempting to access a service on Tomcat I attempted to work on various settings in the worker.properties file under the assumption that this is the key area to try and solve the problem based on a number of messages here and at other venues. I'm assuming I still do not have it right, but have exhausted my understanding of the causes.. worker.properties: worker.list=ajp13 worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.cachesize=30 worker.ajp13.socket_timeout=120 worker.ajp13.connection_pool_timeout=600 worker.ajp13.connect_timeout=7000 worker.ajp13.prepost_timeout=7000 worker.ajp13.reply_timeout=6 worker.ajp13.recycle_timeout=120 worker.ajp13.retries=3 Anyone have some suggestions as to how to solve this problem.. It is rendering my production machines nearly useless.. Thank You! John.. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help with TomCat 6.0 & SSI
Steve Major wrote: I don't have a servlets-ssi.renametojar file nor an existing servlets-ssi.jar. I downloaded various versions of 6.0.x and it doesn't appear to be a part of any of those archives. I can only find that file in archives of TomCat 5.5. You can ignore this. The classes you need are part of the standard distro. 2) I'm unsure about this part of the How To: "Only Contexts which are marked as privileged may use SSI features (see the privileged property of the Context element)." http://tomcat.apache.org/tomcat-6.0-doc/config/context.html Search for privileged. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UTF-8 encoding problems
Thompson,Roger wrote: WHere else besides the connector definition in the server.xml, should I look to find this. The implementor of the SRW/U code is convinced that the problem is in tomcat some where as he does not get this same error. http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q4 Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set a maximun log size?
Tomás Tormo wrote: Hello I'm a newbie Tomcat user and my catalina.out log file is getting too big. How could I set a maximun size in order to force Tomcat to build a new one when the maximun size is reached? I've been searching on the internet but nothing matches what i want to do. http://wiki.apache.org/tomcat/FAQ/Logging#Q4 Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help with TomCat 6.0 & SSI
Hello, I'm new to the list and fairly new to TomCat. I've used it to deploy simple apps, but now need to get some SSI involved. I've followed the How To located here: http://tomcat.apache.org/tomcat-6.0-doc/ssi-howto.html Two problems: 1) when modifying my web.xml conf as instructed, that file says: I don't have a servlets-ssi.renametojar file nor an existing servlets- ssi.jar. I downloaded various versions of 6.0.x and it doesn't appear to be a part of any of those archives. I can only find that file in archives of TomCat 5.5. 2) I'm unsure about this part of the How To: "Only Contexts which are marked as privileged may use SSI features (see the privileged property of the Context element)." Can someone point me in the right direction as to what this means? It seems to indicate that my deployed apps will have to be given permission to use SSI, but I'm not sure where to configure this. Thanks in advance, -Steve - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
UTF-8 encoding problems
Environment: Tomcat 5.5.20, no apache frontend. Running XSLTFIlter and urlrewrite in front of the tomcat. WE are implementing a RESTful webservice (tspilot) on top of a SRU service on the connector going into tomcat I have: Problem: Somewhere in tomcat the UTF-8 encoded chatacters are getting munged. For example, one query has a accented a as in: Romans à clef. this goes through XSLTFilter and Urlrewrite and comes out (partially) /gsafd/?query=oclcts.terms+%3D+%22Romans+a%CC%80+clef%22&version=1.1&operation ... somewhere in tomcat the cc 80 get munged into c3 8c c2 80. WHere else besides the connector definition in the server.xml, should I look to find this. The implementor of the SRW/U code is convinced that the problem is in tomcat some where as he does not get this same error.
Session valueUnbound
We're trying to avoid the execution of valueUnbound(), when a Tomcat instance is stopped in a cluster environment. Can this be done by checking whether the thread that is executing valueUnbound() is a daemon or not? In the tests we have performed, the only thread running valueUnbound(), which is not a daemon, is the one responsible for Tomcat shutdown (which only runs valueUnbound() in a non persistent session environment), but we're trying to ensure this is the/a correct way of doing it. Thank you.
Re: Simple File Server
Kelly.Graus wrote: Hello, I am trying to write a simple file server web app. Basically, an administrator can log in and upload files, and a user can log in and download files that the administrator has given him access to. I know how to do the file uploading and downloading, what I really need to know is where to actually put the files when they have been uploaded. Is there a best practice for this sort of thing? Are there certain locations that are off-limits to Tomcat? Why re-invent the wheel. Check out: http://jackrabbit.apache.org/ http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/servlets/WebdavServlet.html -- Regards Gabe Wong NGASI AppServer Manager JAVA AUTOMATION and SaaS Enablement http://www.ngasi.com NEW! 8.0 - Centrally manage multiple physical servers - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: about java.lang.outofmemory error
If I understand the situation right, the sum total of all memory demands (both tomcat's and others) exceded the sum of all memory on the system, both real and virtual. Reducing the memory allocation to tomcat dropped the total demand to a level the system could provide. If that's the case, you'll end up having to get a bigger box in the long run. Decreasing tomcat's memory will most likely be only a short term solution. --David Milanez, Marcus wrote: Ok... I don't want this thread to be any longer, but the fact is that we haven't configured the heap for mor space them physical plus swap. Anyway, I got it solved when we decreased initial memory and maximum memory. -Mensagem original- De: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 17 de março de 2008 12:16 Para: Tomcat Users List Assunto: RE: about java.lang.outofmemory error From: Milanez, Marcus [mailto:[EMAIL PROTECTED] Subject: RES: about java.lang.outofmemory error GC never (ever) ran and Tomcat proccess could never acquire the amout of memory we'd specified The fact that GC never ran is irrelevant. As someone else pointed out, you likely configured the heap for more space than the sum of real plus swap, thereby causing a failure when attempting to allocate pages for the process. Also be aware that the JVM wil throw an OOME for *any* resource failure, including such things as running out of file descriptors. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: about java.lang.outofmemory error
Ok... I don't want this thread to be any longer, but the fact is that we haven't configured the heap for mor space them physical plus swap. Anyway, I got it solved when we decreased initial memory and maximum memory. -Mensagem original- De: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 17 de março de 2008 12:16 Para: Tomcat Users List Assunto: RE: about java.lang.outofmemory error > From: Milanez, Marcus [mailto:[EMAIL PROTECTED] > Subject: RES: about java.lang.outofmemory error > > GC never (ever) ran and Tomcat proccess could never acquire the amout > of memory we'd specified The fact that GC never ran is irrelevant. As someone else pointed out, you likely configured the heap for more space than the sum of real plus swap, thereby causing a failure when attempting to allocate pages for the process. Also be aware that the JVM wil throw an OOME for *any* resource failure, including such things as running out of file descriptors. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Global Naming Resources
> From: Stephen Nelson-Smith [mailto:[EMAIL PROTECTED] > Subject: Global Naming Resources You didn't bother to tell us what Tomcat version you're using, so it's impossible to tell you exactly where the dependencies are or what to do about them. Search for references to the names of the defined resources. Happy hunting. > Defines resources available to all webapps, should they choose to use them > type="java.lang.Integer" value="30"/> The above is used by one or more of the sample webapps that come with the Tomcat download. > type="org.apache.catalina.UserDatabase"/> The above and the rest of the global resources setting specifies the attributes for the data used by the default authentication realm, not only for Tomcat's manager and admin apps, but also by any other webapp that is configured for container-managed authentication and doesn't supply its own realm (e.g., Lambda Probe). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DelegatingCallableStatement.getInnermostDelegate() -- NoSuchMethodError
> -Original Message- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 15, 2008 5:09 PM > To: Tomcat Users List > Subject: Re: DelegatingCallableStatement.getInnermostDelegate() -- > NoSuchMethodError > > This looks like a signature from dbcp 1.1. Are you sure you used dbcp > 1.2+ when you compiled the classes below? In dbcp 1.1, > getInnermostDelegate is implemented in DelegatingCallableStatement and > it returns a CallableStatement. In 1.2, inheritance is as you > describe and this method returns a Statement (which you need to cast > to CallableStatement). That was it. That was also the one possibility I hadn't considered :-) Thanks for the assistance. IMPORTANT NOTICE: This message may contain confidential information. If you have received this e-mail in error, do not use, copy or distribute it. Do not open any attachments. Delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API call to reload Tomcat web application
jamieb wrote: Hi Thanks for the tip. While I am very grateful for your advice, I am not sure I like either of the approaches. I was hoping just to call a Tomcat API function directly from my web application. Tomcat provides an API, in the form of JMX. Is'nt there a method called restart() or something? I'm not aware of one, have you found one in the docs? JMX seems like overkill since I do not need to control the application remotely. The application doing the calling is the application that needs to be restarted itself. Any further ideas? You haven't elaborated on how you're connecting to the box, but a simple JMX app could be run from the command line, or another webapp on the same server. I'd suggest that you would be better off if a different app called the restart, as you'll never be able to recover (or notify afterwards) from a failure if the app itself is down. p Thanks Jamie Pid-2 wrote: jamieb wrote: Hi there I am busy implementing an auto update facility for a Tomcat web application. As part of the auto update process, the auto update code needs to unpack the changed class files and reload the Tomcat web application. I am aware that you can configure Tomcat to automatically reload the web application when class files are changed. I've decided against the use of this functionality for fear of unscheduled service disruption. My question: Is recommended way for a web application to apply an update to itself and restart itself? Is there an API call to reload the current Tomcat web application from within that application? If app auto-reload facilities are switched off, you should be able to replace WAR files safely*, and then use the built in JMX stuff to restart the webapp in question. (* If you're doing it from a remote location, be sure to send it to a safe directory /then/ do an internal copy to replace the file, rather than directly uploading to the target web app dir. Failed or slow uploads won't cause problems then.) You can also use the included Tomcat Ant tasks, I think, (see bin/catalina-tasks.xml) See also: http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html http://tomcat.apache.org/tomcat-6.0-doc/mbeans-descriptor-howto.html The Tomcat manager app uses JMX AFAIK, so you could examine the source code if you wanted to customise your own utility. p Much appreciate Jamie - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Simple File Server
Hello, I am trying to write a simple file server web app. Basically, an administrator can log in and upload files, and a user can log in and download files that the administrator has given him access to. I know how to do the file uploading and downloading, what I really need to know is where to actually put the files when they have been uploaded. Is there a best practice for this sort of thing? Are there certain locations that are off-limits to Tomcat? Thanks for any help! Kelly -- View this message in context: http://www.nabble.com/Simple-File-Server-tp16094821p16094821.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the best way to stop the tomcat daemon?
David Smith-2 wrote: > > You should have gotten a sample service shell script in you jsvc > source. Mine has this in the stop portion: > > jsvc -stop -pidfile $PID_FILE org.apache.catalina.startup.Bootstrap > > $PID_FILE is a shell variable containing the path of a file with the > process id of the running jsvc. I customized the sample service script > and dropped it in the /etc/init.d folder so I could use service tomcat55 > start|stop > > --David > > Works great. Thanks! Ethan -- View this message in context: http://www.nabble.com/What-is-the-best-way-to-stop-the-tomcat-daemon--tp16085458p16094692.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to set a maximun log size?
Hello I'm a newbie Tomcat user and my catalina.out log file is getting too big. How could I set a maximun size in order to force Tomcat to build a new one when the maximun size is reached? I've been searching on the internet but nothing matches what i want to do. Thank you very much - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: about java.lang.outofmemory error
> From: Milanez, Marcus [mailto:[EMAIL PROTECTED] > Subject: RES: about java.lang.outofmemory error > > GC never (ever) ran and Tomcat proccess could never > acquire the amout of memory we'd specified The fact that GC never ran is irrelevant. As someone else pointed out, you likely configured the heap for more space than the sum of real plus swap, thereby causing a failure when attempting to allocate pages for the process. Also be aware that the JVM wil throw an OOME for *any* resource failure, including such things as running out of file descriptors. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: RES: about java.lang.outofmemory error
Gabe, Quite like that. In my case, we didn't exceed the amout of physical memory available, but as our server shared its resources with other applications, it happened lots of times... -Mensagem original- De: Gabe Wong [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 17 de março de 2008 11:41 Para: Tomcat Users List Assunto: Re: RES: about java.lang.outofmemory error Milanez, Marcus wrote: > Chuck, > > Sorry if I haven't been clear enough, but we did have several situations in > which such a thing happened in production. We'd specified too much memory to > tomcat, and as our server shared its physical with other applications such as > IIS, GC never (ever) ran and Tomcat proccess could never acquire the amout of > memory we'd specified, causing java.lang.OutOfMemory error plenty of times. > We could just solve it decreasing tomcat's proccess initial and maximum > amount of memory, that's why I've warned about it. I really apologize if I'm > wrong, but is there another explanation for it? > > It sounds like in your case, you were allocating more memory to the JVM that was available from the system. Thus quite naturally when you lowered the allocation you encountered less problems. However if your application had indeed required the larger allocation, you would have experienced OutOfMemory. Point is, larger memory allocation is a good thing, but it cannot exceed what is available on the system. -- Regards Gabe Wong NGASI AppServer Manager JAVA AUTOMATION and SaaS Enablement http://www.ngasi.com NEW! 8.0 - Centrally manage multiple physical servers - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: about java.lang.outofmemory error
Milanez, Marcus wrote: Chuck, Sorry if I haven't been clear enough, but we did have several situations in which such a thing happened in production. We'd specified too much memory to tomcat, and as our server shared its physical with other applications such as IIS, GC never (ever) ran and Tomcat proccess could never acquire the amout of memory we'd specified, causing java.lang.OutOfMemory error plenty of times. We could just solve it decreasing tomcat's proccess initial and maximum amount of memory, that's why I've warned about it. I really apologize if I'm wrong, but is there another explanation for it? It sounds like in your case, you were allocating more memory to the JVM that was available from the system. Thus quite naturally when you lowered the allocation you encountered less problems. However if your application had indeed required the larger allocation, you would have experienced OutOfMemory. Point is, larger memory allocation is a good thing, but it cannot exceed what is available on the system. -- Regards Gabe Wong NGASI AppServer Manager JAVA AUTOMATION and SaaS Enablement http://www.ngasi.com NEW! 8.0 - Centrally manage multiple physical servers - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat on Leopard
Date sent: Mon, 17 Mar 2008 12:46:03 + From: Gareth Howells <[EMAIL PROTECTED]> Subject:Re: Tomcat on Leopard To: Tomcat Users List Send reply to: Tomcat Users List > > The OP should use either vi (if they're brave or have experience in > > it) > > nano is available on OS X too > TextWrangler is a nice, free text editor for Mac that supports a few programming languages also. http://www.barebones.com/products/textwrangler/ -Steve O. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: API call to reload Tomcat web application
Hi Thanks for the tip. While I am very grateful for your advice, I am not sure I like either of the approaches. I was hoping just to call a Tomcat API function directly from my web application. Is'nt there a method called restart() or something? JMX seems like overkill since I do not need to control the application remotely. The application doing the calling is the application that needs to be restarted itself. Any further ideas? Thanks Jamie Pid-2 wrote: > > jamieb wrote: >> Hi there >> >> I am busy implementing an auto update facility for a Tomcat web >> application. >> As part of the auto update process, the auto update code needs to unpack >> the >> changed class files and reload the Tomcat web application. >> >> I am aware that you can configure Tomcat to automatically reload the web >> application when class files are changed. I've decided against the use of >> this functionality for fear of unscheduled service disruption. >> >> My question: Is recommended way for a web application to apply an update >> to >> itself and restart itself? Is there an API call to reload the current >> Tomcat >> web application from within that application? > > If app auto-reload facilities are switched off, you should be able to > replace WAR files safely*, and then use the built in JMX stuff to > restart the webapp in question. > > (* If you're doing it from a remote location, be sure to send it to a > safe directory /then/ do an internal copy to replace the file, rather > than directly uploading to the target web app dir. Failed or slow > uploads won't cause problems then.) > > > > You can also use the included Tomcat Ant tasks, I think, (see > bin/catalina-tasks.xml) > > See also: > > http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html > http://tomcat.apache.org/tomcat-6.0-doc/mbeans-descriptor-howto.html > > The Tomcat manager app uses JMX AFAIK, so you could examine the source > code if you wanted to customise your own utility. > > > p > > > > >> Much appreciate >> >> Jamie >> >> > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/API-call-to-reload-Tomcat-web-application-tp16065357p16092888.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: about java.lang.outofmemory error
Chuck, Sorry if I haven't been clear enough, but we did have several situations in which such a thing happened in production. We'd specified too much memory to tomcat, and as our server shared its physical with other applications such as IIS, GC never (ever) ran and Tomcat proccess could never acquire the amout of memory we'd specified, causing java.lang.OutOfMemory error plenty of times. We could just solve it decreasing tomcat's proccess initial and maximum amount of memory, that's why I've warned about it. I really apologize if I'm wrong, but is there another explanation for it? Thank you! -Mensagem original- De: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 17 de março de 2008 11:06 Para: Tomcat Users List Assunto: RE: about java.lang.outofmemory error > From: Milanez, Marcus [mailto:[EMAIL PROTECTED] > Subject: RES: about java.lang.outofmemory error > > Just be aware that increasing memory isn't always the best option. In > most cases you should decrease memory instead, giving GC a chance to > run. If you increase memory, it may never run (realising unused > resources) and your process may never be able to allocate the amount > you specify... The above is confused and erroneous. GC will run automatically before any OOME is thrown, freeing up as much memory as is possible, including soft references. If you are referring to balancing heap space against non-heap space within the total process address space, GC has no effect, since the maximum heap size is reserved (but not allocated) at JVM initialization. There's no such thing as "giving GC a chance to run"; it will run, whenever it needs to. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Global Naming Resources
Hello, What is this for: factory org.apache.catalina.users.MemoryUserDatabaseFactory pathname conf/tomcat-users.xml It seems to provide the user database used by the web-based admin tools. I don't use there, and my application doesn't either, but if I remove the above, tomcat doesn't start. What is the dependency? S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: about java.lang.outofmemory error
> From: Milanez, Marcus [mailto:[EMAIL PROTECTED] > Subject: RES: about java.lang.outofmemory error > > Just be aware that increasing memory isn't always the best > option. In most cases you should decrease memory instead, > giving GC a chance to run. If you increase memory, it may > never run (realising unused resources) and your process may > never be able to allocate the amount you specify... The above is confused and erroneous. GC will run automatically before any OOME is thrown, freeing up as much memory as is possible, including soft references. If you are referring to balancing heap space against non-heap space within the total process address space, GC has no effect, since the maximum heap size is reserved (but not allocated) at JVM initialization. There's no such thing as "giving GC a chance to run"; it will run, whenever it needs to. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: about java.lang.outofmemory error
Hello, Just be aware that increasing memory isn't always the best option. In most cases you should decrease memory instead, giving GC a chance to run. If you increase memory, it may never run (realising unused resources) and your process may never be able to allocate the amount you specify... -Mensagem original- De: David Fisher [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 17 de março de 2008 10:43 Para: Tomcat Users List Assunto: Re: about java.lang.outofmemory error I don't know about BIRT (other than it is a project to generate Excel reports), but I do know that in Apache POI when you read and write an Excel spreadsheet everything is done in memory, and a large amount of memory needs to be available if your spreadsheet is large. I add the following to my catalina.sh to increase memory: -Xms384m -Xmx724m I hope this helps, there are limits. Regards, Dave On Mar 17, 2008, at 8:05 AM, hns wrote: > > hi > i have developed one web application which contains eclipse birt 2.2 > it runs sucessfuly from 2 months but now while data inceresse it cause > problem of showing one report and gives error java.lang.outofmemory > error i have used tomcat 5.5.25 and jdk 1.5 i feel this is the problem > of tomcat 5.5 memory allocation could it solved any way please help me > -- > View this message in context: http://www.nabble.com/about- > java.lang.outofmemory-error-tp16092575p16092575.html > Sent from the Tomcat - User mailing list archive at Nabble.com. > > > - > To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, > e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: about java.lang.outofmemory error
I don't know about BIRT (other than it is a project to generate Excel reports), but I do know that in Apache POI when you read and write an Excel spreadsheet everything is done in memory, and a large amount of memory needs to be available if your spreadsheet is large. I add the following to my catalina.sh to increase memory: -Xms384m -Xmx724m I hope this helps, there are limits. Regards, Dave On Mar 17, 2008, at 8:05 AM, hns wrote: hi i have developed one web application which contains eclipse birt 2.2 it runs sucessfuly from 2 months but now while data inceresse it cause problem of showing one report and gives error java.lang.outofmemory error i have used tomcat 5.5.25 and jdk 1.5 i feel this is the problem of tomcat 5.5 memory allocation could it solved any way please help me -- View this message in context: http://www.nabble.com/about- java.lang.outofmemory-error-tp16092575p16092575.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: about java.lang.outofmemory error
> From: hns [mailto:[EMAIL PROTECTED] > Subject: about java.lang.outofmemory error > > i feel this is the problem of tomcat 5.5 memory allocation Extremely unlikely. The most probable cause is either a memory leak in your webapp or you simply have too much data for whatever size heap you have specified. Read the FAQ: http://wiki.apache.org/tomcat/FAQ/Memory - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
about java.lang.outofmemory error
hi i have developed one web application which contains eclipse birt 2.2 it runs sucessfuly from 2 months but now while data inceresse it cause problem of showing one report and gives error java.lang.outofmemory error i have used tomcat 5.5.25 and jdk 1.5 i feel this is the problem of tomcat 5.5 memory allocation could it solved any way please help me -- View this message in context: http://www.nabble.com/about-java.lang.outofmemory-error-tp16092575p16092575.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Many Java Processes
On Thu, Mar 13, 2008 at 1:02 PM, Christopher Schultz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stephen, > > > Stephen Nelson-Smith wrote: > | I've noticed on one machine (4.1.31 / RHEL 3) as soon as I start Java > | I see many Java processes: > > These are threads, not processes. Some Linux kernel versions report them > as processes, and some don't. It also may depend on your version of ps > (or pgrep, in this case). Aha, well the one which reports threads as processes is procps-2.0.13-9.2E. The one that doesn't is procps-2.0.17-13.10. After upgrading procps, I don't see this behaviour. Thanks for the hint! S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat on Leopard
The OP should use either vi (if they're brave or have experience in it) nano is available on OS X too - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cluster problem (sessions lost)
Hello, I have this problem in which there is very little data to get to a solution. - Running a 5 node cluster of 5.5.23 on java 1.5.0_10. Debian 4.0 and kernel 2.6.22.18-SMP. - It runs behind a Linux LVS which balances the connections over the cluster. - Attached is my server.xml. - Sessions last for 8 hours, so customers can make a full workday while staying logged in. This has run very stable for months. Nothing changed in handling sessions. The rest of the fixes were very small last weeks and I reviewed them more than ones and nothing related to sessions happened. But since two weeks a lot of users are logged out now and than. This happens in bursts I think. If I restart every node in the cluster the problem disappears for a while (a day or a couple of hours). Last week I upgraded to 5.5.26, but the problem is still there. The logs give no errors. I'm running Tomcat clusters for a couple of years now and solved a couple of problems with them, but now I have no clue in any logs about what is happening except users don't have a session anymore. (Possibly sessions aren't shared very well and after a 'load re-balancing' users get on a server which doesn't know the session.) Are there any tips? How can I start debugging this? Is there a way to verify all servers have the same sessions? Ronald. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
