cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terje Marthinussen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2604) EOFException on commitlogs
Date Wed, 04 May 2011 23:10:03 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029033#comment-13029033
] 

Terje Marthinussen commented on CASSANDRA-2604:
-----------------------------------------------

Time for some sleep, but I stepped through this code with a bad commit table (not the same
which caused the above error though, but produces same stack).

    public void deserializeColumns(DataInput dis, ColumnFamily cf, boolean intern, boolean
fromRemote) throws IOException
    {
        int size = dis.readInt();
        ColumnFamilyStore interner = intern ? Table.open(CFMetaData.getCF(cf.id()).left).getColumnFamilyStore(cf.id())
: null;
        for (int i = 0; i < size; ++i)
        {
            IColumn column = cf.getColumnSerializer().deserialize(dis, interner, fromRemote,
(int) (System.currentTimeMillis() / 1000));
            cf.addColumn(column);
        }
    }

The size of the buffer underlying "dis" is 153 byte.

"size" in the above code is 4.

With i == 2 finished, dis has just reached position 153 (perfectly) in the underlying buffer,
although I cannot guarantee that the value is completely read.

Obviously, when trying to read at i==3, it crashes as it is already at the end of the buffer.

I would expect the entry which it is trying to decode in this case to have 4, not 3 columns.

I do see some of my own code is actually involved here, but unless the commitlog does its
own serialization fully or partly and uses the "standard" deserializer my code is unlikely
to cause any problems like this.

> EOFException on commitlogs
> --------------------------
>
>                 Key: CASSANDRA-2604
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2604
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.8 beta 1
>            Reporter: Terje Marthinussen
>            Assignee: Sylvain Lebresne
>
> I have seen this occasionally since we started testing 0.8.
> It happens when reading commitlogs on startups.
> However, I have seen it a lot less on 0.8 beta2 (although this is from beta 2)
> ERROR [main] 2011-05-04 18:02:38,134 AbstractCassandraDaemon.java (line 330) Exception
encountered during startup.
> java.io.EOFException
> 	at java.io.DataInputStream.readByte(DataInputStream.java:250)
> 	at org.apache.cassandra.utils.ByteBufferUtil.readShortLength(ByteBufferUtil.java:357)
> 	at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:368)
> 	at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:252)
> 	at org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:43)
> 	at org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:136)
> 	at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:126)
> 	at org.apache.cassandra.db.RowMutation$RowMutationSerializer.deserialize(RowMutation.java:368)
> 	at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:256)
> 	at org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:157)
> 	at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:173)
> 	at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:313)
> 	at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80)
> Note that the line numbers on columnserializer may be off due to some local changes,
but those changes are in code not executed in this case and I am 100% sure they do not trigger
this problem.
> I looked on this in the debugger in eclipse on a trunk from 0.8 2 weeks ago, and the
interesting thing I saw was that according to the debugger, the offset of the inputstream
to the deserializer was already at the end (very last byte) of the underlying bytebuffer but
according to the stack, it was trying to read the length of the column name (first read done
in the deserialized).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message