[
https://issues.apache.org/jira/browse/ZOOKEEPER-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151019#comment-14151019
]
some one commented on ZOOKEEPER-2031:
-------------------------------------
> From your last comments it seems that the answers to my questions change too,
> right ?
Yes, only for question 2 though.
> It seems that the tag is similar - no matter what tag you wrote in the
> joiner's initial config, you'll be able to add it with any tag. Is that
> correct ? If not, what in the code prevents you from doing that ? (btw, I'm
> not saying its wrong to do it this way, just trying to understand the
> behavior).
Yes, that is correct and is confirmed in the comment above yours.
> Also for reconfig, since you're saying that you're able to change an existing
> server's tag dynamically, there should probably be a test for this.
There is a commented test in the patch on reviewboard that will exercise this
scenario. The asserts in there may be incorrect, but the setup will exercise
this scenario.
> The check in FLE is not symmetric - it checks that the receiver's id has the
> same tag in both sender and receiver, but sender's id is not checked
> similarly. Is this intended ?
I didn't see the point in checking the sender's id and tag. Because I was just
intending for the receiver to just reject the sync. My perspective on this is
that you can either make sure the sender never sends the request (not possible
due to old versions not containing this logic), or with how I did it, have the
receiver reject the request.
> Also, I'm not 100% sure but my intuition says that if you need a change in
> FLE you also need a change in leader-follower connection protocol, since FLE
> is just an optimization. For example checks like "leader is ahead of
> followers" are happening during connection in LearnerHandler.
Yea, FLE is probably not the best place to put this logic. My only intention
with the patch was just to have a receiver reject syncs from existing clusters
if the tags don't match. I'm not really attached to any specific way of doing
it, I'm just not very familiar with the code base and the FLE path seemed to be
the initial connection path that would lead to the sync, so I implemented it
there and it seems to work. So I'm open to any suggestions as to where we
should implement this rejection logic instead.
> One more thing. Could it happen that you connect 2 servers with id 7 but
> different tags ? Then when you do reconfig both adopt the same tag (according
> to what was specified in reconfig). What prevents this ?
Yes, you can probably connect 2 servers with the same id but different tags.
There is nothing in Zookeeper itself to prevent this, but in my use case, the
application will make sure that a reconfig add is not invoked on the new server
if server already exists in the config but has a different tag. The idea is
that even though multiple servers are connected to the cluster, the new server
with the new tag, won't get synced, and the old server with the old tag will
eventually be removed before a reconfig add is invoked on the new one.
Is there anything today (without tags) that prevents the same scenario? If not,
then we don't really get any worse off behavior with this patch, but at least
the application performing the reconfigs will be able to make use of the tags
to do the right thing.
> Support tagging a QuorumServer
> ------------------------------
>
> Key: ZOOKEEPER-2031
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2031
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Reporter: some one
> Assignee: some one
> Fix For: 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2031-Additional.patch, ZOOKEEPER-2031.patch
>
>
> Currently ZooKeeper only allows using the server id which is an integer for
> identifying servers. For my (unavoidable) use case, there may be concurrent
> dynamic removes and adds of servers which may eventually have id collisions.
> When this occurs, there is no good way to determine if the server (given an
> id collision) that we want to remove is the right server.
> To support my use case, I propose that we add a tag field to the server
> string.
> For my specific use case, this tag field will be used to store a uuid as a
> string.
> So for example:
> server.1=127.0.0.1:1234:1236:participant;0.0.0.0:1237;743b9d23-85cb-45b1-8949-930fdabb21f0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
