RE: CrawlerSessionManagerValve only working with default host
Ahh, I can see that from the source now, thanks. - Matt -Original Message- From: Mark Thomas <ma...@apache.org> Sent: Thursday, April 12, 2018 2:27 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: CrawlerSessionManagerValve only working with default host On 12/04/18 00:10, Matt Cosentino wrote: > I first noticed it by the large number of sessions in the manager webapp, but > then I verified it in my logs. Both of my sites are polled every minute by > the UptimeRobot service. These requests are logged and I can see what session > is being used. For the default host site, they reuse the same session. For > the non-default host sites, they create new sessions. It is a limitation of the CrawlerSessionManagerValve. It only supports one session per client IP as it maps client IP to session ID internally. Moving the Valve to the Context (if you want it to apply to every Context you can define it in CATALINA_BASE/conf/context.xml) is a workaround. The proper fix is to change the valve so it maps context+client IP to session ID. There are several ways to do this. Please open a Bugzilla enhancement request for this and someone will take a look. Mark > > 04-11 00:00:14 INFO LogRequest > HEAD: https www.defaulthost.com > /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.defaulthost.com > 04-11 00:01:14 INFO LogRequest > HEAD: https www.defaulthost.com > /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.defaulthost.com > 04-11 00:02:14 INFO LogRequest > HEAD: https www.defaulthost.com > /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.defaulthost.com > 04-11 00:03:13 INFO LogRequest > HEAD: https www.defaulthost.com > /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.defaulthost.com > > 04-11 00:00:32 INFO LogRequest > HEAD: https www.anotherhost.com > /, FROM: 69.162.124.237, C62DCA4E9DC39884E3E82EE19AAEAB4A, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.anotherhost.com > 04-11 00:01:32 INFO LogRequest > HEAD: https www.anotherhost.com > /, FROM: 69.162.124.237, 542027513FD08CD82C8BEFF3C4E75F8C, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.anotherhost.com > 04-11 00:02:32 INFO LogRequest > HEAD: https www.anotherhost.com > /, FROM: 69.162.124.237, F93C1929D880DDD446D13E36413544DF, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.anotherhost.com > 04-11 00:03:32 INFO LogRequest > HEAD: https www.anotherhost.com > /, FROM: 69.162.124.237, 82C3BB415817B8C4761EFEF7EE7591DD, > Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), > REFERER: https://www.anotherhost.com > > This is with the valve at the engine level, which I assumed meant that it > would apply to all hosts within that engine. The documentation states > "Normally, this Valve would be used at the Engine level.", so that's what I > did. > > https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Crawler_Ses > sion_Manager_Valve > > - Matt > > -Original Message- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Wednesday, April 11, 2018 1:46 PM > To: users@tomcat.apache.org > Subject: Re: CrawlerSessionManagerValve only working with default host > > Matt, > > On 4/11/18 2:03 PM, Matt Cosentino wrote: >> I have CrawlerSessionManagerValve set up at the Engine level, but it only >> seems to be working for the default host and not any other host. Is this >> expected behavior? Should I put it at the host level for each host? >> >> Here is an example of how I have it set up: >> >> >> >> >> >> >> >> > className="org.apache.catalina.valves.CrawlerSessionManagerValve" >> sessionInactiveInterval="300"/> >> >> >> Tomcat 8.5.24 > > I don't see anything in the code that suggests it wouldn't work when used at > the level, but it also looks like it makes the most sense at the > level. > > Can you describe your testing and the results you got? > > Wh
RE: CrawlerSessionManagerValve only working with default host
I first noticed it by the large number of sessions in the manager webapp, but then I verified it in my logs. Both of my sites are polled every minute by the UptimeRobot service. These requests are logged and I can see what session is being used. For the default host site, they reuse the same session. For the non-default host sites, they create new sessions. 04-11 00:00:14 INFO LogRequest > HEAD: https www.defaulthost.com /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.defaulthost.com 04-11 00:01:14 INFO LogRequest > HEAD: https www.defaulthost.com /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.defaulthost.com 04-11 00:02:14 INFO LogRequest > HEAD: https www.defaulthost.com /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.defaulthost.com 04-11 00:03:13 INFO LogRequest > HEAD: https www.defaulthost.com /, FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.defaulthost.com 04-11 00:00:32 INFO LogRequest > HEAD: https www.anotherhost.com /, FROM: 69.162.124.237, C62DCA4E9DC39884E3E82EE19AAEAB4A, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.anotherhost.com 04-11 00:01:32 INFO LogRequest > HEAD: https www.anotherhost.com /, FROM: 69.162.124.237, 542027513FD08CD82C8BEFF3C4E75F8C, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.anotherhost.com 04-11 00:02:32 INFO LogRequest > HEAD: https www.anotherhost.com /, FROM: 69.162.124.237, F93C1929D880DDD446D13E36413544DF, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.anotherhost.com 04-11 00:03:32 INFO LogRequest > HEAD: https www.anotherhost.com /, FROM: 69.162.124.237, 82C3BB415817B8C4761EFEF7EE7591DD, Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), REFERER: https://www.anotherhost.com This is with the valve at the engine level, which I assumed meant that it would apply to all hosts within that engine. The documentation states "Normally, this Valve would be used at the Engine level.", so that's what I did. https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Crawler_Session_Manager_Valve - Matt -Original Message- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Wednesday, April 11, 2018 1:46 PM To: users@tomcat.apache.org Subject: Re: CrawlerSessionManagerValve only working with default host Matt, On 4/11/18 2:03 PM, Matt Cosentino wrote: > I have CrawlerSessionManagerValve set up at the Engine level, but it only > seems to be working for the default host and not any other host. Is this > expected behavior? Should I put it at the host level for each host? > > Here is an example of how I have it set up: > > > > > > > >className="org.apache.catalina.valves.CrawlerSessionManagerValve" > sessionInactiveInterval="300"/> > > > Tomcat 8.5.24 I don't see anything in the code that suggests it wouldn't work when used at the level, but it also looks like it makes the most sense at the level. Can you describe your testing and the results you got? When you say "only [...] working for the default host", do you mean that it works for the default host within an (when configured at the level) or that it doesn't even work with a non-default when configured at the level? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CrawlerSessionManagerValve only working with default host
I have CrawlerSessionManagerValve set up at the Engine level, but it only seems to be working for the default host and not any other host. Is this expected behavior? Should I put it at the host level for each host? Here is an example of how I have it set up: Tomcat 8.5.24 - Matt
RE: Skip resource path in TLD scanner?
Thanks, but I'm talking about resource paths and not jar files. - Matt From: Ray Holme [mailto:rayho...@yahoo.com.INVALID] Sent: Friday, November 17, 2017 1:39 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip resource path in TLD scanner? I use JSP and there are taglibs used. But you can cut the scan time way down by not scanning any libraries that don't have TLDs (nested files with name => .tld) You can find this by using "jar t" or "unzip -l" on each library (thanks Chris). If you are a Unix (Linux or MAC) user you may cheat a little by using the script attached. You may put any all .jar files in .../apache/lib or .../apache/webapps/*/WEB-INF/lib into the .../apache/conf/catalina.properties file if they do not have taglibs. So 90% of what I need does not have taglibs (just jstl-impl-...jar DOES and must be left out of the DO NO SCAN line. This took my startup time from a couple minutes to under a second. Best of luck. On Friday, November 17, 2017 1:26 PM, Christopher Schultz <ch...@christopherschultz.net<mailto:ch...@christopherschultz.net>> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matt, On 11/16/17 12:11 PM, Matt Cosentino wrote: > This keeps getting worse, my site was down for over a minute while > the TLD scanner ran. There must be something I can do. If you need taglibs, you'll need to do TLS scanning. There really is no way to avoid that that I know of. One of many reasons I don't like JSP as a technology. If you are having a problem with downtime, you have other options that might help in other areas. For example, you could set up a second server and load-balance between the two of them. This protects you from a number of downtime-causing issues such as power failures, JVM crashes, and -- as in your example here -- planned maintenance. Running a single instance of your application in a production environment where uptime matters is really not an appropriate solution. If you had two servers, your application's restart time would not have been an issue. - -chris > -Original Message- From: Mark Thomas > [mailto:ma...@apache.org<mailto:ma...@apache.org>] Sent: Saturday, April 29, > 2017 5:02 AM > To: Tomcat Users List > <users@tomcat.apache.org<mailto:users@tomcat.apache.org>> Subject: Re: Skip > resource path in TLD scanner? > > On 28/04/17 17:00, Matt Cosentino wrote: >> Yes, it's other folders within WEB-INF. I turned on the >> TldScanner logging and it is definitely what is causing the >> delay. My situation probably isn't very typical. The delay varies >> in my various web applications, the worst being about 20 seconds. >> It all adds up though, and every second counts when our sites are >> down. > > There is a solution available but it is intended more for the > embedded use case rather than a standard Tomcat install. Using it > in a standard install would require (effectively) patching Tomcat. > > The general idea would be to use the TldPreScanned class. That does > require all the TLDs to be listed in advance. On the plus side, no > scanning delay. On the down side, adding TLDs requires code > changes. Doing this with a standard Tomcat install requires changes > to the JasperInitializer (hence the patch). I don't think there is > a pure config way around that but I'll look into it. > > A better solution would probably be to make it easier to plugin in > a custom TLDScanner - i.e. purely with config. If you'd like us to > explore this option we should re-open 61052 and adjust accordingly. > I don't think there is enough demand for filtering resource paths > to make that worth implementing. > > One final thought. Are you running the web application from a WAR > or an expanded directory? (The latter would be faster). > > Mark > > > >> >> - Matt >> >> >> -Original Message- From: Mark Thomas >> [mailto:ma...@apache.org<mailto:ma...@apache.org>] Sent: Friday, April 28, >> 2017 7:28 AM >> To: Tomcat Users List >> <users@tomcat.apache.org<mailto:users@tomcat.apache.org>> Subject: Re: Skip >> resource path in TLD scanner? >> >> On 27/04/17 23:39, Matt Cosentino wrote: >>> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html >>> >>> >>> There is one for skipping jar files: >>> >>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip >> >> >> >>> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not >>> check any property to skip user defined paths. >> >> Is it other paths within WEB-INF you need to skip? >> >> When I read "skipping resource paths" I was thinking of skipping >> the various places w
RE: Skip resource path in TLD scanner?
While that is good advice, it's not necessarily an appropriate solution for this. It's not that I don't want any TLD scanning, it's that it is scanning folders that I know don't have TLDs and there is no reason to scan them. The scanner already decides to skip the classes and lib paths, so it could definitely skip a user defined list of paths. I guess for now I could see if I can move the files in these paths out of WEB-INF to keep them from being scanned. - Matt -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, November 17, 2017 12:26 PM To: users@tomcat.apache.org Subject: Re: Skip resource path in TLD scanner? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Matt, On 11/16/17 12:11 PM, Matt Cosentino wrote: > This keeps getting worse, my site was down for over a minute while the > TLD scanner ran. There must be something I can do. If you need taglibs, you'll need to do TLS scanning. There really is no way to avoid that that I know of. One of many reasons I don't like JSP as a technology. If you are having a problem with downtime, you have other options that might help in other areas. For example, you could set up a second server and load-balance between the two of them. This protects you from a number of downtime-causing issues such as power failures, JVM crashes, and -- as in your example here -- planned maintenance. Running a single instance of your application in a production environment where uptime matters is really not an appropriate solution. If you had two servers, your application's restart time would not have been an issue. - -chris > -Original Message- From: Mark Thomas [mailto:ma...@apache.org] > Sent: Saturday, April 29, 2017 5:02 AM > To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip > resource path in TLD scanner? > > On 28/04/17 17:00, Matt Cosentino wrote: >> Yes, it's other folders within WEB-INF. I turned on the TldScanner >> logging and it is definitely what is causing the delay. My situation >> probably isn't very typical. The delay varies in my various web >> applications, the worst being about 20 seconds. >> It all adds up though, and every second counts when our sites are >> down. > > There is a solution available but it is intended more for the embedded > use case rather than a standard Tomcat install. Using it in a standard > install would require (effectively) patching Tomcat. > > The general idea would be to use the TldPreScanned class. That does > require all the TLDs to be listed in advance. On the plus side, no > scanning delay. On the down side, adding TLDs requires code changes. > Doing this with a standard Tomcat install requires changes to the > JasperInitializer (hence the patch). I don't think there is a pure > config way around that but I'll look into it. > > A better solution would probably be to make it easier to plugin in a > custom TLDScanner - i.e. purely with config. If you'd like us to > explore this option we should re-open 61052 and adjust accordingly. > I don't think there is enough demand for filtering resource paths to > make that worth implementing. > > One final thought. Are you running the web application from a WAR or > an expanded directory? (The latter would be faster). > > Mark > > > >> >> - Matt >> >> >> -Original Message- From: Mark Thomas >> [mailto:ma...@apache.org] Sent: Friday, April 28, 2017 7:28 AM >> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip >> resource path in TLD scanner? >> >> On 27/04/17 23:39, Matt Cosentino wrote: >>> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html >>> >>> >>> There is one for skipping jar files: >>> >>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip >> >> >> >>> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not check >>> any property to skip user defined paths. >> >> Is it other paths within WEB-INF you need to skip? >> >> When I read "skipping resource paths" I was thinking of skipping the >> various places where Tomcat treat directories as JARs that then get >> scanned for TLDs (which can be configured via the JarScanner). But it >> sounds like skipping those won't help you. >> >> How sure are you that it is checking the directories below WEB-INF >> that is the cause of the delay? That isn't a typical source of >> start-up delay although it is certainly possible. >> >> Finally, what sort of delay are we talking out here? Seconds? >> Minutes? >> >> Mark >> >> >>> -Original Me
RE: Skip resource path in TLD scanner?
This keeps getting worse, my site was down for over a minute while the TLD scanner ran. There must be something I can do. - Matt -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Saturday, April 29, 2017 5:02 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip resource path in TLD scanner? On 28/04/17 17:00, Matt Cosentino wrote: > Yes, it's other folders within WEB-INF. I turned on the TldScanner > logging and it is definitely what is causing the delay. My situation > probably isn't very typical. The delay varies in my various web > applications, the worst being about 20 seconds. It all adds up though, > and every second counts when our sites are down. There is a solution available but it is intended more for the embedded use case rather than a standard Tomcat install. Using it in a standard install would require (effectively) patching Tomcat. The general idea would be to use the TldPreScanned class. That does require all the TLDs to be listed in advance. On the plus side, no scanning delay. On the down side, adding TLDs requires code changes. Doing this with a standard Tomcat install requires changes to the JasperInitializer (hence the patch). I don't think there is a pure config way around that but I'll look into it. A better solution would probably be to make it easier to plugin in a custom TLDScanner - i.e. purely with config. If you'd like us to explore this option we should re-open 61052 and adjust accordingly. I don't think there is enough demand for filtering resource paths to make that worth implementing. One final thought. Are you running the web application from a WAR or an expanded directory? (The latter would be faster). Mark > > - Matt > > > -Original Message- From: Mark Thomas [mailto:ma...@apache.org] > Sent: Friday, April 28, 2017 7:28 AM To: > Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip resource > path in TLD scanner? > > On 27/04/17 23:39, Matt Cosentino wrote: >> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html >> >> There is one for skipping jar files: >> >> tomcat.util.scan.StandardJarScanFilter.jarsToSkip > > > >> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not check >> any property to skip user defined paths. > > Is it other paths within WEB-INF you need to skip? > > When I read "skipping resource paths" I was thinking of skipping the > various places where Tomcat treat directories as JARs that then get > scanned for TLDs (which can be configured via the JarScanner). But it > sounds like skipping those won't help you. > > How sure are you that it is checking the directories below WEB-INF > that is the cause of the delay? That isn't a typical source of > start-up delay although it is certainly possible. > > Finally, what sort of delay are we talking out here? Seconds? > Minutes? > > Mark > > >> -Original Message- From: Mark Thomas >> [mailto:ma...@apache.org] Sent: Thursday, April 27, 2017 5:05 PM >> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip >> resource path in TLD scanner? >> >> On 27/04/17 21:17, Matt Cosentino wrote: >>> I need to skip some of the resource paths within WEB-INF. I know >>> there's a property for skipping jar files, but I couldn't find one >>> for resource paths. I reported this as a bug and was told that the >>> property exists. Where is it? >> >> Where have you looked? >> >> Mark > > - > > 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 > - 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: Response cut off after 10 seconds when using NIO2 connector
So you know, I switched NIO and NIO2 on my two servers last night so that the timeout no longer occurs on my live server. The test server now shows the behavior. - Matt -Original Message- From: Matt Cosentino [mailto:mcosent...@cacorp.com] Sent: Wednesday, July 12, 2017 10:05 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: RE: Response cut off after 10 seconds when using NIO2 connector That's certainly not the case, I have no problem accessing 8443. Here is the connector config, only difference on the 8443 server is the protocol, address, and port. - Matt -Original Message- From: Kreuser, Peter [mailto:pkreu...@airplus.com] Sent: Wednesday, July 12, 2017 4:56 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: AW: Response cut off after 10 seconds when using NIO2 connector Hi Matt, > -Ursprüngliche Nachricht----- > Von: Matt Cosentino [mailto:mcosent...@cacorp.com] > Gesendet: Dienstag, 11. Juli 2017 19:35 > An: Tomcat Users List <users@tomcat.apache.org> > Betreff: Response cut off after 10 seconds when using NIO2 connector > > I'm using Tomcat 8.5.16 with the NIO2 connector and OpenSSL. It seems that if > a request runs for more than 10 seconds, Tomcat simply cuts off the response. > This does not happen with either the NIO or APR connectors. I'm using all > default settings. Is this expected behavior or am I missing a setting > somewhere? Here are links showing the behavior with identical settings except > for the connector: > > NIO2: https://www.arclearn.com/sleep.jsp > NIO: https://www.arclearn.com:8443/sleep.jsp > > - Matt Thank you for the Test-Pages, but: could it be that port 8443 is not publicly accessible? I get a connection timeout. I assume that is not the problem you are referring to ;-) ... Can you also send your connector config for NIO and NIO2, please? Best regards 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Response cut off after 10 seconds when using NIO2 connector
That's certainly not the case, I have no problem accessing 8443. Here is the connector config, only difference on the 8443 server is the protocol, address, and port. - Matt -Original Message- From: Kreuser, Peter [mailto:pkreu...@airplus.com] Sent: Wednesday, July 12, 2017 4:56 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: AW: Response cut off after 10 seconds when using NIO2 connector Hi Matt, > -Ursprüngliche Nachricht- > Von: Matt Cosentino [mailto:mcosent...@cacorp.com] > Gesendet: Dienstag, 11. Juli 2017 19:35 > An: Tomcat Users List <users@tomcat.apache.org> > Betreff: Response cut off after 10 seconds when using NIO2 connector > > I'm using Tomcat 8.5.16 with the NIO2 connector and OpenSSL. It seems that if > a request runs for more than 10 seconds, Tomcat simply cuts off the response. > This does not happen with either the NIO or APR connectors. I'm using all > default settings. Is this expected behavior or am I missing a setting > somewhere? Here are links showing the behavior with identical settings except > for the connector: > > NIO2: https://www.arclearn.com/sleep.jsp > NIO: https://www.arclearn.com:8443/sleep.jsp > > - Matt Thank you for the Test-Pages, but: could it be that port 8443 is not publicly accessible? I get a connection timeout. I assume that is not the problem you are referring to ;-) ... Can you also send your connector config for NIO and NIO2, please? Best regards 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
Response cut off after 10 seconds when using NIO2 connector
I'm using Tomcat 8.5.16 with the NIO2 connector and OpenSSL. It seems that if a request runs for more than 10 seconds, Tomcat simply cuts off the response. This does not happen with either the NIO or APR connectors. I'm using all default settings. Is this expected behavior or am I missing a setting somewhere? Here are links showing the behavior with identical settings except for the connector: NIO2: https://www.arclearn.com/sleep.jsp NIO: https://www.arclearn.com:8443/sleep.jsp - Matt
Http2UpgradeHandler crash
Tomcat crashed on us today, here is an excerpt from the crash log: Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 19003 org.apache.tomcat.jni.Socket.sendb(JLjava/nio/ByteBuffer;II)I (0 bytes) @ 0x0599a2df [0x0599a280+0x5f] J 42307 C2 org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking()V (90 bytes) @ 0x02663b84 [0x026632e0+0x8a4] J 38363 C2 org.apache.tomcat.util.net.SocketWrapperBase.flush(Z)Z (20 bytes) @ 0x046e5a18 [0x046e59e0+0x38] j org.apache.coyote.http2.Http2UpgradeHandler.sendStreamReset(Lorg/apache/coyote/http2/StreamException;)V+128 j org.apache.coyote.http2.Stream.close(Lorg/apache/coyote/http2/Http2Exception;)V+76 J 43733 C2 org.apache.coyote.http2.StreamRunnable.run()V (12 bytes) @ 0x0af4d104 [0x0af4c720+0x9e4] J 36891 C1 java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (225 bytes) @ 0x09a7797c [0x09a76940+0x103c] J 41848 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ 0x03ff180c [0x03ff1700+0x10c] J 41853 C1 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()V (25 bytes) @ 0x07e8194c [0x07e81840+0x10c] J 30379 C1 java.lang.Thread.run()V (17 bytes) @ 0x0170dac4 [0x0170d980+0x144] v ~StubRoutines::call_stub In my web application log I found this at the same time: org.apache.coyote.CloseNowException: Connection [389], Stream [67], This stream is not writable at org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:755) at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:721) at org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:682) at org.apache.coyote.Response.doWrite(Response.java:522) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:351) There were more for additional streams at this same time. I've seen quite a few of these CloseNowExceptions since upgrading to 8.5.14 from 8.5.11, but this is the first time it has crashed Tomcat. What could be the cause? What should I be looking for? - Matt
RE: Skip resource path in TLD scanner?
Yes, it's other folders within WEB-INF. I turned on the TldScanner logging and it is definitely what is causing the delay. My situation probably isn't very typical. The delay varies in my various web applications, the worst being about 20 seconds. It all adds up though, and every second counts when our sites are down. - Matt -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, April 28, 2017 7:28 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip resource path in TLD scanner? On 27/04/17 23:39, Matt Cosentino wrote: > https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html > > There is one for skipping jar files: > > tomcat.util.scan.StandardJarScanFilter.jarsToSkip > It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not check any > property to skip user defined paths. Is it other paths within WEB-INF you need to skip? When I read "skipping resource paths" I was thinking of skipping the various places where Tomcat treat directories as JARs that then get scanned for TLDs (which can be configured via the JarScanner). But it sounds like skipping those won't help you. How sure are you that it is checking the directories below WEB-INF that is the cause of the delay? That isn't a typical source of start-up delay although it is certainly possible. Finally, what sort of delay are we talking out here? Seconds? Minutes? Mark > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Thursday, April 27, 2017 5:05 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Skip resource path in TLD scanner? > > On 27/04/17 21:17, Matt Cosentino wrote: >> I need to skip some of the resource paths within WEB-INF. I know >> there's a property for skipping jar files, but I couldn't find one >> for resource paths. I reported this as a bug and was told that the >> property exists. Where is it? > > Where have you looked? > > Mark - 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: Skip resource path in TLD scanner?
I already did, that only mentions skipping jar files. - Matt -Original Message- From: Violeta Georgieva [mailto:violet...@apache.org] Sent: Friday, April 28, 2017 1:30 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Skip resource path in TLD scanner? Hi, 2017-04-27 23:17 GMT+03:00 Matt Cosentino <mcosent...@cacorp.com>: > > I need to skip some of the resource paths within WEB-INF. I know > there's a property for skipping jar files, but I couldn't find one for resource paths. I reported this as a bug and was told that the property exists. Where is it? Check this wiki https://wiki.apache.org/tomcat/HowTo/FasterStartUp Regards, Violeta > - Matt >
RE: Skip resource path in TLD scanner?
https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html
There is one for skipping jar files:
tomcat.util.scan.StandardJarScanFilter.jarsToSkip
I then looked at the source for TldScanner, here is the scanResourcePaths
function:
/**
* Scan web application resources for TLDs, recursively.
*
* @param startPath the directory resource to scan
* @throws IOException if there was a problem scanning for or loading a TLD
* @throws SAXException if there was a problem parsing a TLD
*/
protected void scanResourcePaths(String startPath)
throws IOException, SAXException {
Set dirList = context.getResourcePaths(startPath);
if (dirList != null) {
for (String path : dirList) {
if (path.startsWith("/WEB-INF/classes/")) {
// Skip: JSP.7.3.1
} else if (path.startsWith("/WEB-INF/lib/")) {
// Skip: JSP.7.3.1
} else if (path.endsWith("/")) {
scanResourcePaths(path);
} else if (path.startsWith("/WEB-INF/tags/")) {
// JSP 7.3.1: in /WEB-INF/tags only consider implicit.tld
if (path.endsWith("/implicit.tld")) {
parseTld(path);
}
} else if (path.endsWith(TLD_EXT)) {
parseTld(path);
}
}
}
}
It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not check any
property to skip user defined paths.
- Matt
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, April 27, 2017 5:05 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Skip resource path in TLD scanner?
On 27/04/17 21:17, Matt Cosentino wrote:
> I need to skip some of the resource paths within WEB-INF. I know
> there's a property for skipping jar files, but I couldn't find one for
> resource paths. I reported this as a bug and was told that the
> property exists. Where is it?
Where have you looked?
Mark
-
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
Skip resource path in TLD scanner?
I need to skip some of the resource paths within WEB-INF. I know there's a property for skipping jar files, but I couldn't find one for resource paths. I reported this as a bug and was told that the property exists. Where is it? - Matt
Re: Tomcat on Windows Server 2008 fails to stop completely
I figured it out, it was a problem with our SSL setup. Thanks for the help. - Original Message From: Steve Ochani [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, July 30, 2008 7:53:29 PM Subject: Re: Tomcat on Windows Server 2008 fails to stop completely On 30 Jul 2008 at 14:49, Matt Cosentino wrote: I'm setting up a new server with Tomcat 6.0.16 running on Windows Server 2008 with version 1.1.14 of the native DLL. When I stop the service it seems to stop, but the process does not end. I have to then end the process manually before I can start the service again. I've narrowed it down to the native DLL, since removing it seems to fix the problem. I've used the native DLL under previous versions of Windows, so is there some incompatibility between the native DLL and Windows Server 2008? I haven't used Tomcat on server 2008 but I don't see why there would be a problem. Have you looked in the event logs to see if there is a logged error? -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]
Tomcat on Windows Server 2008 fails to stop completely
I'm setting up a new server with Tomcat 6.0.16 running on Windows Server 2008 with version 1.1.14 of the native DLL. When I stop the service it seems to stop, but the process does not end. I have to then end the process manually before I can start the service again. I've narrowed it down to the native DLL, since removing it seems to fix the problem. I've used the native DLL under previous versions of Windows, so is there some incompatibility between the native DLL and Windows Server 2008?
Re: Erratic HTTP response behavior
Thanks, I've been using Firebug to track the requests and responses from Firefox, which is how I found the strange chunked transfer encoding behavior. I'll try some of the other things you mentioned. - Original Message From: Len Popp [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, June 13, 2007 6:38:43 PM Subject: Re: Erratic HTTP response behavior It's pretty obvious by now that no-one's going to be able to email you a solution to your problem, which seems unique or at least very unusual. You're going to have to dig deeply into this one yourself. Here's what I'd do, if it helps you any. I would track the problem requests from the browser to the server and back again, at several points, to see where it's going wrong. - Look at the request and response in the browser using a plug-in like LiveHTTPHeaders or ieHTTPHeaders. - Log the requests received by Tomcat (AccessLogValve or RequestDumperValve). - Put logging messages in your application, in every servlet or JSP, to see what piece of code is executed for each request. - Use a network sniffer (e.g. Wireshark) to see if the HTTP responses are being sent to the correct clients. You may have to log traffic at both the client and server ends if there's a proxy or gateway between them. Given all of those logs, you should be able to figure out where a particular request went astray - in Tomcat, in the application, or in the network. My money's on the network. -- Len On 6/13/07, Matt Cosentino [EMAIL PROTECTED] wrote: Well that didn't last long. After making some other changes the problem has returned... with a vengeance! Seriously, it's even weirder than before. Not only are some responses coming back chunked, but some are coming back completely wrong. Like I try to open my index page and it responds with an image. I tried reverting everything that I changed back to how they were before and the problem doesn't go away. So strange, could really use some help. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, June 13, 2007 2:20:24 PM Subject: Re: Erratic HTTP response behavior Ok, so I made a small change and somehow I think I fixed it. I removed the following line from my page: link rel=icon type=image/x-icon href=/images/icon.ico This happened by accident, I only removed it because the icon didn't exist at that path. After doing that I noticed that everything would always load correctly. I then added it back to see if that really did fix it, and sure enough the problem came back. Then I just moved the line before some files that I often had problems loading, and the problem went away. So it seems to me that when Tomcat tried to respond to that request it was breaking the responses of the other resources, somehow. I don't understand it, but I figured I'd at least share my experience in case this helps anyone else. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, June 11, 2007 1:07:37 PM Subject: Re: Erratic HTTP response behavior In a previous discussion it was said that the problem was fixed in 5.5.17, so maybe the problem was reintroduced somehow. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, June 8, 2007 6:12:28 PM Subject: Re: Erratic HTTP response behavior I tried looking through the archive and just couldn't find any help. The problem has recently reproduced itself on a new Tomcat 5.5.23 install on one of my co-worker's machine, so it's not my PC. I've also experienced it more often with random images or other resources not loading, and when I check the network monitor in Firebug it lists the transfer-encoding for them as chunked. Luckily this problem has never surfaced on our production server which is version 5.5.17, but I don't see any configuration differences. This is driving me nuts, so any help would be greatly appreciated. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:09:57 PM Subject: Re: Erratic HTTP response behavior No I am on intending on using chunked responses. Is there a way to disable it? - Original Message From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:02:58 PM Subject: Re: Erratic HTTP response behavior -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, You're right, this /is/ erratic behavior. I think something is going wrong with your headers or something: Matt Cosentino wrote: /body/html0 HTTP/1.1 200 OKServer: Apache-Coyote/1.1Transfer-Encoding: chunkedDate: Fri, 18 May 2007 22:35:13 GMT Your response headers appear to be after the body of the response
Re: Erratic HTTP response behavior
I'm not setting the transfer-encoding, but thanks. - Original Message From: Martin Gainty [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, June 13, 2007 8:47:28 PM Subject: Re: Erratic HTTP response behavior if you are setting Transfer-encoding to 'chunked' as in response.setHeader( Transfer-Encoding, chunked); then read and follow these directives http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html Caveat Emptor! Martin- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: Len Popp [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, June 13, 2007 7:38 PM Subject: Re: Erratic HTTP response behavior It's pretty obvious by now that no-one's going to be able to email you a solution to your problem, which seems unique or at least very unusual. You're going to have to dig deeply into this one yourself. Here's what I'd do, if it helps you any. I would track the problem requests from the browser to the server and back again, at several points, to see where it's going wrong. - Look at the request and response in the browser using a plug-in like LiveHTTPHeaders or ieHTTPHeaders. - Log the requests received by Tomcat (AccessLogValve or RequestDumperValve). - Put logging messages in your application, in every servlet or JSP, to see what piece of code is executed for each request. - Use a network sniffer (e.g. Wireshark) to see if the HTTP responses are being sent to the correct clients. You may have to log traffic at both the client and server ends if there's a proxy or gateway between them. Given all of those logs, you should be able to figure out where a particular request went astray - in Tomcat, in the application, or in the network. My money's on the network. -- Len On 6/13/07, Matt Cosentino [EMAIL PROTECTED] wrote: Well that didn't last long. After making some other changes the problem has returned... with a vengeance! Seriously, it's even weirder than before. Not only are some responses coming back chunked, but some are coming back completely wrong. Like I try to open my index page and it responds with an image. I tried reverting everything that I changed back to how they were before and the problem doesn't go away. So strange, could really use some help. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, June 13, 2007 2:20:24 PM Subject: Re: Erratic HTTP response behavior Ok, so I made a small change and somehow I think I fixed it. I removed the following line from my page: link rel=icon type=image/x-icon href=/images/icon.ico This happened by accident, I only removed it because the icon didn't exist at that path. After doing that I noticed that everything would always load correctly. I then added it back to see if that really did fix it, and sure enough the problem came back. Then I just moved the line before some files that I often had problems loading, and the problem went away. So it seems to me that when Tomcat tried to respond to that request it was breaking the responses of the other resources, somehow. I don't understand it, but I figured I'd at least share my experience in case this helps anyone else. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, June 11, 2007 1:07:37 PM Subject: Re: Erratic HTTP response behavior In a previous discussion it was said that the problem was fixed in 5.5.17, so maybe the problem was reintroduced somehow. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, June 8, 2007 6:12:28 PM Subject: Re: Erratic HTTP response behavior I tried looking through the archive and just couldn't find any help. The problem has recently reproduced itself on a new Tomcat 5.5.23 install on one of my co-worker's machine, so it's not my PC. I've also experienced it more often with random images or other resources not loading, and when I check the network monitor in Firebug it lists the transfer-encoding for them as chunked. Luckily this problem has never surfaced on our production server which is version 5.5.17, but I don't see any configuration differences. This is driving me nuts, so any help would be greatly appreciated. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:09:57 PM Subject: Re: Erratic HTTP response behavior No I am on intending on using
Re: Erratic HTTP response behavior
In a previous discussion it was said that the problem was fixed in 5.5.17, so maybe the problem was reintroduced somehow. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, June 8, 2007 6:12:28 PM Subject: Re: Erratic HTTP response behavior I tried looking through the archive and just couldn't find any help. The problem has recently reproduced itself on a new Tomcat 5.5.23 install on one of my co-worker's machine, so it's not my PC. I've also experienced it more often with random images or other resources not loading, and when I check the network monitor in Firebug it lists the transfer-encoding for them as chunked. Luckily this problem has never surfaced on our production server which is version 5.5.17, but I don't see any configuration differences. This is driving me nuts, so any help would be greatly appreciated. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:09:57 PM Subject: Re: Erratic HTTP response behavior No I am on intending on using chunked responses. Is there a way to disable it? - Original Message From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:02:58 PM Subject: Re: Erratic HTTP response behavior -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, You're right, this /is/ erratic behavior. I think something is going wrong with your headers or something: Matt Cosentino wrote: /body/html0 HTTP/1.1 200 OKServer: Apache-Coyote/1.1Transfer-Encoding: chunkedDate: Fri, 18 May 2007 22:35:13 GMT Your response headers appear to be after the body of the response. Either that or the headers I see there are supposed to be the headers from the next chunk and/or request in a keepalive request. Are you intending to use chunked responses? 'Cause it looks like they are being used. There was some in-depth discussion of chunked responses somewhat recently on the list. Perhaps you could take a look at that for some reference points (but I'm not saying that it will solve your problem). I think the problem might be that you are getting chunked encoding for some reason, but you don't really want it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGV08C9CaO5/Lv0PARArfQAJoD+kMZLUVWthGyRuv0NWKIKSuXcACfYh+I sJuvF8+a8MgIcIu3gd1hGak= =u9oS -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz - 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: Erratic HTTP response behavior
I tried looking through the archive and just couldn't find any help. The problem has recently reproduced itself on a new Tomcat 5.5.23 install on one of my co-worker's machine, so it's not my PC. I've also experienced it more often with random images or other resources not loading, and when I check the network monitor in Firebug it lists the transfer-encoding for them as chunked. Luckily this problem has never surfaced on our production server which is version 5.5.17, but I don't see any configuration differences. This is driving me nuts, so any help would be greatly appreciated. - Original Message From: Matt Cosentino [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:09:57 PM Subject: Re: Erratic HTTP response behavior No I am on intending on using chunked responses. Is there a way to disable it? - Original Message From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:02:58 PM Subject: Re: Erratic HTTP response behavior -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, You're right, this /is/ erratic behavior. I think something is going wrong with your headers or something: Matt Cosentino wrote: /body/html0 HTTP/1.1 200 OKServer: Apache-Coyote/1.1Transfer-Encoding: chunkedDate: Fri, 18 May 2007 22:35:13 GMT Your response headers appear to be after the body of the response. Either that or the headers I see there are supposed to be the headers from the next chunk and/or request in a keepalive request. Are you intending to use chunked responses? 'Cause it looks like they are being used. There was some in-depth discussion of chunked responses somewhat recently on the list. Perhaps you could take a look at that for some reference points (but I'm not saying that it will solve your problem). I think the problem might be that you are getting chunked encoding for some reason, but you don't really want it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGV08C9CaO5/Lv0PARArfQAJoD+kMZLUVWthGyRuv0NWKIKSuXcACfYh+I sJuvF8+a8MgIcIu3gd1hGak= =u9oS -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Erratic HTTP response behavior
I’m experiencing some very erratic behavior in my local development installation of Tomcat. Here is my setup: Windows XP SP2 Tomcat 6.0.13 (had been using Tomcat 5.5.20 and was experiencing the same behavior) Struts Web Application (I’ve had similar issues with the manager app, so I’m convinced the problem is in Tomcat) Firefox + Firebug for testing (I seem to experience it less often in IE7, but that could just be my imagination) 1. Sometimes when I request a page I will get a dialog box saying “You have chosen to open page.do which is a DO file”. It seems like the content type is being screwed up. When I save the file to see the response, there is seemingly random data interspersed in the file, but it is consistent after I do it again. It always starts with the first line saying “b1” and the last saying “0”. At different points in the file there are groupings of characters like “d3d” and “3df”. One time I had a similar problem loading the manager app. It displayed with a content type of “text/plain”. Here is some of what displayed: 2000 html head style ... td class=row-left bgcolor=#C3F31329C3 ... /body/html0 HTTP/1.1 200 OKServer: Apache-Coyote/1.1Transfer-Encoding: chunkedDate: Fri, 18 May 2007 22:35:13 GMT 2. Sometimes everything in the page will load except for my stylesheet. When I check the response in Firebug I notice that the response header has a Trasfer-Encoding of chunked and the response just says “Loading …”. When it is successful there is no Transfer-Encoding value in the header. 3. Sometimes it will take a really long time to load certain files in the page, always about 20.5 seconds. One thing I noticed was that for these requests there were no response headers, but the file always ends up loading fine. I’m completely baffled by this behavior. If anyone has even a hint of what could be wrong, I would be very grateful. - Matt Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - 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: Erratic HTTP response behavior
No I am on intending on using chunked responses. Is there a way to disable it? - Original Message From: Christopher Schultz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Friday, May 25, 2007 4:02:58 PM Subject: Re: Erratic HTTP response behavior -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, You're right, this /is/ erratic behavior. I think something is going wrong with your headers or something: Matt Cosentino wrote: /body/html0 HTTP/1.1 200 OKServer: Apache-Coyote/1.1Transfer-Encoding: chunkedDate: Fri, 18 May 2007 22:35:13 GMT Your response headers appear to be after the body of the response. Either that or the headers I see there are supposed to be the headers from the next chunk and/or request in a keepalive request. Are you intending to use chunked responses? 'Cause it looks like they are being used. There was some in-depth discussion of chunked responses somewhat recently on the list. Perhaps you could take a look at that for some reference points (but I'm not saying that it will solve your problem). I think the problem might be that you are getting chunked encoding for some reason, but you don't really want it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGV08C9CaO5/Lv0PARArfQAJoD+kMZLUVWthGyRuv0NWKIKSuXcACfYh+I sJuvF8+a8MgIcIu3gd1hGak= =u9oS -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 - 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: Erratic HTTP response behavior
Actually, it did look like that, the \r\n codes were removed for some reason when I sent the email. - Original Message From: Bill Barker [EMAIL PROTECTED] To: users@tomcat.apache.org Sent: Friday, May 25, 2007 8:12:04 PM Subject: Re: Erratic HTTP response behavior Christopher Schultz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, You're right, this /is/ erratic behavior. I think something is going wrong with your headers or something: Matt Cosentino wrote: /body/html0 HTTP/1.1 200 OKServer: Apache-Coyote/1.1Transfer-Encoding: chunkedDate: Fri, 18 May 2007 22:35:13 GMT Your response headers appear to be after the body of the response. Either that or the headers I see there are supposed to be the headers from the next chunk and/or request in a keepalive request. Indeed :). This is the start of the next response in the pipeline, and should look like: /body/html 0 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Transfer-Encoding: chunked Date: Fri, 18 May 2007 22:35:13 GMT It looks like some 'friendly' intermediate is compressing out the \r\n codes that are needed to interpret 'chunked'. To not use 'chunked', you have to set the Content-Length yourself (or have only very small pages and don't call flush). If your pages aren't too huge, and you don't have too high of concurrency, it is pretty easy to write a Filter that wraps the response to hold the output in memory until it is all there, and then set the Content-Length before passing it back to the browser. Are you intending to use chunked responses? 'Cause it looks like they are being used. There was some in-depth discussion of chunked responses somewhat recently on the list. Perhaps you could take a look at that for some reference points (but I'm not saying that it will solve your problem). I think the problem might be that you are getting chunked encoding for some reason, but you don't really want it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGV08C9CaO5/Lv0PARArfQAJoD+kMZLUVWthGyRuv0NWKIKSuXcACfYh+I sJuvF8+a8MgIcIu3gd1hGak= =u9oS -END PGP SIGNATURE- - 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] Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
