+1 from me as well! GEODE-34 [1] was opened exactly for that - "Introduce Reactive Streams and/or Reactor" but no code contributions so far... At a bare minimum, one could provide an idiomatic reactive wrapper over the Region API implemented using RxJava/Reactor. Unfortunately that would not necessary make the internal APIs be non-blocking, although a few internal APIs offer some flexibility but as already stated, changing semantics quite a bit...
[1] https://issues.apache.org/jira/browse/GEODE-34 On Fri, Dec 23, 2016 at 2:24 PM, Mike Youngstrom <[email protected]> wrote: > A reactive API would work great! +1 from me for this. > > Although a few of my operations can be fire and forget. The majority of > them I'd need to know when they are completed so I can return a response to > the consumer. Here is some simple pseudo code for what I could do if I had > a CompletableFuture: > > public void acceptConnection(ConnectionHandle someConnHandle) { > String key = someConnHandle.read(); > CompletableFuture<Result> future = geodeCache.getAsync(key); > future.onComplete(result -> { > someConnHandle.write(result); > someConnHandle.close(); > } > future.onFailure(error -> { > someConnHandle.write("Failed with error"+error.getMessage()); > someConnHandle.close(); > } > return; > } > > The completion would execute on a Geode thread active when the task is > completed so the connection writes would need to be non blocking as well. > This is netty's bread and butter though. Everything non-blocking greatly > simplifies Thread pool sizing, reduces memory footprint, etc. > > I could get by with a sync/async adapter. Was just hoping to avoid > another thread pool to manage if possible. > > A Reactive API would take things to a whole notha level but my > interactions with the cache are simple enough that a CompletableFuture > pattern would work for me as well. > > On a side note how non-blocking are Geode internals? Are there thread > pools that need to be sized according to load instead of simply basing > thread sizing on number of server cores? > > Thanks, > Mike > > On Fri, Dec 23, 2016 at 10:40 AM, Anthony Baker <[email protected]> wrote: > >> Hi Mike, >> >> Currently basic data operations in Geode such as put/get are blocking >> operations. You could look into half-sync / half-async patterns to bridge >> the gap. >> >> I’d love to add support for reactive patterns in Geode :-) >> >> Anthony >> >> > On Dec 21, 2016, at 9:07 AM, Mike Youngstrom <[email protected]> wrote: >> > >> > Hi Geode Users, >> > >> > I'm looking at creating an application using netty as the server and >> Geode as a major part of the backend store. However, It is difficult for a >> netty application server to consume blocking backend solutions. Does Geode >> provide any kind of non blocking interface I can use to access basic >> functions like create, destory, and get? Or any way I can get something >> like a CompletableFuture for those types of actions? >> > >> > Looking through the Javadocs I couldn't find anything but I thought I'd >> ask just in case. >> > >> > The application I'm writing is not complicated so I'm more than willing >> to trade significant api complexity for an efficient non blocking solution >> when consuming Geode. >> > >> > Thanks, >> > Mike >> >> > -- ~/William
