From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pete Zaitcev Subject: Re: [PATCH] chunkd: add support for multiple key/value tables Date: Tue, 10 Nov 2009 09:33:22 -0700 Message-ID: <20091110093322.313563c2@redhat.com> References: <20091110112409.GA31471@havoc.gtf.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091110112409.GA31471@havoc.gtf.org> Sender: hail-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Jeff Garzik Cc: hail-devel@vger.kernel.org On Tue, 10 Nov 2009 06:24:09 -0500, Jeff Garzik wrote: > LOGIN(user="jgarzik") > TABLE-OPEN(name="tabled") > GET... 2 more turnarounds per session? Brilliant! The theory behind this is sound: let's not saddle chunkd with caching authentication results, which is ineffective anyway, but provide a way for application to amortize the cost of authentication over a number of requests explicitly. But in practice it means tabled needs to keep inactive sessions open, which is a chunk of code for me to write (and debug!). I guess I'll do it in a few months... > @@ -29,9 +29,15 @@ static void test(bool encrypt) > stc1 = stc_new(TEST_HOST, port, TEST_USER, TEST_USER_KEY, encrypt); > OK(stc1); > > + rcb = stc_table_openz(stc1, TEST_TABLE, 0); > + OK(rcb); > + > stc2 = stc_new(TEST_HOST, port, TEST_USER2, TEST_USER2_KEY, encrypt); > OK(stc2); Having a default table? Naah, those lazy application programmers have it too easy already! Again, from the point of view of chunkd, this makes complete sense: why carry an extra (default) table in cases when application does in fact set its own tables, right? > + /* > + * we must supply CHF_TABLE_NEW on the first iteration of > + * this test, because we are the first test in the testsuite, > + * and must create the database to be used by all other tests. > + */ > + rcb = stc_table_openz(stc, TEST_TABLE, > + ssl ? 0 : CHF_TABLE_NEW); > + OK(rcb); You've got to be kidding me. How is tabled supposed to know that the request it's making is "first"?! I guess I have to supply CHF_TABLE_NEW to every call now, or else retry if InvalidTable is returned, I haven't decided what workaround to apply yet. -- Pete