accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4050) Serialize table configs into a single ZK node
Date Tue, 13 Sep 2016 01:46:20 GMT

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

Josh Elser commented on ACCUMULO-4050:
--------------------------------------

bq. I mean an object that is composed of the configuration (set of key value pairs) deserialized
from ZK, as well as functions to perform the serialization/deserialization, and which can
atomically swap out the reference to the complete configuration.

This doesn't really help clarify the things that are vague to me :). Let me try to guess instead;
maybe that will help describe what is not clear to me. A table would have multiple containers:
one for the dynamic system-wide properties, one for the dynamic namespace-wide properties,
and one for the dynamic table-specific properties? And these containers could be merged together
(as per the currrent precedence of table > namespace > system)? Or, would the container
be abstracting this hierarchy away?

bq. By "snapshot", I mean an isolated immutable view of the entire set of configuration (k-v
pairs) at a single point in time

bq. I suppose we could incorporate the ZNode Version into the snapshot object or its containers
somehow

I think allowing a snapshot to have know what "time" it was created at would be all that we'd
really need. Even if it's just a no-op now (always 0) or just {{System.currentTimeMillis()}},
we could easily swap in the necessary info from ZK down the road to piece together the logic
to determine when every server has seen (at least) some update.

bq. Any of that would definitely be follow-on work.

Yes, completely. My only concern is that if you/Michael step up to do this work, let's look
a few feet in front of us to make sure we at least don't make solving the client/server config
disconnect harder :) What you have outlined so far sounds like a nice building block to fixing
this stupid problem once and for all.

> Serialize table configs into a single ZK node
> ---------------------------------------------
>
>                 Key: ACCUMULO-4050
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4050
>             Project: Accumulo
>          Issue Type: Sub-task
>            Reporter: Christopher Tubbs
>             Fix For: 2.0.0
>
>
> Use a single ZK node to store table configs, rather than split across multiple configs.
This should make it easier to implement atomic changes to the configuration, and should simplify
reading loading/saving configuration from/to ZooKeeper.



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

Mime
View raw message