hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Stale connection check in NHttpConnectionBase and DefaultListeningIOReactor
Date Thu, 05 Jul 2012 21:30:11 GMT
On Thu, 2012-07-05 at 22:25 +0400, Dmitry Potapov wrote:
> Hello everyone,
> I develop streaming HTTP server for my project and used HttpCore NIO
> for this purpose.
> Interruptible heavy-weight task takes place before streaming start,
> so, I'm interesting in any mechanism that provides connection status
> check, because I have tons of requests which terminates connection
> before I start streaming.
> APIs I've already tried:
> 1. HttpAsyncExchange.setCallback() — doesn't work, cancel() function
> of the registered callback was never called. Doesn't matter how
> connection was terminated, with RST or FIN.


There is a test case specifically intended to test Cancellable callback
for HTTP exchanges 


If this functionality is broken I would like to know how the problem can
be reproduced.

> 2. NHttpConnectionBase.isStale() — doesn't work, as it does nothing
> but session.isClosed(), which significantly differs from
> HttpConnection.isStale() behaviour.

The stale connection check is needed for blocking connections only as
the blocking I/O model provides no way of finding out whether a
connection is half-closed unless a attempt is made to read from the
underlying socket. Non-blocking connections can immediately react to I/O
events due to their asynchronous nature and can either be open or
closed, but never stale. The behavior of #isStale method is different
because blocking and non-blocking connections work entirely differently.

> 3. NHttpConnectionBase.getSocket().sendUrgentData() — doesn't work, as
> IOReactors configures socket with non-blocking mode, and I haven't
> found way to change this (most probably this shouldn't be changed).
> Is there any other ways I missed? Is there any mechanism (even
> expensive one) to check connection status?
> P.S. I'm using version 4.2.1.
> P.P.S I'm using InputStreamEntity over PipedInputStream for streaming.

I am not entirely sure InputStream interface is the best fit for
streaming large amount of data asynchronously. You should consider using
HttpAsyncContentProducer instead (probably along with SharedOutputBuffer
if the content is generated by a different thread). 


Hope this helps somewhat.


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

View raw message