cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Chemouil <>
Subject Re: Refactoring cassandra service package
Date Tue, 03 Jun 2014 19:20:56 GMT
Gary Dusbabek racontait le 03/06/2014 19:59:
> This has come up before. Let's face it, removing the singletons is a
> tempting proposition.
> Several of us have been down the path of trying to do it.
> At the end of the day, here's what you'd end up with (absolutely best case):
> 1. Modifying just about every class, sometimes substantially.
> 2. A huge patch for someone else to review.
> 3. No performance gains, no bug fixes.  In fact, since so many classes have
> to be changed, I'd say that the risk of introducing a bug/regression is
> fairly likely.
> 4. Complicated merges when bugs need to be fixed in older versions.
> 5. More modular and testable code.
> So far, the positive aspects of 5 have not been able to trump the
> challenges presented by 1, 2, 3, and 4.

Thanks for your reply. I understand the reasoning, yet obviously I think
your 5th point weighs a lot more than the others, because it also means
more hackable code, and though a huge patch might be scary, seeing so
many static fields is scary as well ;).

We could make the patch more manageable by splitting it in several
patches, one per 'service', and start from the leaves of the dependency
graph (services not using other services), but we'd have to apply the
patches in a specific order. Still, it would make it easier to review.

The 3rd point is I guess usual in the life of an healthy project: fixing
the 'technical debt' the project accumulated over the years seems almost
as important as fixing bugs and improving performance. While doing it,
we would also port the tests and hopefully introduce new tests to make
sure we didn't introduce bugs, and generally be careful we don't break
anything. Yes, there might be new bugs, probably the kind of bugs that
are already there but lurking because of the initialization order or
relying on specific side-effects, but those already exist and might pop
out any time. Refactoring this code seems, for the most part, to be a
fairly repetitive process and doing it carefully should allow to avoid
most bugs introduced by inattention.

The (4) is an important problem, but merging this would probably mean a
major version bump (e.g, within the 3.0.0 branch), and at some point in
time, older versions will reach their EOL. It seems to me that only bug
fixes are backported, and the patches already have to be adapted for the
1.x branch... But unless people give up entirely on the idea of fixing
this, this problem is going to become worse as time goes by.



> Kind Regards,
> Gary.
>> Cheers,
>> --
>> Simon
>> [1]

View raw message