[
https://issues.apache.org/jira/browse/HTTPCORE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731468#action_12731468
]
Eugene Kirpichov commented on HTTPCORE-200:
-------------------------------------------
I solved my problem by giving httpclient my own socket factory as described.
I understand your arguments about Thread.isInterrupted() being too low-level;
however, I personally don't see much harm in that.
Since the problem has a workaround, I now leave it up to you to decide what
should be done with this problem, and to other people to provide more arguments.
> 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: [email protected]
For additional commands, e-mail: [email protected]
