Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of christian.ziech@nokia.com
 designates 147.243.128.26 as permitted sender)
Message-ID: <4F60CED2.5080601@nokia.com>
Date: Wed, 14 Mar 2012 18:01:06 +0100
From: Christian Ziech <christian.ziech@nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: <user@zookeeper.apache.org>
Subject: Re: Zookeeper on short lived VMs and ZOOKEEPER-107
References: <4F60C181.90802@nokia.com>
In-Reply-To: <4F60C181.90802@nokia.com>
Content-Type: multipart/alternative;
	boundary="------------070204030607000506010201"

--------------070204030607000506010201
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 8bit

Just a small addition: In my opinion the patch could really boil down to 
add a

    quorumServer.electionAddr = new
    InetSocketAddress(electionAddr.getHostName(), electionAddr.getPort());

in the catch(IOException e) clause of the connectOne() method of the 
QuorumCnxManager. In addition on should perhaps make the electionAddr 
field in the QuorumPeer.QuorumServer class volatile to prevent races.

I haven't checked this change yet fully for implications but doing a 
quick test on some machines at least showed it would solve our use case. 
What do the more expert users / maintainers think - is it even 
worthwhile to go that route?

Am 14.03.2012 17:04, schrieb ext Christian Ziech:
> LEt me describe our upcoming use case in a few words: We are planning 
> to use zookeeper in a cloud were typically nodes come and go 
> unpredictably. We could ensure that we always have a more or less 
> fixed quorum of zookeeper servers with a fixed set of host names. 
> However the IPs associated with the host names would change every time 
> a new server comes up. I browsed the code a little and it seems right 
> now that the only problem is that the zookeeper server is remembering 
> the resolved InetSocketAddress in its QuorumPeer hash map.
>
> I saw that possibly ZOOKEEPER-107 would also solve that problem but 
> possibly in a more generic way than actually needed (perhaps here I 
> underestimate the impact of joining as a server with an empty data 
> directory to replace a server that previously had one).
>
> Given that - from looking at ZOOKEEPER-107 - it seems that it will 
> still take some time for the proposed fix to make it into a release, 
> would it make sense to invest time into a smaller work fix just for 
> this "replacing a dropped server without rolling restarts" use case? 
> Would there be a chance that a fix for this makes it into the 3.4.x 
> branch?
>
> Are there perhaps other ways to get this use case supported without 
> the need for doing rolling restarts whenever we need to replace one of 
> the zookeeper servers?
>


-- 
*NOKIA*
*Christian Ziech*
Senior Software Developer
Context Based Services
Services & Software
Mobile: +4915155155740
Fax: +493044676555
eMail: christian.ziech@nokia.com
Nokia gate5 GmbH
Invalidenstr. 117
10115 Berlin, Germany
www.maps.nokia.com <http://www.maps.nokia.com>
www.smart2go.com <http://www.smart2go.com>

Nokia gate5 GmbH, Sitz der Gesellschaft: Berlin, Amtsgericht 
Charlottenburg: HRB 106443 B, Steuernr.: 37/222/20817, ID/VAT-Nr.: DE 
812 845 193, Gesch�ftsf�hrer: Dr. Michael Halbherr, Karim T�htivuori

--------------070204030607000506010201--