[
https://issues.apache.org/jira/browse/HTTPCORE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731431#action_12731431
]
Oleg Kalnichevski edited comment on HTTPCORE-200 at 7/15/09 6:19 AM:
---------------------------------------------------------------------
Eugene,
The only truly reliable way of unblocking an I/O operation or terminating a
socket bound process I am _personally_ aware of is closing the underlying
network socket. Thread#interrupt() will not unblock the thread if blocked in an
I/O operation and may require tons of ugly Thread#isInterrputed() checks all
over the place.
Anyways, Thread#isInterrputed() do not belong to a library. For your particular
application you should consider subclassing SocketInputBuffer and overriding
its #fillBuffer().
If I hear no objections I'll close this issue as WONTFIX
Oleg
was (Author: olegk):
Eugene,
The only truly reliable way of unblocking an I/O operation or terminating a
socket bound process I am _personally_ aware of is closing the underlying
network socket. Thread#interrupt() will not unblock the thread if blocked in an
I/O operation and may require tons of ugly Thread#isInterrputed() checked all
over the place.
Anyways, Thread#isInterrputed() do not belong to a library. For your particular
application you should consider subclassing SocketInputBuffer and overriding
its #fillBuffer().
If I hear no objections I'll close this issue as WONTFIX
Oleg
> 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]
