[
https://issues.apache.org/jira/browse/CASSANDRA-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2285:
----------------------------------------
Attachment: 0001-skip-CL-recover-when-fully-data-was-fully-flushed-wi.patch
I had of wrong understanding of what was going on. The problem is that we can
have a commit log header with a replay position greater than the size of the
commit log.
This happens if some data gets flushed before it had time to hit the actual log
(thus only in periodic mode). Which in turn can happen because we use a
FileOutputStream for the header, which will get sync to disk even if cassandra
dies/is killed shortly afterwards (unless this is a system failure).
It's fairly unlikely to happen in real use, but it is fairly easy to reproduce
(see description).
Attaching a patch using the correct condition as well as a test unit.
> Reading an empty commit log throw an exception
> ----------------------------------------------
>
> Key: CASSANDRA-2285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2285
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7.3
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.7.4
>
> Attachments:
> 0001-skip-CL-recover-when-fully-data-was-fully-flushed-wi.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Start a one node cluster, shutdown within 10 seconds but after the node is
> started and the location infos has been flushed. Restart node, you'll get a
> 'EOFException: unable to seek past the end of the file in read-only mode.'
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
