tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: IIS 6.0 / JK1.2.25 / Tomcat 5.5.20 - "Service temporary unavailable"
Date Mon, 21 Jul 2008 19:53:07 GMT
Jesse Klaasse schrieb:
> Last Wednesday, I decided to try to use commons-dbcp (1.2.2) instead of the
> included naming-factory-dbcp.jar. Besides that, I have removed the
> "validationQuery" attribute, after reading about some problems with that.
> Since then, no problems have arised, Tomcat behaved nicely. I hope this
> finally has solved my problems. Still have to wait a few weeks before I can
> really say the system is stable. I keep my fingers crossed.
> Only problem which I still can't explain: there seems to be a 20 second
> timeout somewhere between IIS and Tomcat. I have created a test JSP with
> does this:
> out.println("wait..."); out.flush();
> Thread.sleep(65000).
> out.println("finished!"); out.flush();
> Calling Tomcat directly by using http://localhost:8080/delay.jsp works as
> expected (it shows "wait...", then waits for 65 seconds and then prints
> "finished!").
> Calling the same page through IIS causes this:
> "wait..." appears on screen
> after 10 seconds, another "wait..." appears
> after another 10 seconds, a "Service temporary unavailable" message appears
> I suppose this has something to do with the connect_timeout, prepost_timeout
> and socket_timeout parameters (which are set to 10000, 10000 and 10
> respectively). Should I set these values to a higher value? What I
> especially don't understand, is the reappearance of "wait..." after 10
> seconds.

Not sure here. There's always the topic of flushing. With Apache httpd 
we have switches to configure, if httpd is allowed to combine ajp result 
packets before sending them to the client, or if it should flush each 
packet by itself. No idea, how IIS does it.

Considering the wait reappearance: what's you client?

To really study communication behaviour I would suggest installing a raw 
http client like curl and then do

curl -v -D - http://myserver:myport/myuri

curl will not cache, follow redirects or any other of those nice user 
GUI features, that make understanding communication behaviour difficult.

prepose and connect timeout should not induce any problem here, because 
the are run before the request is sent, and the result for those probes 
is immediately returned by the Tomcat connector itself.

socket_timeout could be a reason, e.g. JK might detect a request failure 
and retry the request another 2 times, before it gives up.

Any of those should log info and finally error log lines in the isapi 
log telling u more about the reason.

I generally don't like the socket_timeout much ... (the same does not 
hold true for the other timeouts).



To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message