Re: Write retry issues with ZooKeeperClient

details on errors > > > > -- Enrico > > > > > > > > > > > > JV > > > > On Mon, Jun 26, 2017 at 11:19 PM Sijie Guo <guosi...@gmail.com guo > > si...@gmail.com>> wrote: > > > > > > > > Hi Sam, > > > >

Re: Write retry issues with ZooKeeperClient

On Tue, Jun 27, 2017 at 2:29 PM, Sijie Guo <guosi...@gmail.com> wrote: > On Tue, Jun 27, 2017 at 10:18 AM, Sam Just <sj...@salesforce.com> wrote: > > > JV: What do you mean by "May not be perfect for negative testing"? > > > > I don't think there's a

Re: [VOTE] Release 4.5.0, release candidate #0

+1 On Tue, Aug 8, 2017 at 10:22 AM, Matteo Merli wrote: > +1 > > Checked src and bin package > * Signatures ok > * Build > * Rat > * Run local bookie >(I had to set allowLoopback=true in conf/bk_server.conf for that. I > agree we can > document it and improve it

Write retry issues with ZooKeeperClient

BookKeeper has a wrapper class for the ZooKeeper client called ZooKeeperClient. Its purpose appears to be to transparently perform retries in the case that ZooKeeper returns ConnectionLoss on an operation due to a Disconnect event. The trouble is that it's possible that a write which received a

Re: Write retry issues with ZooKeeperClient

for metadata users where we depend on atomicity, and update each one to handle it appropriately. -Sam On Mon, Jun 26, 2017 at 4:34 PM, Sam Just <sj...@salesforce.com> wrote: > BookKeeper has a wrapper class for the ZooKeeper client called > ZooKeeperClient. > Its purpose appears to be t

Re: Write retry issues with ZooKeeperClient

handling for EXPIRED anyway? -Sam On Tue, Jun 27, 2017 at 4:08 PM, Sijie Guo <guosi...@gmail.com> wrote: > On Tue, Jun 27, 2017 at 2:36 PM, Sam Just <sj...@salesforce.com> wrote: > > > On Tue, Jun 27, 2017 at 2:29 PM, Sijie Guo <guosi...@gmail.com> wrote: > > &g

git/github commit hooks

Last thursday, we a had a short discussion about possibly changing the merge process to allow unsquashed commits and the use of the github merge button. One sticking point is that we'd like an automatic way to enforce some commit message metadata requirements and formatting. Git lets you define

Re: Usefulness of ensemble change during recovery

To flesh out JV's point a bit more, suppose we've got a 5/5/4 ledger which needs to be recovery opened. In such a scenario, suppose the last entry on each of the 5 bookies (no holes) are 10,10,10,10,19. Any entry in [10,19] is valid as the end of the ledger, but the safest answer for the end of

Re: Scanning the list of entries present on a bookie

IIRC, InterleavedLedgerStorage has for each ledger an index file mapping the entries to entry logger offsets, you could probably scan that directly (particularly if you included a lower bound -- probably the client's current idea of the LAC). -Sam On Thu, Apr 12, 2018 at 12:31 AM, Enrico Olivelli

Re: Clusterwide vs Client configuration for metadata format version

I'll take a look. On Tue, Dec 18, 2018 at 1:39 AM Ivan Kelly wrote: > JV, Sam, Charan, Andrey, could one of you chime in on this? It's > holding up 4.9 release. > > -Ivan > > On Thu, Dec 13, 2018 at 5:38 PM Ivan Kelly wrote: > > > > I'd be interested to see the opinion of the salesforce folks

Re: Clusterwide vs Client configuration for metadata format version

basis anyway, so in practice there may be little difference. -Sam On Tue, Dec 18, 2018 at 10:01 AM Sam Just wrote: > I'll take a look. > > On Tue, Dec 18, 2018 at 1:39 AM Ivan Kelly wrote: > >> JV, Sam, Charan, Andrey, could one of you chime in on this? It's >> holding up