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).
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
