[ https://issues.apache.org/jira/browse/SOLR-12290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465240#comment-16465240 ]
Uwe Schindler commented on SOLR-12290: -------------------------------------- I think I know how to solve this: - Revert all stuf that removed close of code that uses ContentStream - In SolrRequestParsers$HttpRequestContentStream add a CloseShieldInputStream in the getStream() method. This should solve the file leaks caused by no longer closing streams on files... This should make the changes in BlobHandler and CSVLoaderBase obsolete - and code clean again. It's a no-go to not close streams of unknown origin! > Do not close any servlet streams and improve our servlet stream closing > prevention code for users and devs. > ----------------------------------------------------------------------------------------------------------- > > Key: SOLR-12290 > URL: https://issues.apache.org/jira/browse/SOLR-12290 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Mark Miller > Assignee: Mark Miller > Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: SOLR-12290.patch, SOLR-12290.patch, SOLR-12290.patch, > SOLR-12290.patch > > > Original Summary: > When you fetch a file for replication we close the request output stream > after writing the file which ruins the connection for reuse. > We can't close response output streams, we need to reuse these connections. > If we do close them, clients are hit with connection problems when they try > and reuse the connection from their pool. > New Summary: > At some point the above was addressed during refactoring. We should remove > these neutered closes and review our close shield code. > If you are here to track down why this is done: > Connection reuse requires that we read all streams and do not close them - > instead the container itself must manage request and response streams. If we > allow them to be closed, not only do we lose some connection reuse, but we > can cause spurious client errors that can cause expensive recoveries for no > reason. The spec allows us to count on the container to manage streams. It's > our job simply to not close them and to always read them fully, from client > and server. > Java itself can help with always reading the streams fully up to some small > default amount of unread stream slack, but that is very dangerous to count > on, so we always manually eat up anything on the streams our normal logic > ends up not reading for whatever reason. > We also cannot call abort without ruining the connection or sendError. These > should be options of very last resort (requiring a blood sacrifice) or when > shutting down. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org