[
https://issues.apache.org/jira/browse/CASSANDRA-15066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862083#comment-16862083
]
Benedict edited comment on CASSANDRA-15066 at 6/12/19 1:13 PM:
---------------------------------------------------------------
bq. that it'd be great to separate them from the final commit
As I say, I strongly believe TODOs are useful to leave in the codebase more
generally. They provide context on decision making; regular prompts for future
readers of the code, in context, that certain flaws remain; and help
maintainers make improvements alongside other work that is touching a given
pathway.
I don't really understand or subscribe to the idea that only Jira should know
about flaws, particularly given Jira is not easily browsed in relation to the
code. What purpose does removing them from their context serve?
(In fact I'd go a step further in opposition and suggest every Jira for which
it is possible should have a corresponding TODO in the code, in context,
possibly with a link to the Jira)
was (Author: benedict):
bq. that it'd be great to separate them from the final commit
As I say, I strongly believe TODOs are useful to leave in the codebase more
generally. They provide context on decision making; regular prompts for future
readers of the code, in context, that certain flaws remain; and help
maintainers make improvements alongside other work that is touching a given
pathway.
I don't really understand or subscribe to the idea that only Jira should know
about flaws, particularly given Jira is not easily browsed in relation to the
code. What purpose does removing them from their context serve?
> Improvements to Internode Messaging
> -----------------------------------
>
> Key: CASSANDRA-15066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15066
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
> Reporter: Benedict
> Assignee: Benedict
> Priority: High
> Fix For: 4.0
>
> Attachments: 20k_backfill.png, 60k_RPS.png,
> 60k_RPS_CPU_bottleneck.png, backfill_cass_perf_ft_msg_tst.svg,
> baseline_patch_vs_30x.png, increasing_reads_latency.png,
> many_reads_cass_perf_ft_msg_tst.svg
>
>
> CASSANDRA-8457 introduced asynchronous networking to internode messaging, but
> there have been several follow-up endeavours to improve some semantic issues.
> CASSANDRA-14503 and CASSANDRA-13630 are the latest such efforts, and were
> combined some months ago into a single overarching refactor of the original
> work, to address some of the issues that have been discovered. Given the
> criticality of this work to the project, we wanted to bring some more eyes to
> bear to ensure the release goes ahead smoothly. In doing so, we uncovered a
> number of issues with messaging, some of which long standing, that we felt
> needed to be addressed. This patch widens the scope of CASSANDRA-14503 and
> CASSANDRA-13630 in an effort to close the book on the messaging service, at
> least for the foreseeable future.
> The patch includes a number of clarifying refactors that touch outside of the
> {{net.async}} package, and a number of semantic changes to the {{net.async}}
> packages itself. We believe it clarifies the intent and behaviour of the
> code while improving system stability, which we will outline in comments
> below.
> https://github.com/belliottsmith/cassandra/tree/messaging-improvements
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
