[
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)
