incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Ticket CASSANDRA-3578 - Multithreaded CommitLog
Date Sun, 11 Dec 2011 07:15:39 GMT
2011/12/8 Piotr Kołaczkowski <pkolaczk@ii.pw.edu.pl>:
> Can someone tell me what is the use pattern of the CommitLog#add method? I
> mean, is it possible, that a single thread calls add many times, remembers
> the returned Future objects and *then* waits on all / some of them? Or is it
> always like: add, then wait (until the Future is ready), add, wait, add,
> wait... ?

I'm not sure what you're looking at, since CommitLog#add returns void
and so does AbstractCommitLogExecutorService#add.  There is only one
caller of CommitLog#add outside of the test code.

I think you should take a look at the executor implementations and
what kinds of guarantees they're trying to provide.  That may make it
more clear what kind of approach you want to take.  (I suspect it's
going to be a lot more difficult to multithread the Batch executor,
for instance.  Does that mean we ignore it entirely and say "sorry, we
can only provide single-threaded commitlog in batch mode?"  Or take
two different approaches?  Or can we do one approach for both after
all?)

I'd also point you to RowMutation.preserializedBuffers -- when we
receive a RM from another node, we keep the byte[] we deserialized it
from, so we don't need to reserialize it for the CommitLog.  So I'd
avoid spending a ton of effort parallelizing the serialize, since in
the real world it's usually a no-op.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Mime
View raw message