[
https://issues.apache.org/jira/browse/HTTPCORE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731441#action_12731441
]
Ortwin Glück commented on HTTPCORE-200:
---------------------------------------
I disagree about Thread#isInterrputed(). I am used to include an
Thread#isInterrputed() into possibly long-running loops. Of course this doesn't
help with unblocking a socket, but at least it prevents to keep looping and
blocking AGAIN even though someone wishes to interrupt the thread. This way we
would block for max the SO_TIMEOUT (usually seconds), but not several times
that time (i.e. minutes)!
This is very useful in application server environments, where you configure
your transaction manager to send an interrrupt to the thread after its
transaction times out. This is essential to control resources (namely threads)
in a busy application, in case something bad happens. You simply can not afford
to have a thread running away for several minutes. And thus you really want the
thread to be returned to the pool as soon as possible.
> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
