hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Kirpichov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-200) ContentLengthInputStream.close() is not interruptible and may take an arbitrarily long time to complete
Date Wed, 15 Jul 2009 13:47:14 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731442#action_12731442

Eugene Kirpichov commented on HTTPCORE-200:


I understand that unblocking an IO operation is only possible by closing the socket.

However, I am not talking about unblocking the IO operation at an interrupt (although of course
it would be most desirable :) ): I am merely talking about taking measures to guarantee the
termination of ContentLengthInputStream.close(); it seems rather bad to me that an input stream's
close operation may be non-terminating and may not even be terminated forcibly; one would
expect such guarantees from an IO library like httpclient.

As for the problem with interrupt checks: can't it be solved with using a custom socket factory
somewhere at the core of httpclient? (there probably aren't too many places where sockets
are created?)
The factory could produce sockets whose getInput/OutputStream returns a proxy with read/write
operations performing interrupt checks.
(Probably I'll try precisely this solution myself)

> ContentLengthInputStream.close() is not interruptible and may take an arbitrarily long
time to complete
> -------------------------------------------------------------------------------------------------------
>                 Key: HTTPCORE-200
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-200
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore
>    Affects Versions: 4.0
>            Reporter: Eugene Kirpichov
> The method ContentLengthInputStream.close() reads the entity content to end.
> It does so in a non-interruptible fashion, and thus, if the entity content is too long
(or even infinite), the method may take too much time or not terminate at all.
> I have actually observed this behavior: my program does a time-limited web crawl and,
after the time limit is exceeded, interrupts the crawler thread and expects it to finish soon.
The thread didn't finish in several minutes after the interrupt, because it was stuck in consumeContent()
for some very large entity.
> Actually, execution time of this method for an entity of size N is limited by soTimeout
* N / ContentLengthInputStream.BUFFER_SIZE for the worst case where each call to read() in
the close() method almost causes a socket timeout. This upper limit is definitely too large,
especially for a method that is supposed to release resources.
> It would of course be best if interrupting the thread just caused an IOException in the
underlying SocketInputStream.read(), but I know that this functionality is not implemented
in the JVM (and probably not going to be), so we need a workaround.
> I suggest that ContentLengthInputStream.close() (or someone down its call stack) check
for Thread.currentThread.isInterrputed() between reads from the socket and throw an InterruptedIOException
if it returns true. Probably, this might be done in AbstractSessionInputBuffer.fillBuffer().
> If done so, execution time of this method will be limited by 2*soTimeout, which is already
acceptable and at least predictable.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message