Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Message-ID: <1412859554.28277.18.camel@ubuntu>
Subject: Re: Connection termination issue (sometimes connections are not
 closed after receiving [FIN, ACK] from server)
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
Date: Thu, 09 Oct 2014 14:59:14 +0200
In-Reply-To: 
 <CAL1_ndwXaXYVBooGGNdmb+HKfyKfVd3UYwJazyn7Cs-Tyes-kA@mail.gmail.com>
References: 
	<CAL1_ndwXaXYVBooGGNdmb+HKfyKfVd3UYwJazyn7Cs-Tyes-kA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

On Thu, 2014-10-09 at 16:43 +0530, Jayanga Dissanayake wrote:
> Hi All,
> 
> We are using WSO2ESB [1], and we want to communicate with a web server via
> HTTPS. While we were trying to communicate with the web service, we
> observed some weired behavior in the client side, when we analyzed the
> tcpdump, found that, client sometimes try to send application data after
> the [FIN, ACK] is received from the server, and server sends a [RST] after
> we send application data. (Here, in this case, my end point is a HIS server)
> 
> As I know, according to the TCP spec, its allowed to send data via a half
> closed connection. But in this case I want to stop sending data,
> immediately after detecting the half closed connection. So, tried to put
> debug points at endOfInput(), in all the implementation classes found in
> synapse.transport and apache.http,  and see whether I can detect the
> connection close from the server end. The break points were hit at the
> times when the connection termination happens properly. But not at the
> times when application messages were sent after the [FIN, ACK].
> 
> It seems like the connection termination from the remote end is not
> detected. Please read the below for more information.
> 
> Once we create the connection with the back end service, response header
> looks,
> 
> [2014-10-09 13:52:09,516] DEBUG - wire >> "HTTP/1.1 200 OK[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "Date: Thu, 09 Oct 2014 08:22:07
> GMT[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "X-Powered-By:
> Servlet/3.0[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "SOAPAction: ""[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "Accept: text/xml[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "Keep-Alive: timeout=10,
> max=100[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "Connection: Keep-Alive[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "Transfer-Encoding:
> chunked[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "Content-Type: text/xml[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "Content-Language: en-US[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "[\r][\n]"
> [2014-10-09 13:52:09,516] DEBUG - wire >> "20b[\r][\n]"
> 
> As indicated in the Keep-Alive field, connection termination initiated from
> the server end, after idle time of 10 seconds,
> 
> 1206 72.626148 [BackEndServerIP] [MyIP] TCP 60 https > 59949 [FIN, ACK]
> Seq=5230 Ack=2024 Win=19024 Len=0
> 
> As a response it sent an ACK to the server,
> 
> 1207 72.665189 [MyIP] [BackEndServerIP] TCP 54 59949 > https [ACK] Seq=2024
> Ack=5231 Win=24840 Len=0
> 
> After that it sends application data to the server,
> 
> 1940 120.137122 [MyIP] [BackEndServerIP] TLSv1 443 Application Data
> 1941 120.137419 [MyIP] [BackEndServerIP] TLSv1 1275 Application Data
> 
> Then server sends a RST,
> 
> 1949 120.182599 [BackEndServerIP] [MyIP] TCP 60 https > 59949 [RST]
> Seq=5231 Win=0 Len=0
> 
> Note: there is a considerable time gap between ACK and first application
> data packet (72.665189 – 120.137122)
> 
> 1. My first questions is, why sometimes the client end sends just a ACK for
> the server side [FIN, ACK]. If client can send a [FIN, ACK] and gracefully
> terminate the connection, my problem is solved.
> 2. As we have problem (1), Is there anyway to detect partially closed
> connection, so that we can call close() or shutdown() to close the client
> end.
> 

Jayanga

Unfortunately to my knowledge there is simply no way to control TCP
signals from Java. TCP signals are received and sent by JRE and the way
it is done is entirely out of application control. #endOfInput() should
always get fired when the channel returns -1 on a read operation. If it
does not, there is really not much one can do.

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org