[
https://issues.apache.org/jira/browse/ACCUMULO-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13968756#comment-13968756
]
Josh Elser commented on ACCUMULO-2669:
--------------------------------------
bq. A commit hash to go along w/ the line number would be useful.
Current HEAD of 1.6.0-SNAPSHOT (5ab2c15e406a8e6ed83d56589127d6d4114e8182) has
the expected line number.
I was just looking at this. It looks like [~parkjsung]'s diagnosis is accurate.
The same OutputStream object is there, but it's wrapped in that
NoFlushOutputStream. We could add a method to the NoFlushOutputStream that
gives returns the underlying stream which could fix it. That, however, still
seems a bit brittle.
Also verified this with a quick log statement:
{noformat}
Encrypting Log File: class java.io.DataOutputStream, Enciphering output stream:
class org.apache.accumulo.core.security.crypto.NoFlushOutputStream, Log File:
class org.apache.hadoop.hdfs.client.HdfsDataOutputStream
{noformat}
> NoFlushOutputStream always in use in DfsLogger
> ----------------------------------------------
>
> Key: ACCUMULO-2669
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2669
> Project: Accumulo
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Jonathan Park
> Priority: Minor
>
> I may be misreading the implementation of DfsLogger, but it looks like we
> always make use of the NoFlushOutputStream, even if encryption isn't enabled.
> There appears to be a faulty check in the DfsLogger.open() implementation
> that I don't believe can be satisfied (line 384).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
