cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9673) Improve batchlog write path
Date Wed, 02 Sep 2015 01:58:47 GMT

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

Stefania edited comment on CASSANDRA-9673 at 9/2/15 1:58 AM:
-------------------------------------------------------------

bq. I meant checking for table emptiness at the beginning of startup migration, and logging
once if not empty. 

Right, makes more sense now.

bq. Also, the logic in conversion for != 1 uuids seems a bit weird. It will never be the case
that we'll get a mutation

The replay unit tests were still checking for 1.2 mutations.

bq. There was a bug in SP::syncWriteToBatchlog that is as old as is batchlog itself. We are
using CL.ONE unconditionally, even when we have two endpoints. And both legacy/modern writes
should be sharing the same callback, so I switched back to using WriteResponseHandler for
both.

Thanks for fixing this.

bq.  I think I broke some replay tests. 

I removed the 1.2 mutations from the replay tests. They are fine now.

Rebased again and force pushed, if the latest CI is good then I'm +1 as well:

http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9673-3.0-dtest/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9673-3.0-testall/

Thanks!


was (Author: stefania):
bq. I meant checking for table emptiness at the beginning of startup migration, and logging
once if not empty. 

Right, makes more sense now.

bq. Also, the logic in conversion for != 1 uuids seems a bit weird. It will never be the case
that we'll get a mutation

The replay unit tests were still checking for 1.2 mutations.

bq. There was a bug in SP::syncWriteToBatchlog that is as old as is batchlog itself. We are
using CL.ONE unconditionally, even when we have two endpoints. And both legacy/modern writes
should be sharing the same callback, so I switched back to using WriteResponseHandler for
both.

Thanks for fixing this.

bq.  I think I broke some replay tests. 

I removed the 1.2 mutations from the replay tests. They are fine now.

Rebased again and force pushed, if the latest CI is good then I'm +1 as well:

http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9673-3.0-dtest/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-9673-3.0-testall/
Thanks!

> Improve batchlog write path
> ---------------------------
>
>                 Key: CASSANDRA-9673
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9673
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Aleksey Yeschenko
>            Assignee: Stefania
>              Labels: performance
>             Fix For: 3.0 beta 2
>
>         Attachments: 9673_001.tar.gz, 9673_004.tar.gz, gc_times_first_node_patched_004.png,
gc_times_first_node_trunk_004.png
>
>
> Currently we allocate an on-heap {{ByteBuffer}} to serialize the batched mutations into,
before sending it to a distant node, generating unnecessary garbage (potentially a lot of
it).
> With materialized views using the batchlog, it would be nice to optimise the write path:
> - introduce a new verb ({{Batch}})
> - introduce a new message ({{BatchMessage}}) that would encapsulate the mutations, expiration,
and creation time (similar to {{HintMessage}} in CASSANDRA-6230)
> - have MS serialize it directly instead of relying on an intermediate buffer
> To avoid merely shifting the temp buffer to the receiving side(s) we should change the
structure of the batchlog table to use a list or a map of individual mutations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message