Yeah. It was an oversight. I did the java client and I ten not to think much about the asynchronous interfaces so I never designed anything along those lines.
Should be hard to add. Sent from my iPhone On Feb 1, 2013, at 2:04 PM, Marshall McMullen <[email protected]> wrote: > As far as I know it was not intentional. > > My best guess here is that is was due to different people working on > different parts of Multi. Ted did the original Java client work but didn't > have the time to do the C client work and my company really needed that > functionality so I volunteered to implement it. We never discussed the > async interface. I only implemented it because the C client necessitates > it. All of the synchronous interfaces are just wrappers around the > asynchronous ones. > > I think this was definitely an oversight. At a minimum it seems during the > many code reviews the Multi code got this should have been noticed.. > > > On Fri, Feb 1, 2013 at 2:45 PM, Camille Fournier <[email protected]> wrote: > >> Thawan's followup on that ticket pointed me to this open issue: >> https://issues.apache.org/jira/browse/ZOOKEEPER-1572 >> >> So that resolves it, which is great. >> My general call-out on divergent functionality away from the Java client >> stands for future reference but looks like we're good for this one. >> >> C >> >> >> On Fri, Feb 1, 2013 at 4:42 PM, Camille Fournier <[email protected]> >> wrote: >> >>> Can anyone jog my memory about why we didn't implement multi requests >> with >>> async callbacks for the Java client like we did in the C client? >>> I think it's not a great precedent to set because now we have bugs that >>> have been discovered in the implementation of multi on the server side >> that >>> are easily reproducible only via the C client, see: >>> https://issues.apache.org/jira/browse/ZOOKEEPER-1624 >>> >>> >>> Multi was a big project so I can understand why we let this go for the >>> first impl, but unless there's a technical reason not to support it in >> the >>> Java client it would be a good fix for us to put it in there as well, >>> especially in light of this issue. >>> >>> Thoughts? >>> >>> C >>> >>> >>> >>
