2011/12/8 Piotr Kołaczkowski <pkola...@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
