[
https://issues.apache.org/jira/browse/SOLR-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767754#comment-17767754
]
Chris M. Hostetter commented on SOLR-16983:
-------------------------------------------
{quote}(are you not a fan of github PRs?)
{quote}
I am not. (I don't mind looking at PR links from jira, but i don't create PRs
myself, and i don't go out of my way to hunt for PRs)
{quote}I posted another potential fix of a missing close in a test
[https://github.com/apache/solr/pull/1947] which was probably surfaced by this
change.
{quote}
I was aware of those jenkins failures when i created this issue – it was
actually one of the reasons i started looking into where/why/how
ObjectReleaseTracker was being used in our test-framework, because i couldn't
understand how we could be leaking {{"h2sc"}} threads w/o seeing
ObjectReleaseTracker complainingg about un-closed instances of
{{{}Http2SolrClient{}}}...
The thing your PR overlooks is that the {{StreamingTest.getTuple(estream);}}
call is already going to call {{estream.close()}} internally – unless the
{{open()}} or {{read()}} calls throw an Exception – but if they did that then
{{testExceptionStream()}} stream would propogate that exception and the test
method would fail (in addition to the leaked threads/objects) .. but it doesn't
fail, because the point of the {{ExceptionStream}} method is to swallow those
exceptions – so {{estream.close()}} is (almost certainly) being called already
.... the question is whether everything {{ExceptionStream}} hangs on to is
being closed.
Since the jenkins failures don't reliably reproduce on other machines, the
problem isn't deterministic (based on the seed) and is likely related to thread
scheduling/concurrency.
I have a loose theory about these {{StreamingTest}} failures that i'll file in
a new jira later today once i have a chance to think it through fully, and I'll
make sure to tag you in it you want to investigate further.
> ObjectReleaseTracker completely useless in all SolrTestCaseJ4 based tests -
> masking unclosed InputStream in some SolrStream usecases
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-16983
> URL: https://issues.apache.org/jira/browse/SOLR-16983
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-16983-1.patch, SOLR-16983-2.patch,
> SOLR-16983.bug-demo.nocommit.patch, SOLR-16983.patch,
> test-output-if-clear-is-removed-from-SolrTestCaseJ4.txt.gz
>
>
> {panel:title=NOTE: This was masking a real bug in SolrStream}
> Fixing tests that fialed while working on this bug lead me to discover that
> some usages of {{SolrStream}} weren't closing their {{TupleStreamParser}}
> which could result in unclosed {{InputStream}} (returned from the underlying
> HTTP client)
>
> {panel}
> {{SolrTestCase}} has a {{@ClassRule}} named {{solrClassRules}} which calls
> {{ObjectReleaseTracker.clearObjectTrackerAndCheckEmpty()}} in it's
> {{afterIfSuccessful()}} method to ensure that any objects which use
> {{ObjectReleaseTracker}} are correctly released (ie: closed)
> _*...BUT...*_
> {{SolrTestCaseJ4}} has an {{@AfterClass}} method named
> {{teardownTestCases()}} which calls {{ObjectReleaseTracker.clear()}} _before_
> the {{afterIfSuccessful()}} method of it's parent class's {{solrClassRules}}
> gets to run.
> ... Which means that {{ObjectReleaseTracker}} is completley useless in every
> test that descends from {{{}SolrTestCaseJ4{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
