[ https://issues.apache.org/jira/browse/HBASE-21915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16770022#comment-16770022 ]
stack commented on HBASE-21915: ------------------------------- Good one lads. Whats up w/ the call to tryOpen inside the unbuffer? Are we opening the stream when we do this? If fresh open, an unbuffer makes sense? Thanks. > FileLink$FileLinkInputStream doesn't implement CanUnbuffer > ---------------------------------------------------------- > > Key: HBASE-21915 > URL: https://issues.apache.org/jira/browse/HBASE-21915 > Project: HBase > Issue Type: Bug > Components: Filesystem Integration > Reporter: Josh Elser > Assignee: Josh Elser > Priority: Major > Attachments: HBASE-21915.001.patch > > > FileLinkInputStream is an InputStream which handles the indirection of where > the real HFile lives. This implementation is wrapped via > FSDataInputStreamWrapper and is transparent when it's being used by a caller. > Often, we have an FSDataInputStreamWrapper wrapping a FileLinkInputStream > which wraps an FSDataInputStream. > The problem is that FileLinkInputStream does not implement the > \{{CanUnbuffer}} interface, which means that the underlying > {{FSDataInputStream}} for the HFile the link refers to doesn't get > {{unbuffer()}} called on it. This can cause an open Socket to hang around, as > described in HBASE-9393. > Both [~wchevreuil] and myself have run into this, each for different users. > We think the commonality as to why these users saw this (but we haven't run > into it on our own) is that it requires a very large snapshot to be brought > into a new system. Big kudos to [~esteban] for his help in diagnosing this as > well! > If this analysis is accurate, it would affect all branches. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)