[ https://issues.apache.org/jira/browse/SOLR-12290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493988#comment-16493988 ]
ASF subversion and git services commented on SOLR-12290: -------------------------------------------------------- Commit 62de5c099476c958229aafe19c3b266fdfec10eb in lucene-solr's branch refs/heads/branch_7x from [~mark.mil...@oblivion.ch] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=62de5c0 ] SOLR-12290: Do not close any servlet streams and improve our servlet stream closing prevention code for users and devs. (cherry picked commit 2962010 + 5fc7251 + 4c09a13 + ab58b7f) > 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: master (8.0) > > Attachments: SOLR-12290.patch, SOLR-12290.patch, SOLR-12290.patch, > SOLR-12290.patch, SOLR-12290_7x.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