Ah, that issue has a lot of good information. Thanks! Mike
On Fri, Dec 23, 2016 at 6:18 PM, William Markito Oliveira < [email protected]> wrote: > +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 >
