(and if the message is being decoded on the server si=
te as a complete message, then presumably the same resident memory consumpti=
on applies there too).

Yerp. <=
/div>

And every row mutation in your batch becomes a t=
ask in the Mutation thread pool. If one replica gets 500 row mutations from o=
ne client request it will take a while for the (default) 32 threads to chew t=
hrough them. While this is going on other client request will be effectively=
blocked.

Depending=
on the number of clients, I would start with say 50 rows per mutation and k=
eep and eye of the *request* latency.

Thanks for the clarif=
ication Andrey. If that is the case, I had better ensure that I don't put th=
e entire contents of a very long input stream into a single batch, since tha=
t is presumably going to cause a very large message to accumulate on the cli=
ent side (and if the message is being decoded on the server site as a comple=
te message, then presumably the same resident memory consumption applies the=
re too).

Cassandra uses thrift messages to pass data to and from=
server. A batch is just a convenient way to create such message. N=
othing happens until you send this message. Probably, this is what you call "=
close the batch".

I'd like my app to stream a large number of events into Cassandra that origi=
nate from the same network input stream. If I create one batch mutation, can=
I just keep appending events to the Cassandra batch until I'm done, or are t=
here some practical considerations about doing this (e.g. too much stuff buf=
fering up on the client or server side, visibility of the data within the ba=
tch that hasn't been closed by the client yet)? Barring any discussion about=
atomicity, if I were able to stream a largish source into Cassandra, what w=
ould happen if the client crashed and didn't close the batch? Or is this kin=
d of thing just a normal occurrence that Cassandra has to be aware of anyway=
?