Re: Tomcat Java Settings for each webapps, and virtual host strange issue.
On 26/12/2013 04:30, Peter wrote: Hi all, I am having strange issues with tomcat 7 as well as tomcat 8, following is details of that issue, please someone help me to configure java for each webapps You can't do that. You can only have one version of Java per OS process / Tomcat instance. If you want different Java versions for different web applications you need to have separate Tomcat instances. Marl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Java Settings for each webapps, and virtual host strange issue.
Peter wrote: Hi all, I am having strange issues with tomcat 7 as well as tomcat 8, following is details of that issue, please someone help me to configure java for each webapps Thanks for all the detailed information. But I believe that you have things the wrong way around. It is not a question of the webapp (or Tomcat) choosing its Java JVM. If you look at the way in which Tomcat is being started (script in /etc/init.d or (tomcat_dir)/bin/startup.sh), you will see that the command being run is java, followed by parameters which tell this java which Java code modules to run. (And not the other way around). From the OS point of view, the process which really runs on your computer is a JVM (Java Virtual Machine) (./java or whatever). Once you start this particular JVM process, you tell it to load and run some Java code : in this case, a Tomcat java code module. This Java code then starts to run (inside the JVM), and it reads its configuration files (server.xml etc.) to set itself up. This includes which TCP/IP ports it should be listening on, which Hosts and webapps it should load and configure etc. You can start and run several (identical or different) JVM's concurrently, as distinct processes within your OS, and you can tell each one to run a different set of Java code modules : e.g. another Tomcat instance with different parameters, different Hosts and different webapps. (As long as the different instances do not conflict with one another, for example by trying to use the same TCP/IP ports). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
V 7 047 windows x64
Hi, I can't use EL in .jsp files. I have searched the web and sintalled jasper-el.jar and javaee-api 7 0 in the \lib directory, but I keep getting the ELResolver error.
Re: V 7 047 windows x64
JB MORLA wrote: Hi, I can't use EL in .jsp files. I have searched the web and sintalled jasper-el.jar and javaee-api 7 0 in the \lib directory, but I keep getting the ELResolver error. Hi. You would have a much higher probability of getting useful and quick help, if you pasted the original corresponding Tomcat error log lines in your message, like here : (Note: really do a cut-and-paste directly in your mail message to the list. Do not attach the error log as attachment. This list strips most attachments). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
apache tomcat serialization
It appears new revisions of tomcat (current for sure) are much more sensitive to keeping serialized data BETWEEN restarts. I have to wait at least 30 minutes to properly restart my applications. In the OLD days $CATALINA_HOME/work/Catalina/localhost/appName/*.ser was where things were kept and I could remove these files before a startup. I no longer see these files and I am sure they are someplace. I have a couple java beans that are application wide resources. So tomcat does NOT complain, they are compiled saying they can be serialized (they can while the app is running, but not between shutdown/startup. It it these beans which I really do not want OLD copies found when tomcat restarts. But there is no reason to keep ANY serialized data between tomcat instances. Can anyone tell me how to tell tomcat to NOT use old serialized data at startup? OR How to delete it so it cannot be found? I run on fedora. Thanks
Ping_mode
Hi guys, Can you plz help me in understand that under what circumstances i should use ping_mode attribute in worker.properties. Actually i dont understand that how it will make the applications more reliable because as per my understanding if apache-tomcat connection results in failure then mod_jk will fallback try connecting with another tomcat jvm. when this is happening automatically then what is the point of configuring ping_mode Please enlighten me Thanks, Vicky
Re: Tomcat Java Settings for each webapps, and virtual host strange issue.
Thanks *Mark,* Martin Gainty, André Warnier for you time As some of you suggested I need to have different tomcat for different java version Do you mean if I have 2 webapps, which works on 2 difference java versions then, do I have to create 2 tomcat folders ? like this /tomcat7_copy1 ---www.host1.com bin setenv.sh java version1 for app1 start.sh stop.sh conf logs server webapps --- app1 work /tomcat8_copy2 ---www.host2.com bin setenv.sh java version2 for app2 start.sh stop.sh conf logs server webapps --- app2 work if this is what you said, I suspect tomcat will get confused I think, please guide me how can create 2 hosts ? for instance I want to do like this, port should be 80 tomcat7_copy1 as www.host1.com tomcat8_copy2 as www.host2.com what will be the configuration, I suspect system will be confused with 2 versions of java, may be PID configuration is needed to solve conflict, but I have no much idea about this tomcat and java. what will be server.xml ? what will be setenv.sh ? what I expect from you people is if I type *www.host1.com http://www.host1.com* on browser I should get *tomcat7 default index page*, and for *www.host2.com http://www.host2.com* I should get *tomcat8 default index page*, both should work simultaneously without any disturbance like, suppose if I run stop.sh of tomcat7, it should not disturb tomcat8. Hope my requirement is clear to all of you. Please help me. Thanks in advance. - Peter On Thu, Dec 26, 2013 at 2:42 PM, Mark Thomas ma...@apache.org wrote: On 26/12/2013 04:30, Peter wrote: Hi all, I am having strange issues with tomcat 7 as well as tomcat 8, following is details of that issue, please someone help me to configure java for each webapps You can't do that. You can only have one version of Java per OS process / Tomcat instance. If you want different Java versions for different web applications you need to have separate Tomcat instances. Marl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat auto deployer not working for ROOT applications
I am trying to deploy a web app as the ROOT application for Tomcat 7.0.35, running on Ubuntu 12 with Amazon EC2. 1) When I use auto-deploy using the Tomcat Deployer 'deploy' ant task (just downloaded the most recent version of the TCD libs) to a non-ROOT context name, such as /360Site, everything works as expected - war file is uploaded, decompressed to directory, and is immediately available. 2) When I use the manager HTML interface to upload the ROOT.war file by clicking the 'Select WAR file to upload' and then clicking 'deploy', everything works as expected. However, 3) When I do exactly the same thing as #1 (tomcat auto deploy) but just change the 'path' variable from /360Store to /ROOT, here is what happens: * WAR file appears in the webapps directory, but does not get expanded. * The webapp is not running (I get a blank page when I go to the URL in the browser) * I can go into the HTML manager page and click the 'start' button, and the webapp does successfully start (tested the URL in the browser), but the WAR file still does not get unpacked into a directory. * I see these entries in the catalina.date.log Dec 26, 2013 7:22:49 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war Dec 26, 2013 7:22:49 PM org.apache.catalina.startup.ContextConfig init SEVERE: Exception fixing docBase for context [] java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:214) at java.util.zip.ZipFile.init(ZipFile.java:144) at java.util.jar.JarFile.init(JarFile.java:153) at java.util.jar.JarFile.init(JarFile.java:90) at sun.net.www.protocol.jar.URLJarFile.init(URLJarFile.java:93) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:88) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:113) at org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:720) at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:843) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:387) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:977) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1655) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Dec 26, 2013 7:22:49 PM org.apache.catalina.core.StandardContext resourcesStart SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Invalid or unreadable WAR file : error in opening zip file at org.apache.naming.resources.WARDirContext.setDocBase(WARDirContext.java:138) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4912) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5092) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:977) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1655) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
Re: Tomcat Java Settings for each webapps, and virtual host strange issue.
On 12/26/2013 2:17 PM, Peter wrote: Thanks *Mark,* Martin Gainty, André Warnier for you time As some of you suggested I need to have different tomcat for different java version Do you mean if I have 2 webapps, which works on 2 difference java versions then, do I have to create 2 tomcat folders ? like this Not absolutely necessary, if Tomcat is able to run on both JREs that you are trying to use. For example, TC7 can run on both JRE6 and JRE7. So you just need to start separate instances of TC with the appropriate parameters to the correct JRE. However, it may be easier to manage if you have separate installations of TC for the different JRE versions. /tomcat7_copy1 ---www.host1.com bin setenv.sh java version1 for app1 start.sh stop.sh conf logs server webapps --- app1 work /tomcat8_copy2 ---www.host2.com bin setenv.sh java version2 for app2 start.sh stop.sh conf logs server webapps --- app2 work if this is what you said, I suspect tomcat will get confused I think, please guide me how can create 2 hosts ? for instance I want to do like this, port should be 80 Each instance of Tomcat needs to listen on a unique combination of IP address:port. So you can't have both TC instances listening on a.b.c.d:port1; the second one will fail to start in this case. One of them will need to listen on e.f.g.h:port1, or on a.b.c.d:port2. tomcat7_copy1 as www.host1.com tomcat8_copy2 as www.host2.com what will be the configuration, I suspect system will be confused with 2 versions of java, may be PID configuration is needed to solve conflict, but I have no much idea about this tomcat and java. what will be server.xml ? what will be setenv.sh ? what I expect from you people is if I type *www.host1.com http://www.host1.com* on browser I should get *tomcat7 default index page*, and for *www.host2.com http://www.host2.com* I should get *tomcat8 default index page*, both should work simultaneously without any disturbance like, suppose if I run stop.sh of tomcat7, it should not disturb tomcat8. Hope my requirement is clear to all of you. Your requirements are clear enough (except for the listening address:port), but you have a fair amount of work ahead of you to get it to do what you want. Please help me. Thanks in advance. - Peter On Thu, Dec 26, 2013 at 2:42 PM, Mark Thomas ma...@apache.org wrote: On 26/12/2013 04:30, Peter wrote: Hi all, I am having strange issues with tomcat 7 as well as tomcat 8, following is details of that issue, please someone help me to configure java for each webapps You can't do that. You can only have one version of Java per OS process / Tomcat instance. If you want different Java versions for different web applications you need to have separate Tomcat instances. Marl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
On Dec 23, 2013, at 12:50 PM, Konstantin Preißer kpreis...@apache.org wrote:
In that case, the stacktrace would show that the Exception is thrown in the
webapp's code (and if the Exception is created using a cause, it would show a
Caused by: ... stacktrace showing the original source).
However, the stacktrace from Jesse shows that the EOFException is thrown by
Tomcat's AjpNioProcessor class:
java.io.EOFException
at
org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:358)
at
org.apache.coyote.ajp.AjpNioProcessor.read(AjpNioProcessor.java:314)
at
org.apache.coyote.ajp.AjpNioProcessor.readMessage(AjpNioProcessor.java:406)
at
org.apache.coyote.ajp.AjpNioProcessor.receive(AjpNioProcessor.java:375)
at
org.apache.coyote.ajp.AbstractAjpProcessor$SocketInputBuffer.doRead(AbstractAjpProcessor.java:1066)
at org.apache.coyote.Request.doRead(Request.java:422)
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:290)
at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:431)
at
org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:315)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:167)
at com.prosc.io.IOUtils.writeInputToOutput(IOUtils.java:49)
at com.prosc.io.IOUtils.inputStreamAsBytes(IOUtils.java:116)
at com.prosc.io.IOUtils.inputStreamAsString(IOUtils.java:136)
at com.prosc.io.IOUtils.inputStreamAsString(IOUtils.java:127)
at com.prosc.licensecheck.LicenseCheck.doPost(LicenseCheck.java:164)
[...]
Lines 351-361 of Tomcat 7.0.35's AjpNioProcessor#readSocket() are as follows:
351 if (nRead 0) {
352 socket.getBufHandler().getReadBuffer().flip();
353 socket.getBufHandler().getReadBuffer().limit(nRead);
354 socket.getBufHandler().getReadBuffer().get(buf, pos, nRead);
355 return nRead;
356 } else if (nRead == -1) {
357 //return false;
358 throw new EOFException(sm.getString(iib.eof.error));
359 } else {
360 return 0;
361 }
Line 358 throws the EOFException because there was no more data to read on
the AJP connection although (I think) the AJP connector expected the client
to send further data (the request body).
Regards,
Konstantin Preißer
Thanks Konstantin - it doesn't sound like this is a problem that I can do
anything about, other than to catch the exception and ignore it.
--Jesse Barnum, President, 360Works
http://www.360works.com
Product updates and news on http://facebook.com/360Works
(770) 234-9293
== Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==
Re: V 7 047 windows x64
I was testing the EL in a .jsp file under Eclipse Kepler. Now I copied the project files under c:\tomcat7\webapps and recompiled the java sources. And the EL works! So the EL problems are in the Eclipse Kepler setup. Many thanks for your reply. Jean On Thu, Dec 26, 2013 at 3:16 PM, André Warnier a...@ice-sa.com wrote: JB MORLA wrote: Hi, I can't use EL in .jsp files. I have searched the web and sintalled jasper-el.jar and javaee-api 7 0 in the \lib directory, but I keep getting the ELResolver error. Hi. You would have a much higher probability of getting useful and quick help, if you pasted the original corresponding Tomcat error log lines in your message, like here : (Note: really do a cut-and-paste directly in your mail message to the list. Do not attach the error log as attachment. This list strips most attachments). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Request Timeout and empty post data issue
Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Is there some other timeout value somewhere that defaults to 20 seconds? Is there a way for me to see exactly what is taking so long? Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. I'd appreciate any ideas on what could cause this. Thanks, Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: V 7 047 windows x64
Date: Thu, 26 Dec 2013 21:24:27 +0100 Subject: Re: V 7 047 windows x64 From: jbmo...@gmail.com To: users@tomcat.apache.org I was testing the EL in a .jsp file under Eclipse Kepler. Now I copied the project files under c:\tomcat7\webapps and recompiled the java sources. And the EL works! So the EL problems are in the Eclipse Kepler setup. MGthen you should contact the support staff at Eclipse to let them know of this significant bug in Kepler Many thanks for your reply. Jean On Thu, Dec 26, 2013 at 3:16 PM, André Warnier a...@ice-sa.com wrote: JB MORLA wrote: Hi, I can't use EL in .jsp files. I have searched the web and sintalled jasper-el.jar and javaee-api 7 0 in the \lib directory, but I keep getting the ELResolver error. Hi. You would have a much higher probability of getting useful and quick help, if you pasted the original corresponding Tomcat error log lines in your message, like here : (Note: really do a cut-and-paste directly in your mail message to the list. Do not attach the error log as attachment. This list strips most attachments). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Request Timeout and empty post data issue
Hi, -Original Message- From: Peter Rifel [mailto:pri...@mixpo.com] Sent: Thursday, December 26, 2013 9:45 PM To: users@tomcat.apache.org Subject: Request Timeout and empty post data issue Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Is there some other timeout value somewhere that defaults to 20 seconds? Is there a way for me to see exactly what is taking so long? Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. I'd appreciate any ideas on what could cause this. Did you try to set the connectionTimeout to some other value to see if the requests still take ~ 20s? I just tested with Tomcat 7.0.47 and HTTP APR connector, and for me the connectionTimeout value is also applied when reading the POST data: When the client does not send a byte in this interval (20s), then this will trigger some timeout error. E.g., if you send the following POST request without a body (2x CR LF after the last header): POST /MyWebapp/PostServlet HTTP/1.1 Host: localhost Connection: keep-alive Content-Length: 999 Content-Type: application/x-www-form-urlencoded Then after the connectionTimeout interval, an java.net.SocketTimeoutException occurs at org.apache.catalina.connector.CoyoteInputStream.read (e.g. when you directly read the Request input stream), so that Tomcat doesn't wait forever for further data when the client is already gone. Note that the exception did not occur when I called request.getParameter(xxx) - it just returned null. It could be possible that a client sends a request with complete headers, but when sending the POST body the client waits too long so that Tomcat applies the connectionTimeout before the full request body is received. The request will then be logged as the request headers where completely received. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Java Settings for each webapps, and virtual host strange issue.
Peter wrote: Thanks *Mark,* Martin Gainty, André Warnier for you time As some of you suggested I need to have different tomcat for different java version The very first question which you should maybe ask yourself (or the developers of the webapps), is *why* these webapps require different Java versions. It should not be so. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Request Timeout and empty post data issue
-Original Message- From: Konstantin Preißer [kpreis...@apache.org] Sent: Thursday, December 26, 2013 1:28 PM To: 'Tomcat Users List' Subject: RE: Request Timeout and empty post data issue Hi, -Original Message- From: Peter Rifel [mailto:pri...@mixpo.com] Sent: Thursday, December 26, 2013 9:45 PM To: users@tomcat.apache.org Subject: Request Timeout and empty post data issue Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Is there some other timeout value somewhere that defaults to 20 seconds? Is there a way for me to see exactly what is taking so long? Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. I'd appreciate any ideas on what could cause this. Did you try to set the connectionTimeout to some other value to see if the requests still take ~ 20s? I just tested with Tomcat 7.0.47 and HTTP APR connector, and for me the connectionTimeout value is also applied when reading the POST data: When the client does not send a byte in this interval (20s), then this will trigger some timeout error. E.g., if you send the following POST request without a body (2x CR LF after the last header): POST /MyWebapp/PostServlet HTTP/1.1 Host: localhost Connection: keep-alive Content-Length: 999 Content-Type: application/x-www-form-urlencoded Then after the connectionTimeout interval, an java.net.SocketTimeoutException occurs at org.apache.catalina.connector.CoyoteInputStream.read (e.g. when you directly read the Request input stream), so that Tomcat doesn't wait forever for further data when the client is already gone. Note that the exception did not occur when I called request.getParameter(xxx) - it just returned null. It could be possible that a client sends a request with complete headers, but when sending the POST body the client waits too long so that Tomcat applies the connectionTimeout before the full request body is received. The request will then be logged as the request headers where completely received. Regards, Konstantin Preißer Konstantin, I changed the connectionTimeout and that value is being reflected in our access logs. So this means that tomcat is not receiving a body with the POST request, indicating a client-side or network problem? We never read the input stream directly, we only use getParameter so that would explain why our servlet isn't throwing a SocketTimeoutException. It would be nice if the connectionTimeout documentation could mention this scenario as well. Thank you for your quick response! Peter Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: V 7 047 windows x64
I think there is a little chance that Tomcat uses java.exe while Eclipse uses javaw I can see in the Windows task manager that it is not the same process. I'll try to find an Eclipse newsgroup. Many thanks Jean On Thu, Dec 26, 2013 at 9:46 PM, Martin Gainty mgai...@hotmail.com wrote: Date: Thu, 26 Dec 2013 21:24:27 +0100 Subject: Re: V 7 047 windows x64 From: jbmo...@gmail.com To: users@tomcat.apache.org I was testing the EL in a .jsp file under Eclipse Kepler. Now I copied the project files under c:\tomcat7\webapps and recompiled the java sources. And the EL works! So the EL problems are in the Eclipse Kepler setup. MGthen you should contact the support staff at Eclipse to let them know of this significant bug in Kepler Many thanks for your reply. Jean On Thu, Dec 26, 2013 at 3:16 PM, André Warnier a...@ice-sa.com wrote: JB MORLA wrote: Hi, I can't use EL in .jsp files. I have searched the web and sintalled jasper-el.jar and javaee-api 7 0 in the \lib directory, but I keep getting the ELResolver error. Hi. You would have a much higher probability of getting useful and quick help, if you pasted the original corresponding Tomcat error log lines in your message, like here : (Note: really do a cut-and-paste directly in your mail message to the list. Do not attach the error log as attachment. This list strips most attachments). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request Timeout and empty post data issue
Peter Rifel wrote: Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Is there some other timeout value somewhere that defaults to 20 seconds? Is there a way for me to see exactly what is taking so long? Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. I'd appreciate any ideas on what could cause this. Can't think of an answer yet, but what would help is if you posted the corresponding Connector configuration here. I am a bit puzzled by your description of the servlet filter above. How does it determine that the request has no POST parameters ? And how/what does it log to the Access log ? Also, can you get to the HTTP headers of the request, in this filter ? It may be useful to know what the request's Content-length header is saying. And one more thing : presumably, you know what kind of POST requests this is, or what it should be. What would a normal POST request of that kind look like ? For example if it was a valid/legitimate POST request of that kind from a valid/legitimate client (browser ?), how large could it be, as a maximum ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request Timeout and empty post data issue
One issue that will cause empty POST data to be received is if the POST data size exceeds the value in the server.xml file: http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html The maximum size in bytes of the POST which will be handled by the container FORM URL parameter parsing. The limit can be disabled by setting this attribute to a value less than or equal to 0. If not specified, this attribute is set to 2097152 (2 megabytes). It would also make sense that these larger POSTs would take longer, so it fits the evidence. --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Dec 26, 2013, at 3:45 PM, Peter Rifel pri...@mixpo.com wrote: Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Is there some other timeout value somewhere that defaults to 20 seconds? Is there a way for me to see exactly what is taking so long? Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. I'd appreciate any ideas on what could cause this. Thanks, Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Request Timeout and empty post data issue
From: André Warnier [a...@ice-sa.com]
Sent: Thursday, December 26, 2013 2:11 PM
To: Tomcat Users List
Subject: Re: Request Timeout and empty post data issue
Peter Rifel wrote:
Hello,
I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25.
I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6.
I'm noticing in my access logs that some of our POST requests don't have any
POST data and all have response times of a few ms over 2ms. I'm trying
to figure out whether this issue is client side or server side. The
response code and response size for these requests are normal. Can anyone
tell me under what circumstances this would happen? I noticed that our
connector's connectionTimeout is set to 2ms, but it wouldn't make sense
for that value to be a part of this issue because a connection timeout only
occurs when the URI hasn't been received by tomcat in that amount of time,
which is clearly not happening here (I was able to confirm this with telnet;
a connection timeout will not write anything to the access logs).
The request is making it to my servlet (logging confirms this) but for
some reason tomcat doesn't see any request parameters and all of the
response times in our access logs are just above 20 seconds. Does this mean
that my servlet is taking 20 seconds to process the request? Is there some
other timeout value somewhere that defaults to 20 seconds? Is there a way
for me to see exactly what is taking so long? Its incredibly hard to debug
this because we cant reproduce this bug on our own without any post data and
1% of our production traffic is having this issue. To try and gather more
info on this, I added a servlet filter that logs all of our POST request
parameters to the access log and I can confirm that there are no parameters
on these specific requests.
The lack of post data makes me think its a client issue, but that doesn't
explain why all of these requests take ~20 seconds to be processed.
I'd appreciate any ideas on what could cause this.
Can't think of an answer yet, but what would help is if you posted the
corresponding
Connector configuration here.
I am a bit puzzled by your description of the servlet filter above.
How does it determine that the request has no POST parameters ?
And how/what does it log to the Access log ?
Also, can you get to the HTTP headers of the request, in this filter ?
It may be useful to know what the request's Content-length header is saying.
And one more thing : presumably, you know what kind of POST requests this is,
or what it
should be. What would a normal POST request of that kind look like ?
For example if it was a valid/legitimate POST request of that kind from a
valid/legitimate
client (browser ?), how large could it be, as a maximum ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Here is the Connector configuration:
Connector executor=HttpThreadPool port=8080 protocol=HTTP/1.1
pollerSize=25000 pollerThreadCount=2
connectionTimeout=2 redirectPort=8443 server=MixpoServer
maxPostSize=10485760
compression=on
compressableMimeType=text/html,text/plain,text/xml,application/xml,text/javascript
noCompressionUserAgents=.*MSIE[56].*
/
The filter is a snippet I found online while trying to debug this that just
loops through the parameter names and values, creating a string:
public void doFilter(ServletRequest request, ServletResponse
response,FilterChain chain) throws IOException, ServletException {
EnumerationString names = request.getParameterNames();
StringBuffer output=new StringBuffer();
while (names.hasMoreElements()) {
String name = names.nextElement();
output.append(name+=);
String values[] = request.getParameterValues(name);
for (int i = 0; i values.length; i++) {
if (i 0) output.append(' );
output.append(values[i]);
}
if(names.hasMoreElements()) output.append();
}
request.setAttribute(postdata, output);
chain.doFilter(request, response);
}
Then I just added %{postdata}r to my access log valve format. If you know of
a better way of dumping POST data to a log of some sort without interfering
with the servlet I'm open for alternatives. I'll try and log the
Content-length header as well. The requests are made by a custom flash plugin
that runs on all browsers, the post data is only plaintext: just a handful of
name/value pairs.
Peter
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: apache tomcat serialization
On 26/12/2013 17:14, Ray Holme wrote: It appears new revisions of tomcat (current for sure) are much more sensitive to keeping serialized data BETWEEN restarts. I have to wait at least 30 minutes to properly restart my applications. Nope. Nothing has changed in the session serialization code since the Tomcat 4.1.x days. It still works exactly the same way. In the OLD days $CATALINA_HOME/work/Catalina/localhost/appName/*.ser was where things were kept and I could remove these files before a startup. I no longer see these files and I am sure they are someplace. Only if you have configured Tomcat to place them somewhere else. I have a couple java beans that are application wide resources. So tomcat does NOT complain, they are compiled saying they can be serialized (they can while the app is running, but not between shutdown/startup. It it these beans which I really do not want OLD copies found when tomcat restarts. But there is no reason to keep ANY serialized data between tomcat instances. I assume you are placing these beans in the session. Can anyone tell me how to tell tomcat to NOT use old serialized data at startup? Have you tried reading the manual for the session manager you are using? You could start here: http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html#Disable_Session_Persistence OR How to delete it so it cannot be found? If sessions are serialised, the file will be created wherever you tell Tomcat to create it. I run on fedora. Ah. If you are using a Fedora packaged version of Tomcat I suggest you direct your enquires to whomever maintains that package and ask them where they opted to move the session serialization files to. Alternatively you could remove the 3rd party packaged version of Tomcat, download Tomcat from the ASF and install it in your location of choice so you know exactly where every single file is that Tomcat is using. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request Timeout and empty post data issue
Peter Rifel wrote: -Original Message- From: Konstantin Preißer [kpreis...@apache.org] Sent: Thursday, December 26, 2013 1:28 PM To: 'Tomcat Users List' Subject: RE: Request Timeout and empty post data issue Hi, -Original Message- From: Peter Rifel [mailto:pri...@mixpo.com] Sent: Thursday, December 26, 2013 9:45 PM To: users@tomcat.apache.org Subject: Request Timeout and empty post data issue Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Is there some other timeout value somewhere that defaults to 20 seconds? Is there a way for me to see exactly what is taking so long? Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. I'd appreciate any ideas on what could cause this. Did you try to set the connectionTimeout to some other value to see if the requests still take ~ 20s? I just tested with Tomcat 7.0.47 and HTTP APR connector, and for me the connectionTimeout value is also applied when reading the POST data: When the client does not send a byte in this interval (20s), then this will trigger some timeout error. E.g., if you send the following POST request without a body (2x CR LF after the last header): POST /MyWebapp/PostServlet HTTP/1.1 Host: localhost Connection: keep-alive Content-Length: 999 Content-Type: application/x-www-form-urlencoded Then after the connectionTimeout interval, an java.net.SocketTimeoutException occurs at org.apache.catalina.connector.CoyoteInputStream.read (e.g. when you directly read the Request input stream), so that Tomcat doesn't wait forever for further data when the client is already gone. Note that the exception did not occur when I called request.getParameter(xxx) - it just returned null. It could be possible that a client sends a request with complete headers, but when sending the POST body the client waits too long so that Tomcat applies the connectionTimeout before the full request body is received. The request will then be logged as the request headers where completely received. Regards, Konstantin Preißer Konstantin, I changed the connectionTimeout and that value is being reflected in our access logs. So this means that tomcat is not receiving a body with the POST request, indicating a client-side or network problem? It could also of course be a malicious client, doing this just to bother you. (a form of DoS attack). We never read the input stream directly, we only use getParameter so that would explain why our servlet isn't throwing a SocketTimeoutException. Calling getParameters(), as far as I know, forces Tomcat to read the /whole/ request body, to parse the parameters before returning from getParameters(). That is why I was a bit curious about how you managed to determine, in the servlet filter, that there were no parameters. Somehow it seems to me that there is still an unexplained phenomenon there, as follows : Suppose that there is supposed to be a body with parameters, the total length of that body being given by the Content-length header. Your code calls getParameters() for the first time. The underlying Tomcat code reads the body. Either this body can be read completely (up to Content-length) and parsed into parameters, and the getParameter() call returns. Or else, the read of the POST body blocks for lack of data, before Content-length has been reached. In that case, the call to getParameter() should not return. And if that situation lasts
RE: Request Timeout and empty post data issue
From: Jesse Barnum [jsb_tom...@360works.com] Sent: Thursday, December 26, 2013 2:14 PM To: Tomcat Users List Subject: Re: Request Timeout and empty post data issue One issue that will cause empty POST data to be received is if the POST data size exceeds the value in the server.xml file: http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html The maximum size in bytes of the POST which will be handled by the container FORM URL parameter parsing. The limit can be disabled by setting this attribute to a value less than or equal to 0. If not specified, this attribute is set to 2097152 (2 megabytes). It would also make sense that these larger POSTs would take longer, so it fits the evidence. --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Dec 26, 2013, at 3:45 PM, Peter Rifel pri...@mixpo.com wrote: Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Is there some other timeout value somewhere that defaults to 20 seconds? Is there a way for me to see exactly what is taking so long? Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. I'd appreciate any ideas on what could cause this. Thanks, Peter In this case, these requests are only plaintext, never more than a few hundred characters. Our max post size is set to 10MB so theres no apparent reason that we would reach this limit on these requests, nor is there a reason that processing the data would timeout unless there was a problem with the data itself. Thanks for the suggestion, Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request Timeout and empty post data issue
On 26/12/2013 20:45, Peter Rifel wrote: Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? It depends. The connectionTimeout is also the socket timeout. If at any time Tomcat is (trying to) read data from the client or write data to the client and no data is available (reading) or read (writing) for the timeout period then the read / write will fail. It sounds like the client sends the request and then either doesn't send the whole body, only sends part of the body or pauses for longer than connectionTimeout while sending the body. The request body is therefore missing / incomplete so can't be processed. Whether that results in an error response will depend on your application. I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The above statement is incorrect. See the explanation preceding it. The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Unlikely. It almost certainly means Tomcat is waiting 20s for the request body to turn up. Is there some other timeout value somewhere that defaults to 20 seconds? No. Is there a way for me to see exactly what is taking so long? Wireshark. Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. That makes it look very much like a client issue. I'd log the size of the request body as well. A request body size of 0 and no POST data would point to a client issue. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. See above. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat auto deployer not working for ROOT applications
On 26/12/2013 19:33, Jesse Barnum wrote: Any ideas here? It sounds like a bug in the deployer. Can you confirm the behaviour with the latest 7.0.x release? If so, please create a Bugzilla entry. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Request Timeout and empty post data issue
From: Mark Thomas [ma...@apache.org] Sent: Thursday, December 26, 2013 3:19 PM To: Tomcat Users List Subject: Re: Request Timeout and empty post data issue On 26/12/2013 20:45, Peter Rifel wrote: Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? It depends. The connectionTimeout is also the socket timeout. If at any time Tomcat is (trying to) read data from the client or write data to the client and no data is available (reading) or read (writing) for the timeout period then the read / write will fail. It sounds like the client sends the request and then either doesn't send the whole body, only sends part of the body or pauses for longer than connectionTimeout while sending the body. The request body is therefore missing / incomplete so can't be processed. Whether that results in an error response will depend on your application. I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The above statement is incorrect. See the explanation preceding it. This is what the documentation on the Configuration Reference page says, so if it is incorrect it should be updated. The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Unlikely. It almost certainly means Tomcat is waiting 20s for the request body to turn up. Is there some other timeout value somewhere that defaults to 20 seconds? No. Is there a way for me to see exactly what is taking so long? Wireshark. Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. That makes it look very much like a client issue. I'd log the size of the request body as well. A request body size of 0 and no POST data would point to a client issue. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. See above. Mark I’m logging the Content-length header and it has expected values, mostly between 300 and 800 bytes. The requests are coming from a custom flash player that is being in embedded in users’ browsers that are out of our control, so it does make it difficult to debug with only 1% of our traffic seeing this problem. I will run wireshark on tomcat to try and get a better idea of where the issue is, thank you for the suggestion. Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request Timeout and empty post data issue
On 26/12/2013 23:57, Peter Rifel wrote: From: Mark Thomas [ma...@apache.org] On 26/12/2013 20:45, Peter Rifel wrote: I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The above statement is incorrect. See the explanation preceding it. This is what the documentation on the Configuration Reference page says, so if it is incorrect it should be updated. The docs have been fixed in 8.0.x and 7.0.x for the next release of each. You might also want to take a look at connectionUploadTimeout and disableUploadTimeout. Also, I'd recommend seriously considering reducing that timeout to a few seconds. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Request Timeout and empty post data issue
Peter Rifel wrote: From: Mark Thomas [ma...@apache.org] Sent: Thursday, December 26, 2013 3:19 PM To: Tomcat Users List Subject: Re: Request Timeout and empty post data issue On 26/12/2013 20:45, Peter Rifel wrote: Hello, I'm currently running Tomcat 7.0.42 on Ubuntu 12.04 with OpenJDK 1.7.0_25. I'm using Apache Tomcat Native library 1.1.27 with APR version 1.4.6. I'm noticing in my access logs that some of our POST requests don't have any POST data and all have response times of a few ms over 2ms. I'm trying to figure out whether this issue is client side or server side. The response code and response size for these requests are normal. Can anyone tell me under what circumstances this would happen? It depends. The connectionTimeout is also the socket timeout. If at any time Tomcat is (trying to) read data from the client or write data to the client and no data is available (reading) or read (writing) for the timeout period then the read / write will fail. It sounds like the client sends the request and then either doesn't send the whole body, only sends part of the body or pauses for longer than connectionTimeout while sending the body. The request body is therefore missing / incomplete so can't be processed. Whether that results in an error response will depend on your application. I noticed that our connector's connectionTimeout is set to 2ms, but it wouldn't make sense for that value to be a part of this issue because a connection timeout only occurs when the URI hasn't been received by tomcat in that amount of time, which is clearly not happening here (I was able to confirm this with telnet; a connection timeout will not write anything to the access logs). The above statement is incorrect. See the explanation preceding it. This is what the documentation on the Configuration Reference page says, so if it is incorrect it should be updated. The request is making it to my servlet (logging confirms this) but for some reason tomcat doesn't see any request parameters and all of the response times in our access logs are just above 20 seconds. Does this mean that my servlet is taking 20 seconds to process the request? Unlikely. It almost certainly means Tomcat is waiting 20s for the request body to turn up. Is there some other timeout value somewhere that defaults to 20 seconds? No. Is there a way for me to see exactly what is taking so long? Wireshark. Its incredibly hard to debug this because we cant reproduce this bug on our own without any post data and 1% of our production traffic is having this issue. To try and gather more info on this, I added a servlet filter that logs all of our POST request parameters to the access log and I can confirm that there are no parameters on these specific requests. That makes it look very much like a client issue. I'd log the size of the request body as well. A request body size of 0 and no POST data would point to a client issue. The lack of post data makes me think its a client issue, but that doesn't explain why all of these requests take ~20 seconds to be processed. See above. Mark I’m logging the Content-length header and it has expected values, mostly between 300 and 800 bytes. The requests are coming from a custom flash player that is being in embedded in users’ browsers that are out of our control, so it does make it difficult to debug with only 1% of our traffic seeing this problem. I will run wireshark on tomcat to try and get a better idea of where the issue is, thank you for the suggestion. Suggestion: if the custom player is under your control, make sure that the problematic requests are indeed coming from this player, and not from some (malicious or not) other source. Perhaps some additional X- header in the request, with some time-variable key that can be checked on the server side ? You probably don't want to spend a lot of time inspecting thousands of packets if the reason is a misbehaving robot or monitoring agent or similar. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat auto deployer not working for ROOT applications
I ran apt-get today and I got version 7.0.35, not 7.0.47. Maybe this is more of a Linux question then Tomcat, but shouldn't apt-get get me the latest version? Do I need to do something on my end, or is this something that the Tomcat team needs to publish somewhere? --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Dec 26, 2013, at 6:22 PM, Mark Thomas ma...@apache.org wrote: On 26/12/2013 19:33, Jesse Barnum wrote: Any ideas here? It sounds like a bug in the deployer. Can you confirm the behaviour with the latest 7.0.x release? If so, please create a Bugzilla entry. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
how http connector backlog attribute works?
Hi, I find a problem of http bio connector,I need help. You can find it in flowing steps: 1.set tomcat connector like this: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 acceptCount=1 maxThreads=1 minSpareThreads=1/ 2. deploy a war file, which contains a servlet that will sleep 60s in it's doPost method 3. use LR or JMeter send 5 requests to the serlvet above 4. use command jstack print current thread stack NOTE: now the main acceptor thread stack like this: http-bio-8080-Acceptor-0 daemon prio=6 tid=0x04b49800 nid=0x1a88 waiting on condition [0x0536f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x29a06cd0 (a org.apache.tomcat.util.threads.LimitLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:115) at org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:733) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:210) at java.lang.Thread.run(Thread.java:662) Now, In the 5 requests, 3 request will served correctly, but another 2 requests will received Connection refused error like this Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:529) Why the 2 requests not entering the thread pool executor or taskQueue, but get refused quickly? Thanks in advance.
Re: how http connector backlog attribute works?
侯树成 wrote: Hi, I find a problem of http bio connector,I need help. You can find it in flowing steps: 1.set tomcat connector like this: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 acceptCount=1 maxThreads=1 minSpareThreads=1/ 2. deploy a war file, which contains a servlet that will sleep 60s in it's doPost method 3. use LR or JMeter send 5 requests to the serlvet above 4. use command jstack print current thread stack NOTE: now the main acceptor thread stack like this: http-bio-8080-Acceptor-0 daemon prio=6 tid=0x04b49800 nid=0x1a88 waiting on condition [0x0536f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x29a06cd0 (a org.apache.tomcat.util.threads.LimitLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:115) at org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:733) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:210) at java.lang.Thread.run(Thread.java:662) Now, In the 5 requests, 3 request will served correctly, but another 2 requests will received Connection refused error like this Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:529) Why the 2 requests not entering the thread pool executor or taskQueue, but get refused quickly? Thanks in advance. Which java and Tomcat versions ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how http connector backlog attribute works?
On 12/26/2013 11:09 PM, 侯树成 wrote: Hi, I find a problem of http bio connector,I need help. You can find it in flowing steps: 1.set tomcat connector like this: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 acceptCount=1 maxThreads=1 minSpareThreads=1/ 2. deploy a war file, which contains a servlet that will sleep 60s in it's doPost method 3. use LR or JMeter send 5 requests to the serlvet above 4. use command jstack print current thread stack NOTE: now the main acceptor thread stack like this: http-bio-8080-Acceptor-0 daemon prio=6 tid=0x04b49800 nid=0x1a88 waiting on condition [0x0536f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x29a06cd0 (a org.apache.tomcat.util.threads.LimitLatch$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at org.apache.tomcat.util.threads.LimitLatch.countUpOrAwait(LimitLatch.java:115) at org.apache.tomcat.util.net.AbstractEndpoint.countUpOrAwaitConnection(AbstractEndpoint.java:733) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:210) at java.lang.Thread.run(Thread.java:662) Now, In the 5 requests, 3 request will served correctly, but another 2 requests will received Connection refused error like this Caused by: java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:529) Why the 2 requests not entering the thread pool executor or taskQueue, but get refused quickly? Thanks in advance. I'm going to guess based on the Tomcat 7 documentation: request 1 gets executed and sits in your doPost for 60 seconds request 2 consumes the minSpareThread request 3 consumes the acceptCount Per documentation, connections 4 and 5 are dropped immediately. Please read the following and see if my interpretation is reasonable: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html Pay particular attention to the Introduction section. If I have the particulars wrong, hopefully someone will come along and correct me. . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Java Settings for each webapps, and virtual host strange issue.
Guys see here is that error message , I am attaching log file also please help OS - Centos 6.5 64 bit HTTP Status 500 - Error instantiating servlet class gov.noaa.pfel.erddap.Erddap -- *type* Exception report *message* *Error instantiating servlet class gov.noaa.pfel.erddap.Erddap* *description* *The server encountered an internal error that prevented it from fulfilling this request.* *exception* javax.servlet.ServletException: Error instantiating servlet class gov.noaa.pfel.erddap.Erddap org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:744) *root cause* java.lang.ExceptionInInitializerError gov.noaa.pfel.erddap.Erddap.init(Erddap.java:196) sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) java.lang.reflect.Constructor.newInstance(Constructor.java:526) java.lang.Class.newInstance(Class.java:374) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:744) *root cause* java.lang.RuntimeException: Ask the ERDDAP administrator to look at the detailed error message in [bigParentDirectory]/logs/log.txt . gov.noaa.pfel.erddap.util.EDStatic.clinit(EDStatic.java:2322) gov.noaa.pfel.erddap.Erddap.init(Erddap.java:196) sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) java.lang.reflect.Constructor.newInstance(Constructor.java:526) java.lang.Class.newInstance(Class.java:374) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:744) Please help me Peter On Fri, Dec 27, 2013 at 3:03 AM, André Warnier a...@ice-sa.com wrote: Peter wrote: Thanks *Mark,* Martin Gainty, André Warnier for you time As some of you suggested I need to have different tomcat for different java version The very first question which you should maybe ask yourself (or the developers of the webapps), is *why* these webapps require different Java versions. It should not be so. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
