Hi Chris, in order to conclude on this thread could you please answer my final question now that I understood what the source of the problem is?
So, is there is a way to have connections between apache and tomcat closed when aborted? I've found recovery_options 4 for ajp workers which closes the connection to tomcat if an error when writing back the answer to the client is detected but not sure if such a behaviour can be configured for READ. George On Mon, Jan 22, 2018 at 11:45 AM, Emanuel Hategan <emanuel.hate...@gmail.com > wrote: > Hi Chris, > > > Forget about EOFException, that was my mistake in the first email >> > (and subject). I'm interested in improved handling of aborted >> > connections (at least most of them). That's my end goal. >> > >> > read=-1 solely does not provide sufficient information to be able >> > to distinguish between malformed request bodies and actual aborted >> > connections. >> >> How is Tomcat supposed to determine the difference? >> >> > That's why the ServletInputStream#readLine API says: Returns: an >> > integer specifying the actual number of bytes read, or -1 if the >> > end of the stream is reached Throws: IOException - if an input or >> > output exception has occurred >> >> End-of-stream is not an exceptional condition. >> >> > I understand that detecting aborted connections is not always >> > possible because of the missed handshakes but given that apache2 >> > and tomcat are most likely in the same local network and assuming >> > the protocol closes sockets properly, as long as apache2 detects it >> > tomcat should also. >> >> You are talking about AJP, which does not close connections between >> the reverse proxy (httpd) and Tomcat. So... what event are you looking >> for that Tomcat can use to signal an error? >> > > You're spot on for the source of confusion. I thought AJP does close the > connection between the reverse proxy and tomcat based on the apache log > below (especially line 3 and 6). > > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [info] > ajp_service::jk_ajp_common.c (2773): (directory_service) sending request > to tomcat failed (unrecoverable), because of client read error (attempt=1) > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] > ajp_reset_endpoint::jk_ajp_common.c (851): (directory_service) resetting > endpoint with socket 23 (socket shutdown) > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] > ajp_abort_endpoint::jk_ajp_common.c (821): (directory_service) aborting > endpoint with socket 23 > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] > jk_shutdown_socket::jk_connect.c (932): About to shutdown socket 23 [ > 127.0.0.1:42538 -> 127.0.0.1:15443] > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] > jk_is_input_event::jk_connect.c (1383): timeout during poll on socket 23 [ > 127.0.0.1:42538 -> 127.0.0.1:15443] (timeout=100) > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] > jk_shutdown_socket::jk_connect.c (1016): Shutdown socket 23 [ > 127.0.0.1:42538 -> 127.0.0.1:15443] and read 0 lingering bytes in 0 sec. > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] > ajp_done::jk_ajp_common.c (3282): recycling connection pool for worker > directory_service and socket -1 > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [debug] > jk_handler::mod_jk.c (2921): Consumed 0 bytes of remaining request data > for worker=directory_service > [Wed Jan 17 14:42:41 2018] [23791:140542260176640] [info] > jk_handler::mod_jk.c (2984): Aborting connection for > worker=directory_service > > And also based on the ajp workers documentation which has specific > recovery_options 4 that closes the connection to tomcat if an error when > writing back the answer to the client is detected. Yes, this is for write > not read. > > So, the next question is whether there is a way to have connections > between apache and tomcat closed when aborted. > > > >> > I therefore think my expectation for an IOException when trying to >> > read is justified. >> > >> > Do you still think otherwise? >> >> I do. It's not really up to Tomcat to verify that the client sent all >> of the data it intended to send. >> >> > George >
