cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1502) remove IClock from internals
Date Wed, 15 Sep 2010 10:27:33 GMT

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

Sylvain Lebresne commented on CASSANDRA-1502:
---------------------------------------------

If we are to include CASSANDRA-1072, we probably need to be carefull with
that. CASSANDRA-1072 does rely on the IClock interface and on reconciliation.

It may well be that CASSANDRA-1072 could be rewritten to stuff the context in
the value instead of the clock. Column with counters would then be a new kind
of Column (as DeletedColumn or ExpiringColumn are). And nothing would make me
more happy.
But I, for one, am not sure if it will work. I see at least a few points that
will need attention:
  * The conflict detection does use the context for counter columns, not the
    timestamp. And when two columns conflict, you need to merge them instead
    of just picking the more recent one. That's one the problem the IClock
    interface was solving. All this logic would have to be internalized in the
    IColumn interface. Not saying it's not doable, I just don't know.
    In particular, internalizing the deletion parts may not be that easy.
  * There's the cleanContext logic of CASSANDRA-1072 (not the nicest part of
    1072 if you ask me, but it's needed). I don't see why this couldn't be
    done if the context is in the value but the devil's in the details.
In any case, I doubt this will be a trivial refactor of CASSANDRA-1072.

Still, Jonathan has a compelling argument when he says that the IClock
interface has probably a non-negligeable performance impact on the normal
path (and it add some more pressure on the GC). And let me here recall that
the counters of 1072 have non-negligeable drawbacks which, until we're able to
fix those (and it's unclear we will be able to), makes the counter useful to
only some people. So my very own opinion is that we should try everything we
could to not impose this performance hit on the normal path.

Maybe one way to go forward without shooting ourselves in the foot would be
first to get rid of everything about clocks that is externally visible. That
includes CASSANDRA-1501 but also:
  * the avro API
  * the clock_type and reconciler in the on-disk format and network protocol.
  * probably a few code cleanup here and there
This ain't too much work and that way, keeping or removing IClock from the
internals wouldn't break any compatibility and thus wouldn't block any 0.7
beta or release.
Then we could try the refactor of 1072 without the IClock interface. If that
fly, fine. If not, at least we'll know why and will be able to apply 1072 with
IClock.

Opinions ?

> remove IClock from internals
> ----------------------------
>
>                 Key: CASSANDRA-1502
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1502
>             Project: Cassandra
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 0.7 beta 1
>            Reporter: Jonathan Ellis
>             Fix For: 0.7.0
>
>
> finish what CASSANDRA-1501 started (i.e., finish reverting CASSANDRA-1070)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message