From user-return-2756-apmail-zookeeper-user-archive=zookeeper.apache.org@zookeeper.apache.org Mon Feb 14 08:36:20 2011 Return-Path: Delivered-To: apmail-zookeeper-user-archive@www.apache.org Received: (qmail 47428 invoked from network); 14 Feb 2011 08:36:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Feb 2011 08:36:20 -0000 Received: (qmail 27101 invoked by uid 500); 14 Feb 2011 08:36:19 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 26857 invoked by uid 500); 14 Feb 2011 08:36:16 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 26849 invoked by uid 99); 14 Feb 2011 08:36:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Feb 2011 08:36:15 +0000 X-ASF-Spam-Status: No, hits=3.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tivv00@gmail.com designates 209.85.216.177 as permitted sender) Received: from [209.85.216.177] (HELO mail-qy0-f177.google.com) (209.85.216.177) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Feb 2011 08:36:08 +0000 Received: by qyk27 with SMTP id 27so3768934qyk.15 for ; Mon, 14 Feb 2011 00:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WTnv3ZumlthhR3Z9yFGfuFTIkKW2PEKRE0kKRI3wA00=; b=eVEJHPZW6tTol0ERPxmfVMAIKqnkifRMz1piB4hn8+td75qvK5nFHY34W+vsbyewOQ sjvJiS8Zj6XsOQH8uOzjoMfNq6XJSmDliamFEogk56Tj2B+bht9uKN2vxc8xkJcXcpCt 58Ze5kgPoHEpsycoFfF/mgBHhMDXalshsxFJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CA0LfXbmuG70wPH7B3w7y2NsiimStcyc1oxqjGHDCPL/kK+sHTyPkpaCMKOH/s4SOW l186QS/ieRwLpmwzGj448ZTiBFpljXWVnAoT3xCH4FAEgTmaW4Ab8t4XvqW+9jiBKnhc YqtNkfIP6dNxZi1brkoCudnw1w62MWzHlHV6s= MIME-Version: 1.0 Received: by 10.229.83.198 with SMTP id g6mr2480665qcl.157.1297672547400; Mon, 14 Feb 2011 00:35:47 -0800 (PST) Received: by 10.229.211.203 with HTTP; Mon, 14 Feb 2011 00:35:47 -0800 (PST) In-Reply-To: <201102131710.21091.thomas@koch.ro> References: <201102131710.21091.thomas@koch.ro> Date: Mon, 14 Feb 2011 10:35:47 +0200 Message-ID: Subject: Re: ExecutorService over a zookeeper From: =?KOI8-U?B?96bUwcymyiD0yc3eydvJzg==?= To: thomas@koch.ro Cc: user@zookeeper.apache.org Content-Type: multipart/alternative; boundary=00163642748d38fcd7049c39ef2f X-Virus-Checked: Checked by ClamAV on apache.org --00163642748d38fcd7049c39ef2f Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: quoted-printable 13 =CC=C0=D4=CF=C7=CF 2011 =D2. 18:10 Thomas Koch =CE=C1= =D0=C9=D3=C1=D7: > =F7=A6=D4=C1=CC=A6=CA =F4=C9=CD=DE=C9=DB=C9=CE: > > Hello. > > > > I am trying to implement distributed executor service over a zookeeper > and > > encountered a problem I am not sure how to deal with. > > > Hi, > > I've the impression, you're doing it too complicate. Why not have a znode > jobs/ and put all your jobs as persistent znodes in there. > So your job_queue could look like: > > jobs/ > job1 > job2 > job3 > > A consumer can then lock a job by putting an ephemeral node in one of the > job > znodes: > > jobs/ > job1 > job2/ > .lock > job3 > > 1)This won't handle producer death as job can't be EPHEMERAL 2)The job list will have locked jobs every consumer must iterate over to find non-locked one. 3) I have job result So, instead of jobs/ job1 .lock .result I have jobs/ job1 (holding data) locks/ job1 queue/ job1 (holding unlocked jobs) result/ job1 This is actually 1 more node per job (queue) to handle (2) But, my main Q is about watches leakes. Even in your scheme, adding a watch on jobs/job1/.result may produce a leak if job is cancelled before it was processed (so that .result never filled). --=20 Best regards, Vitalii Tymchyshyn --00163642748d38fcd7049c39ef2f--