RE: connectionTimeout
Hi, I think, I finally found out what the problem is. As Bill already said each child process in Apache (Apache 1.3) tries to generate a connection to Tomcat. If there are more child processes on Apache site that try to connect than maximal possible Threads in Tomcat (defined by means of the property maxProcessor) everythings hangs (no more requests will reach Tomcat). So I think I must set the maxProcessors on the Tomcat side equal or a little bit higher than the property maxClients on the Apache side. What do you think? Regards Karin -Original Message- From: Krause Karin Sent: Donnerstag, 22. Januar 2004 09:19 To: 'Tomcat Users List' Subject: RE: connectionTimeout I agree with you that closing the socket on each request isn't a good idea. But I have the feeling that only if the socket is closed the thread is freed and Tomcat can accept new input on this thread. Yesterday I did some more tests and I'd like to explain you one in more detail: I use Apache (Apache/1.3.26 (Unix) mod_jk/1.2.4) -> Tomcat 4.1.27 I work with the default sample servlets (the Helloworld Servlet) The configuration of my CoyoteConnector looks like this: I did only sequential requests. So I did my first and get the answer back, the second and again I get the answer back. So than I did the third request and I had to wait quite a while (and as I recognized in my mod_jk logging output I had to wait 2 minutes (like I set my timeout)). SEE: [Wed Jan 21 16:32:50 2004] [jk_ajp_common.c (966)]: ajp_send_request 2: request body to send 0 - request body to resend 0 --> Here the Request is sent to Tomcat [Wed Jan 21 16:34:21 2004] [jk_ajp_common.c (804)]: received from ajp13 #60 --> Here I got the answer back (takes 2 minutes) In the Tomcat log I saw the following output: 20040122:085055.660 LFFM01 NO_PROJ common.ChannelSocket DEBUG T-59219Accepted socket Socket[addr=/194.40.39.77,port=16058,localport=9000] 20040122:085122.547 LFFM01 NO_PROJ JK INFO T-12985263 org.apache.jk.common.ChannelSocket: connection timeout reached -> The request is only processed further when the connection timeout is received ... 20040122:085122.550 LFFM01 NO_PROJ JK DEBUG T-12985263 org.apache.jk.common.ChannelSocket: receive() 20040122:085122.551 LFFM01 NO_PROJ JK DEBUG T-12985263 org.apache.jk.common.ChannelSocket: read() [EMAIL PROTECTED] 8192 0 4 = 4 When I set the connection timeout to 2000 I never will get something back. (I tried it also with a connection timeout with -1 and also I got nothing back.) As you would certainly agree I did not generate heavy load (even if I worked with a maximal thread number of three, I did only sequential requests). So what do you think? Cheers Karin -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 22. Januar 2004 04:28 To: [EMAIL PROTECTED] Subject: Re: connectionTimeout connectionTimeout="-1" (or channelSocket.soTimeout=-1 in jk2.properties) disables it. The reason that the socket isn't closed on each request is to avoid the cost of setting up and tearing down sockets. By leaving it open, the Apache child can just send the next request that gets handed to it down the same open socket. It's the same reasoning as the HTTP/1.1 keep-alive, except that since the Apache <--> Tomcat socket has nothing to do with the browser <--> Apache socket, there isn't a reason to close it. "Krause Karin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > thanx for your answer (again ) > > As far as I know I cannot disable the connectionTimeout. > The connectionTimeout I mean here is a property of the CoyoteConnector > (and if not set the default value is 60 sec). What I do not understand is, > why the socket is not free again after the response is sent back to the client. > Tomcat can only accept new requests if the socket is removed (and it is removed > when the connectionTimeout is reached). > > Cheers Karin > > -Original Message- > From: Bill Barker [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 21. Januar 2004 10:34 > To: [EMAIL PROTECTED] > Subject: Re: connectionTimeout > > > > "Krause Karin" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > Hi everybody, > > > I have a question regarding the configuration/behaviour of the > org.apache.coyote.tomcat4.CoyoteConnector (Tomcat 4.1.27). > > I use Tomcat together with Apache (over mod_jk). > > When I set the connectionTimeout to a very high value (for example 5 > hours) and the maxProcessors to a very > > low value (for example 3) I can see the following behaviour. I can only > make 2 requests, > > than tomcat complains
RE: connectionTimeout
I agree with you that closing the socket on each request isn't a good idea. But I have the feeling that only if the socket is closed the thread is freed and Tomcat can accept new input on this thread. Yesterday I did some more tests and I'd like to explain you one in more detail: I use Apache (Apache/1.3.26 (Unix) mod_jk/1.2.4) -> Tomcat 4.1.27 I work with the default sample servlets (the Helloworld Servlet) The configuration of my CoyoteConnector looks like this: I did only sequential requests. So I did my first and get the answer back, the second and again I get the answer back. So than I did the third request and I had to wait quite a while (and as I recognized in my mod_jk logging output I had to wait 2 minutes (like I set my timeout)). SEE: [Wed Jan 21 16:32:50 2004] [jk_ajp_common.c (966)]: ajp_send_request 2: request body to send 0 - request body to resend 0 --> Here the Request is sent to Tomcat [Wed Jan 21 16:34:21 2004] [jk_ajp_common.c (804)]: received from ajp13 #60 --> Here I got the answer back (takes 2 minutes) In the Tomcat log I saw the following output: 20040122:085055.660 LFFM01 NO_PROJ common.ChannelSocket DEBUG T-59219Accepted socket Socket[addr=/194.40.39.77,port=16058,localport=9000] 20040122:085122.547 LFFM01 NO_PROJ JK INFO T-12985263 org.apache.jk.common.ChannelSocket: connection timeout reached -> The request is only processed further when the connection timeout is received ... 20040122:085122.550 LFFM01 NO_PROJ JK DEBUG T-12985263 org.apache.jk.common.ChannelSocket: receive() 20040122:085122.551 LFFM01 NO_PROJ JK DEBUG T-12985263 org.apache.jk.common.ChannelSocket: read() [EMAIL PROTECTED] 8192 0 4 = 4 When I set the connection timeout to 2000 I never will get something back. (I tried it also with a connection timeout with -1 and also I got nothing back.) As you would certainly agree I did not generate heavy load (even if I worked with a maximal thread number of three, I did only sequential requests). So what do you think? Cheers Karin -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 22. Januar 2004 04:28 To: [EMAIL PROTECTED] Subject: Re: connectionTimeout connectionTimeout="-1" (or channelSocket.soTimeout=-1 in jk2.properties) disables it. The reason that the socket isn't closed on each request is to avoid the cost of setting up and tearing down sockets. By leaving it open, the Apache child can just send the next request that gets handed to it down the same open socket. It's the same reasoning as the HTTP/1.1 keep-alive, except that since the Apache <--> Tomcat socket has nothing to do with the browser <--> Apache socket, there isn't a reason to close it. "Krause Karin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > thanx for your answer (again ) > > As far as I know I cannot disable the connectionTimeout. > The connectionTimeout I mean here is a property of the CoyoteConnector > (and if not set the default value is 60 sec). What I do not understand is, > why the socket is not free again after the response is sent back to the client. > Tomcat can only accept new requests if the socket is removed (and it is removed > when the connectionTimeout is reached). > > Cheers Karin > > -Original Message- > From: Bill Barker [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 21. Januar 2004 10:34 > To: [EMAIL PROTECTED] > Subject: Re: connectionTimeout > > > > "Krause Karin" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > Hi everybody, > > > I have a question regarding the configuration/behaviour of the > org.apache.coyote.tomcat4.CoyoteConnector (Tomcat 4.1.27). > > I use Tomcat together with Apache (over mod_jk). > > When I set the connectionTimeout to a very high value (for example 5 > hours) and the maxProcessors to a very > > low value (for example 3) I can see the following behaviour. I can only > make 2 requests, > > than tomcat complains > > org.apache.tomcat.util.threads.ThreadPool: All threads are busy, waiting. > Please increase maxThreads or check the servlet status3 3 > > Yup. In the normal state, the 'maxProcessors' should be at least as big as > the number of Apache children. Also, 'connectionTimeout' should usually be > disabled (although on a few Linux systems, I've had problems doing this). > There is a one-to-one mapping from Apache children to Tomcat socket > connections. If Apache launches one more child than Tomact can handle, you > will see the results as below. > > > No more requests can be performed until a restart. > > Does this mean a c
Re: connectionTimeout
connectionTimeout="-1" (or channelSocket.soTimeout=-1 in jk2.properties) disables it. The reason that the socket isn't closed on each request is to avoid the cost of setting up and tearing down sockets. By leaving it open, the Apache child can just send the next request that gets handed to it down the same open socket. It's the same reasoning as the HTTP/1.1 keep-alive, except that since the Apache <--> Tomcat socket has nothing to do with the browser <--> Apache socket, there isn't a reason to close it. "Krause Karin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > thanx for your answer (again ) > > As far as I know I cannot disable the connectionTimeout. > The connectionTimeout I mean here is a property of the CoyoteConnector > (and if not set the default value is 60 sec). What I do not understand is, > why the socket is not free again after the response is sent back to the client. > Tomcat can only accept new requests if the socket is removed (and it is removed > when the connectionTimeout is reached). > > Cheers Karin > > -Original Message- > From: Bill Barker [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 21. Januar 2004 10:34 > To: [EMAIL PROTECTED] > Subject: Re: connectionTimeout > > > > "Krause Karin" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > Hi everybody, > > > I have a question regarding the configuration/behaviour of the > org.apache.coyote.tomcat4.CoyoteConnector (Tomcat 4.1.27). > > I use Tomcat together with Apache (over mod_jk). > > When I set the connectionTimeout to a very high value (for example 5 > hours) and the maxProcessors to a very > > low value (for example 3) I can see the following behaviour. I can only > make 2 requests, > > than tomcat complains > > org.apache.tomcat.util.threads.ThreadPool: All threads are busy, waiting. > Please increase maxThreads or check the servlet status3 3 > > Yup. In the normal state, the 'maxProcessors' should be at least as big as > the number of Apache children. Also, 'connectionTimeout' should usually be > disabled (although on a few Linux systems, I've had problems doing this). > There is a one-to-one mapping from Apache children to Tomcat socket > connections. If Apache launches one more child than Tomact can handle, you > will see the results as below. > > > No more requests can be performed until a restart. > > Does this mean a connection (socket) is as long occupied as long the > connectionTimeout is set (even if the response was already sent back to the > browser)? > > I had expected that even if the set connectiontimeout is high, the socket > should be given free when the response is sent back to the client. > > I observed the Tomcat process by means of lsof and saw that the tomcat > process has opened 3 sockets to apache. > > When I set a connectionTimeout to a low value (for example 15 sec) the > error above (all threads are busy) does not appear any more. > > The lsof command shows that sockets are regulary removed and build again. > I debug the Tomcat code and saw that the socket is > > closed when the timeout occurs. I had expected another behaviour. I mean > that not every time a new socket is established from Tomcat > > to apache but sockets are reused. > > > > Thanx for any help > > Karin > > > > > - > 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]
RE: connectionTimeout
thanx for your answer (again ) As far as I know I cannot disable the connectionTimeout. The connectionTimeout I mean here is a property of the CoyoteConnector (and if not set the default value is 60 sec). What I do not understand is, why the socket is not free again after the response is sent back to the client. Tomcat can only accept new requests if the socket is removed (and it is removed when the connectionTimeout is reached). Cheers Karin -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 21. Januar 2004 10:34 To: [EMAIL PROTECTED] Subject: Re: connectionTimeout "Krause Karin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hi everybody, > > I have a question regarding the configuration/behaviour of the org.apache.coyote.tomcat4.CoyoteConnector (Tomcat 4.1.27). > I use Tomcat together with Apache (over mod_jk). > When I set the connectionTimeout to a very high value (for example 5 hours) and the maxProcessors to a very > low value (for example 3) I can see the following behaviour. I can only make 2 requests, > than tomcat complains > org.apache.tomcat.util.threads.ThreadPool: All threads are busy, waiting. Please increase maxThreads or check the servlet status3 3 Yup. In the normal state, the 'maxProcessors' should be at least as big as the number of Apache children. Also, 'connectionTimeout' should usually be disabled (although on a few Linux systems, I've had problems doing this). There is a one-to-one mapping from Apache children to Tomcat socket connections. If Apache launches one more child than Tomact can handle, you will see the results as below. > No more requests can be performed until a restart. > Does this mean a connection (socket) is as long occupied as long the connectionTimeout is set (even if the response was already sent back to the browser)? > I had expected that even if the set connectiontimeout is high, the socket should be given free when the response is sent back to the client. > I observed the Tomcat process by means of lsof and saw that the tomcat process has opened 3 sockets to apache. > When I set a connectionTimeout to a low value (for example 15 sec) the error above (all threads are busy) does not appear any more. > The lsof command shows that sockets are regulary removed and build again. I debug the Tomcat code and saw that the socket is > closed when the timeout occurs. I had expected another behaviour. I mean that not every time a new socket is established from Tomcat > to apache but sockets are reused. > > Thanx for any help > Karin - 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]
Re: connectionTimeout
"Krause Karin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hi everybody, > > I have a question regarding the configuration/behaviour of the org.apache.coyote.tomcat4.CoyoteConnector (Tomcat 4.1.27). > I use Tomcat together with Apache (over mod_jk). > When I set the connectionTimeout to a very high value (for example 5 hours) and the maxProcessors to a very > low value (for example 3) I can see the following behaviour. I can only make 2 requests, > than tomcat complains > org.apache.tomcat.util.threads.ThreadPool: All threads are busy, waiting. Please increase maxThreads or check the servlet status3 3 Yup. In the normal state, the 'maxProcessors' should be at least as big as the number of Apache children. Also, 'connectionTimeout' should usually be disabled (although on a few Linux systems, I've had problems doing this). There is a one-to-one mapping from Apache children to Tomcat socket connections. If Apache launches one more child than Tomact can handle, you will see the results as below. > No more requests can be performed until a restart. > Does this mean a connection (socket) is as long occupied as long the connectionTimeout is set (even if the response was already sent back to the browser)? > I had expected that even if the set connectiontimeout is high, the socket should be given free when the response is sent back to the client. > I observed the Tomcat process by means of lsof and saw that the tomcat process has opened 3 sockets to apache. > When I set a connectionTimeout to a low value (for example 15 sec) the error above (all threads are busy) does not appear any more. > The lsof command shows that sockets are regulary removed and build again. I debug the Tomcat code and saw that the socket is > closed when the timeout occurs. I had expected another behaviour. I mean that not every time a new socket is established from Tomcat > to apache but sockets are reused. > > Thanx for any help > Karin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: connectionTimeout
It depends on which you are using. The value of "0" is simply that both the Http-Coyote and the Jk-Coyote would both behave as the docs describe for "-1". For the Jk-Coyote Connector, you usually want the connectionTimeout disabled, or at least set to a large value (e.g. 5min). The mod_jk module will reuse the connection for different requests, so the only reason to have a connectionTimeout at all is to free up Threads after a peak-request spike. I've got a Linux 7.x box configured this way, but on my Solaris boxes I always disable 'connectionTimeout'. For Http-Coyote (aka stand-alone), you want to set this to a small number (e.g 5-15 sec.). Possibly a bit higher if you're using SSL on a light traffic site. This determines how soon a Thread is available to serve request from other clients. "Geralyn M Hollerman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I am still looking for information about the "connectionTimeout" > attribute of a element in server.xml, past what's in Tomcat's > Server Configuration Reference; from what I've read, the default value > is 6 (milliseconds), but the server.xml that came with the 4.1.24 > that I downloaded is set to "0". Is there a reason for this? Does "0" do > anything special? According to the sample server.xml, "-1" disables > connection timeouts - under what situations would I want to do that? > > Thanks! > -- > Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: connectionTimeout
Bill Barker wrote: > It depends on which you are using. The value of "0" is > simply > that both the Http-Coyote and the Jk-Coyote would both behave as the > docs > describe for "-1". Yes, Coyote was what I was thinking of. > For the Jk-Coyote Connector, you usually want the connectionTimeout > disabled, or at least set to a large value (e.g. 5min). The mod_jk > module > will reuse the connection for different requests, so the only reason > to have > a connectionTimeout at all is to free up Threads after a peak-request > spike. > I've got a Linux 7.x box configured this way, but on my Solaris boxes > I > always disable 'connectionTimeout'. This brings up an interesting point. Is this parameter akin to Apache's "TimeOut" directive? If so, then would it not be a problem if you had the Tomcat connectionTimeout set to some low value (let's say, 1 min) and Apache TimeOut set to the default (5 min)? I would think Apache would pass a request along after, say 4 min, but Tomcat would've timed out, no? Or are they not related as I'm thinking? -- Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: connectionTimeout
"Geralyn M Hollerman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Bill Barker wrote: > > > It depends on which you are using. The value of "0" is > > simply > > that both the Http-Coyote and the Jk-Coyote would both behave as the > > docs > > describe for "-1". > > Yes, Coyote was what I was thinking of. > > > For the Jk-Coyote Connector, you usually want the connectionTimeout > > disabled, or at least set to a large value (e.g. 5min). The mod_jk > > module > > will reuse the connection for different requests, so the only reason > > to have > > a connectionTimeout at all is to free up Threads after a peak-request > > spike. > > I've got a Linux 7.x box configured this way, but on my Solaris boxes > > I > > always disable 'connectionTimeout'. > > This brings up an interesting point. Is this parameter akin to Apache's > "TimeOut" directive? If so, then would it not be a problem if you had > the Tomcat connectionTimeout set to some low value (let's say, 1 min) > and Apache TimeOut set to the default (5 min)? I would think Apache > would pass a request along after, say 4 min, but Tomcat would've timed > out, no? Or are they not related as I'm thinking? > It is functionally similar at the implementation level, but very different at the abstracted level. If you set connectionTimeout="1min", and TimeOut="5min" (note: neither of these is syntactically correct, they are just for the purpose of discussion), then after 4min Apache would discover that Tomcat dropped the connection. It would then attempt to open a new connection to Tomcat, and proceed to use that one. There is a slight performance hit with re-opening the connection, but that's all. This feature has been there since mod_jk 1.1 (e.g. the one that ships with TC 3.3). The result is that setting the connectionTimeout (to a reasonable value) only has the effect of removing Tomcat Threads if the server becomes idle (e.g. it is an intranet site, so gets next to no traffic after 5PM). > -- > Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
