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:
>> 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.
>> On Fri, Feb 1, 2013 at 4:42 PM, Camille Fournier <[EMAIL PROTECTED]>
>>> Can anyone jog my memory about why we didn't implement multi requests
>>> 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
>>> are easily reproducible only via the C client, see:
>>> 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
>>> Java client it would be a good fix for us to put it in there as well,
>>> especially in light of this issue.