[
https://issues.apache.org/jira/browse/HDFS-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049973#comment-13049973
]
Konstantin Shvachko commented on HDFS-1989:
-------------------------------------------
Seems like a valid bug.
Client does not directly talk to BN, but NN sends the journal transaction
(close in the case). And if that kicks in when BN closed edits, but hasn't
reopened them yet, the exception can happen.
Todd's right the transaction should go into journal spool, but I suspect that
{{edits.close()}} closes all streams including the spool, and that could be the
problem.
> When checkpointing by backup node occurs parallely when a file is being
> closed by a client then Exception occurs saying no journal streams.
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-1989
> URL: https://issues.apache.org/jira/browse/HDFS-1989
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.23.0
> Reporter: ramkrishna.s.vasudevan
> Fix For: 0.23.0
>
>
> Backup namenode initiates the checkpointing process.
> As a part of checkpointing based on the timestamp it tries to download the
> FSImage or use the existing one.
> Then it tries to save the FSImage.
> During this time it tries to close the editLog streams.
> Parallely when a client tries to close a file just after the checkpointing
> process closes the editLog Stream then we get an exception saying
> java.io.IOException: java.lang.IllegalStateException: !!! WARNING !!! File
> system changes are not persistent. No journal streams.
> Here the saveNameSpace api closes all the editlog streams resulting in this
> issue.
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
