Re: [jsr107spec] No async API !? (#307)

[Alex Snaps]

Hey @gregrluck

So there is a plan for a new JSR to be submitted? I don't remember seeing this on the mailing yet, do you think you could update us (all?) on what the plans here are?

Obviously nailing the scope of that new JSR before submitting it would be... nice. Not only to us implementers, but to make sure we convey a clear message to the EC. But I guess you know all that way too well already. Anyways, just trying to get a sense of what is coming up. 

Thanks,

Alex

On Mon Feb 09 2015 at 4:57:33 PM Greg Luck <notifi...@github.com> wrote:

Actually we are planning to add this. I have a draft done which I should get out to the list in the next few weeks.

Regards

Greg Luck

web: http://gregluck.com <http://gregluck.com/>
skype: gregrluck
yahoo: gregrluck
mobile: +61 408 061 622

> On 10 Feb 2015, at 6:05 am, RuedigerMoeller <notifi...@github.com> wrote:
>
> There should be at least asynchronous variants of most important operations such as get(), getAndPut(), putIFAbsent() using a functional style callback or a Future alike return object. Considering most implementations will be implemented in a distributed fashion, an enforced synchronous API creates a dirct connection of throughput and network latency, so an application deployed in a 10GB lowlat network LAN will perform like 100 times worse e.g. when ran on a cloud platform.
>
> e.g. see https://github.com/RuedigerMoeller/advcalendar2014/blob/master/src/main/java/keyvalue/KVServer.java <https://github.com/RuedigerMoeller/advcalendar2014/blob/master/src/main/java/keyvalue/KVServer.java> for an example of an completely async kv-store example. Throughput of this example is completely independent of network latency.
>
> —
> Reply to this email directly or view it on GitHub <https://github.com/jsr107/jsr107spec/issues/307>.
>

—
Reply to this email directly or view it on GitHub.