Hi Angelov,
I had a similar problem a few years back using websphere 4.0 and IBM's
HTTP server. The HTTP server was dropping the connection with the
servlet container before the unit of work had finished. Setting the
HTTP server's connection timeout to "infinite" resolved the issue.
Not sure if it will work here... but it is worth a try..
Angelov, Rossen wrote:
That's exactly how I understood it too. The request will be dropped if after
certain number of milliseconds the request's URI hasn't been received.
In my case the URI comes directly with the request and based on my log I can
see the request is being processed but there is no response after the doPost
method is finished.
I can still give it try with connectionTimeout="0", but don't expect it to
help.
Ross
-----Original Message-----
From: Steve Kirk [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 26, 2005 3:09 PM
To: 'Tomcat Users List'; [EMAIL PROTECTED]
Subject: RE: servlet request time out ?!
I haven't tested this myself, so I'm only going on what the docs say (5.5):
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/http.html
If I've understood correctly, this doc seems to say that the
connectionTimeout param doesn't have the effect Angelov is looking for - it
sets the max time between a connection (socket) being opened by the client,
and the client sending a request url to TC.
-----Original Message-----
From: Mike Baliel [mailto:[EMAIL PROTECTED]
Sent: Thursday 26 May 2005 19:49
To: Tomcat Users List
Subject: Re: servlet request time out ?!
Hi Angelov,
I am new to Tomcat (Just started using Tomcat5.0
yesterday), but the
problem you mentioned sounds like a typical connnection timout.
Have you tried to setting the connectionTimeout value to 0 in the
server.xml?
Here is to location in server.xml. Where there is currently
a value of
[connectionTimeout="20000"] change to [connectionTimeout="0"].
<Service name="Catalina">
<!-- A "Connector" represents an endpoint by which requests are
received
and responses are returned. Each Connector passes
requests on
to the
associated "Container" (normally an Engine) for processing.
By default, a non-SSL HTTP/1.1 Connector is established on
port 8080.
You can also enable an SSL HTTP/1.1 Connector on
port 8443 by
following the instructions below and uncommenting
the second
Connector
entry. SSL support requires the following steps
(see the SSL
Config
HOWTO in the Tomcat 5 documentation bundle for more detailed
instructions):
* If your JDK version 1.3 or prior, download and
install JSSE
1.0.2 or
later, and put the JAR files into
"$JAVA_HOME/jre/lib/ext".
* Execute:
%JAVA_HOME%\bin\keytool -genkey -alias tomcat
-keyalg RSA
(Windows)
$JAVA_HOME/bin/keytool -genkey -alias tomcat
-keyalg RSA
(Unix)
with a password value of "changeit" for both the
certificate and
the keystore itself.
By default, DNS lookups are enabled when a web
application calls
request.getRemoteHost(). This can have an adverse impact on
performance, so you can disable it by setting the
"enableLookups" attribute to "false". When DNS lookups are
disabled,
request.getRemoteHost() will return the String
version of the
IP address of the remote client.
-->
<!-- Define a non-SSL Coyote HTTP/1.1 Connector on the
port specified
during installation -->
<Connector
port="8080" maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false" redirectPort="8443"
acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />
<!-- Note : To disable connection timeouts, set
connectionTimeout value
to 0 -->
Mike
Angelov, Rossen wrote:
Hi,
Does anybody know about a time out on a servlet request
with Tomcat 5?
The problem is that I have a request that takes about 30
minutes but the
browser keeps waiting for the response forever. I tried
different browsers
but it's the same behavior.
I put debug statements in the doPost method and it's
finishing correctly.
The last debug statement is printed out but the browser is
still waiting for
the response.
Ross
"This communication is intended solely for the addressee and is
confidential and not for third party unauthorized distribution."
--------------------------------------------------------------
----------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.17 - Release
Date: 5/25/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 5/25/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
"This communication is intended solely for the addressee and is
confidential and not for third party unauthorized distribution."
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 5/25/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.17 - Release Date: 5/25/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
