Re: Can Tomcat Disconnect HTTP Connection that is Connecting for Too Long
On Sat, Oct 21, 2017 at 10:44 PM, André Warnier (tomcat) wrote: > > " timeout on backend to api, is also not feasible " > > Why not ? > That seems to be the real underlying issue. > > " my plan is, http connection from device to server, that are connected for > more than 10second need to be disconnected forcefully > " > > This is probaly possible (through some "Listener" starting a timer etc. > ?), but it does not seem to me to be a very clean way of resolving the > issue. > For one, any background connection that the tomcat thread establishes to a > back-end server (API), will continue to run and use up resources, even if > you kill the client connection. > You would need to kill (and cleanup) the back-end connections too, > otherwise you are setting yourself up for the perfect DoS scenario : a > million client connections come in, expecting to be killed after 10 > seconds; but your server continues to wait for a million back-end things to > happen. > It seems more logical (and clean) to set a timeout on the back-end API, > and return an error to the client if that timeout is exceeded. > > Note that if the client TCP connection is dropped (for whatever reason, > even the client closing it unilaterally), the server will never notice, > *until* it tries to write something to that connection. Then the server > code will get an error, and thus notice. > Hi Andre, long story short, there is no reversal api to 3rd party, so i cannot disconnect forcefully using timeout (yes, it's an old school api) as for DoS concern, we are having a thread pool specifically for handling connection, so number of connection to 3rd party is limited idea of asynchronous request from device to server is also proposed, but it will changed the logic of our mobile apps, a risk that management dont want to take thank you. -- Warm Regards, Edwin
Re: Can Tomcat Disconnect HTTP Connection that is Connecting for Too Long
On 21.10.2017 17:03, Muhammad Edwin wrote: Hello all, im currently using Apache Tomcat 8.5.23, which serve json api to a lot of mobile application during production i can see that several request took more than 30seconds response time and it happens because our backend application have dependency to a lot of third party api enforcing http timeout on device is not feasible due to apps is already on production and alot of people using it timeout on backend to api, is also not feasible so my only option is implementing a default http timeout on tomcat, my plan is, http connection from device to server, that are connected for more than 10second need to be disconnected forcefully on OS level, i can achieved it using crontab and tcpkill option, but it seems less elegant my question is, can i achieved above requirement using apache tomcat.? any file to be configured, thread pool to be tuned, or perhaps enforcing http timeout.? " timeout on backend to api, is also not feasible " Why not ? That seems to be the real underlying issue. " my plan is, http connection from device to server, that are connected for more than 10second need to be disconnected forcefully " This is probaly possible (through some "Listener" starting a timer etc. ?), but it does not seem to me to be a very clean way of resolving the issue. For one, any background connection that the tomcat thread establishes to a back-end server (API), will continue to run and use up resources, even if you kill the client connection. You would need to kill (and cleanup) the back-end connections too, otherwise you are setting yourself up for the perfect DoS scenario : a million client connections come in, expecting to be killed after 10 seconds; but your server continues to wait for a million back-end things to happen. It seems more logical (and clean) to set a timeout on the back-end API, and return an error to the client if that timeout is exceeded. Note that if the client TCP connection is dropped (for whatever reason, even the client closing it unilaterally), the server will never notice, *until* it tries to write something to that connection. Then the server code will get an error, and thus notice. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Can Tomcat Disconnect HTTP Connection that is Connecting for Too Long
Hello all, im currently using Apache Tomcat 8.5.23, which serve json api to a lot of mobile application during production i can see that several request took more than 30seconds response time and it happens because our backend application have dependency to a lot of third party api enforcing http timeout on device is not feasible due to apps is already on production and alot of people using it timeout on backend to api, is also not feasible so my only option is implementing a default http timeout on tomcat, my plan is, http connection from device to server, that are connected for more than 10second need to be disconnected forcefully on OS level, i can achieved it using crontab and tcpkill option, but it seems less elegant my question is, can i achieved above requirement using apache tomcat.? any file to be configured, thread pool to be tuned, or perhaps enforcing http timeout.? Any help appreciated. Thank you. -- Warm Regards, Edwin
Re: TomCat service is running but not responding
Darin, On Oct 20, 2017 8:48 PM, "James H. H. Lampert" wrote: On 10/20/17, 7:50 AM, André Warnier (tomcat) wrote: . . . Then also tell a bit more about the "stop responding" aspect. What > exactly happens when you try to access tomcat, in the browser ? > Are you not getting any answer at all, no mater how long you wait ? > Are you gettin an error page ? > Are you getting a blank page ? > And are there any messages (especially Java stack traces) in the "catalina.out" log file that might indicate that something has gone horribly wrong? -- JHHL In addition to the answer of the above questions, I will request you to take at least 3 thread dumps 5Sec apart, when you think Tomcat service has "stopped responding". Also look for OutOfMemory condition. Please post those dumps in this list. Thanks! Suvendu
