Hi Olaf, Just repeat here what I have already replied to André’s comment. “First about network. Client and server are in the same segment and there are no firewalls in between them. Second I expect connection to be alive because during initiation I specify 'keep-alive' property of HTTP request. Also Tomcat and WLS are configured to support keepalive connections. From what I noticed, I monitored TCP connection using TCPView and Wireshark (on the client side), TCP connection is still alive even Tomcat or WLS cannot write to the socket. Just to mention, I have in my code an option to send periodical heartbeats to the client if there is no data. It is configurable and when I use this option everything works fine. But if I don’t send heartbeats as I wrote before connection becomes stale and I want to understand why it happens so that I can initiate, for example, automatic client logoff and cleanup resources.”
On 29/01/16 16:13, "Olaf Kock" <tom...@olafkock.de> wrote: >I'll second Andre's answer: Just because you declare a 10d timeout, you >can't rely on the connection to stay up for that long. You can't even >rely on a connection to stay up during the download of a simple gif >(although that's so quick that the odds for connection termination are a >lot lower). > >This is without looking at the code - just relying on a connection to >stay up is not a proper assumption. You'll have to work around anything >in between to fail and reconnect if necessary. Declaring a 10d timeout - >if it works - will cause the appropriately configured endpoint to assume >it's open. It has no effect on any of the components in between the >endpoints. > >Olaf > >Am 29.01.2016 um 09:33 schrieb André Warnier (tomcat): >> On 28.01.2016 18:38, Maxim Neshcheret wrote: >>> I have a problem with my java application related to HTTP >>>communication. >>> >>> Application description: >>> >>> 1. Client – server. Server is running in servlet container. We >>> use Tomcat. >>> >>> Client use java HTTP library to communicate with the server. >>> >>> 2. When client establish connection to the server it sends GET >>> request (keepalive) and server creates AsyncContext for the client >>> with 10 days timeout. >>> >>> 3. After connection established server periodically sends data >>> to the client using AsyncContext and on the client side there is >>> special thread which reads and processes the data. >>> >> [ snip ...] >>> >>> Usually this code works fine but it there is no data from server to >>> client for 1 day and after 24 hours (can be 16 or 12) data appears, >>> server cannot send data to the client. >>> In the log there is no error. It is written that everything flushed >>> but client still waiting for data in “final String line = >>> reader.readLine();” >>> When 2nd portion of data is sent by the server, then during flush I >>> see the following error >>> >>> 2016-01-26 00:00:00,051|INFO |GWNotify-2/50 |ClientAbort >>> 2016-01-26 00:00:00,051|TRACE|GWNotify-2/50 >>> |ClientAbortException:java.io.IOException: APR error: -32 >>> org.apache.catalina.connector.ClientAbortException: >>> java.io.IOException: APR error: -32 >> [snip ...] >> >> Hi. >> I am unqualified to check your code, but a first question would be : >> where is the Client, and where is the Server and what is the >> connection between them like ? >> >> And the reason for the question is : it is not at all unusual, that >> any kind of network connection would be interrupted at some point over >> a 24-hour period, specially if nothing is sent over that connection >> for a long time. >> When a connection "disappears", TCP sends no signal to either the >> client or the server, and an error will only be caught, if one of the >> parties tries to write to the (now gone) connection (which seems to be >> what happens above, when the server tries to write to the Client, and >> gets a "client is no longer there" exception). >> >> If you want to avoid this, you will have to handle this in your code. >> You cannot just expect the connection to be alive no matter what. >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org >
