Vishal K commented on ZOOKEEPER-933:

I looks like we need a way to uniquely identify the observer after we receive a 
connection. One way to do this is to get IP address from the socket. But this 
is not a good idea.

Instead, we can ask the observer to generate a unique id (uuid or crypto hash) 
and send <sid, role, uuid> after connecting to a peer (instead of just sid in 
the current implementation).
>From role, QCM can figure out that the node is observer. It can then ignore 
>the sid and use the uuid passed by the observer.

For followers and leader we will use sid as identifier and for observers we 
will use uuid.

How does that sound?

> Remove wildcard  QuorumPeer.OBSERVER_ID
> ---------------------------------------
>                 Key: ZOOKEEPER-933
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-933
>             Project: Zookeeper
>          Issue Type: Sub-task
>            Reporter: Vishal K
>             Fix For: 3.4.0
> 1. I have a question about the following piece of code in QCM:
> if (remoteSid == QuorumPeer.OBSERVER_ID) {
>  /* * Choose identifier at random. We need a value to identify * the 
> connection. */ 
> remoteSid = observerCounter--;
> LOG.info("Setting arbitrary identifier to observer: " + remoteSid); 
> }
> Should we allow this? The problem with this code is that if a peer
> connects twice with QuorumPeer.OBSERVER_ID, we will end up creating
> threads for this peer twice. This could result in redundant
> SendWorker/RecvWorker threads.
> I haven't used observers yet. The documentation
> http://hadoop.apache.org/zookeeper/docs/r3.3.0/zookeeperObservers.html
> says that just like followers, observers should have server IDs. In
> which case, why do we want to provide a wild-card?

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

Reply via email to