[
https://issues.apache.org/jira/browse/SOLR-16129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515669#comment-17515669
]
Chris M. Hostetter commented on SOLR-16129:
-------------------------------------------
{quote}... I plan to add a new unit test of the Listener that shows
{{{}getInputStream().read(){}}}: ...
{quote}
I've commit the tests to branch {{jira/solr-16129}} but while working on them i
realized that the changes don't actaully work _quite_ the way i intended them
to.
It should still be true that the code, as written, won't hang forever – but
that's really just because of the (default) {{requestTimeout}} – the
{{waitLimit}} doesn't actaully cause any TimeoutExceptions on it's own (if for
example you use {{setRequestTimeout(null)}} ) .. the reason is because i tried
to keep the changes to a minimum, and am still using {{Object.wait()}} which
doesn't indicate anything about why it returns (and i'm not checking, except
for {{requestTimeout}} - but that check is only if there is no new bytes)
The "right" solution is to to go the route [jetty PR
7260|https://github.com/eclipse/jetty.project/pull/7260] wants to go – using a
{{ReentrantLock}} – and add in our "min of waitLimit vs requestTimeout" logic.
I've included nocommits in the code and test (showing where/why one test method
passes for the wrong reason) to this effect, and will try to have "the right"
fix by ~monday.
> Solr specific InputStreamResponseListener to prevent client threads from
> hanging forever
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-16129
> URL: https://issues.apache.org/jira/browse/SOLR-16129
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-16129.patch
>
>
> This issue tracks the implementation of workaround I suggested for SOLR-16099
> - it does not _fix_ the underlying bug (which as of this writting doesn't
> have an identified root cause) but it does ensure that client threads which
> encounter the bug won't hang forever...
> {quote}One thing we may want to consider (in Solr) is replacing our usage of
> {{InputStreamResponseListener}} with a variant implementation that uses a
> "timeout" instead of an unlimited {{wait()}} (along the lines of a [spin-off
> jetty enhancement issue|https://github.com/eclipse/jetty.project/issues/7259]
> one of the jetty devs filed). We could probably (with some effort) tweak the
> impacted Solr APIs to propogate the (remaining) {{timeAllowed}} (if that
> option was specified) down to this class – and/or have an "extreme" default
> (ie: 30min) just to prevent threads from sticking around forever.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
