[
https://issues.apache.org/jira/browse/CASSANDRA-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839485#action_12839485
]
Ross M commented on CASSANDRA-836:
----------------------------------
changing the size of the bitset is only one of the ways things could break.
it's relying on the java BitSet::serialize to stay the same size. if
http://java.sun.com/j2se/1.4.2/docs/api/serialized-form.html#java.util.BitSet
is set in stone and all jdk impls have to implement it the same way it might be
ok. if not things could break.
beyond that i was looking at trying to improve the on-disk size of things and
this blocks me from being able to improve the size of BitSet's with a custom
BitSetSerializer. currently a large percentage of the data is repetitive
serialization info (java classes etc.) java serialization is not very space
efficient. just take a good size commit log with varied data and gzip it, i was
seeing ~10x size reduction. if you reduce the amount of data being written to
the disk each write will take less time...
if a header is going to be re-written like this it would be better to have the
CommitLogHeader write all of it's data out on it's own so that it can make sure
to use a fixed size rather than relying on the underlying implementations.
> CommitLogSegment::seekAndWriteCommitLogHeader assumes header size doesn't
> change.
> ---------------------------------------------------------------------------------
>
> Key: CASSANDRA-836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-836
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: n/a - all
> Reporter: Ross M
> Priority: Minor
> Attachments: BitSetSerializer.java
>
>
> CommitLogSegment::seekAndWriteCommitLogHeader assumes header size doesn't
> grow. there are pieces of the header (BitSet) that are serialized with java
> serialization which makes no such promises.
> the following code:
> /** writes header at the beginning of the file, then seeks back to
> current position */
> void seekAndWriteCommitLogHeader(byte[] bytes) throws IOException
> {
> long currentPos = logWriter.getFilePointer();
> logWriter.seek(0);
> writeCommitLogHeader(bytes);
> logWriter.seek(currentPos);
> }
> works fine as long as the header size doesn't change, but if it grows the new
> header will over write the beginning of the data segment. the bit-set being
> written in the header happens to serialize to the same size, but there is no
> guarantee of this.
> i found this when looking at optimizing the serialization of data to disk
> (thus improving write throughput/performance.) i removed the
> ObjectOutputStream serialization in BitSetSerializer and replaced it with a
> custom serialization that omits the generic java
> serialization/ObjectOutputStream stuff and just writes on the "true" bits.
> the custom serialization worked fine, but broke other parts of the code when
> the header bitset had new bits turned on, thus growing the header's size,
> data segment bytes were overwritten.
> the serialized version of a BitSet can grow in a similar manner, no pomises
> of size/consistency are made, but with current use it luckily doesn't seem to
> happen.
> a good fix is unclear. without forcing the header to be a fixed/constant size
> in some manner this problem could pop up at any point. it's generally not
> safe to rewrite headers like this without custom code that ensures the size
> doesn't change. one fix would be to manually write all of the header data out
> (rather than relying on java serialization and serialization code in other
> parts of cassandra not to change.) another might be to pad the size of the
> header so that the data inside can grow, but that seems fraught with
> (potential) problems. (i've played around with padding the header length, but
> that seems to cause other things to break, which i haven't been able to track
> down yet.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
