I have updated the wiki based on Dan's comment. Changes with api: *On "AsyncEventQueueFactory" interface - *
*AsyncEventQueueFactory pauseEventDispatchToListener(); *// This causes AEQ to be created with paused state. On Fri, Aug 16, 2019 at 4:36 PM Anilkumar Gingade <aging...@pivotal.io> wrote: > Dan, > > If you look into the API; the AEQ will be created with the pause state. > The user (application) has to call resume to dispatch the events. > > It will be slightly different from GatewaySender behavior; where > GatewaySender will be created with run mode and then application has to > call pause on it. Here in this case AEQ will be created with paused state. > > -Anil. > > > On Fri, Aug 16, 2019 at 4:31 PM Dan Smith <dsm...@pivotal.io> wrote: > >> Hi Anil, >> >> While I like the idea of matching the API of GatewaySender, I'm not sure I >> see how this solves the problem. Is it required of the user to call pause >> on the AsyncEventQueue as soon as it is created? How would someone do that >> when creating AEQs with xml or cluster configuration? Maybe it would be >> better to not dispatch any events until we are done creating all regions? >> >> -Dan >> >> On Fri, Aug 16, 2019 at 2:31 PM Anilkumar Gingade <aging...@pivotal.io> >> wrote: >> >> > Proposal to support controlling capability with event dispatch to >> > AsyncEventQueue Listener. >> > >> > Wiki proposal page: >> > >> > >> https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Controlling+event+dispatch+to+AsyncEventListener >> > >> > Here is the details from the wiki page: >> > *Problem* >> > >> > *The Geode system requires AEQs to be configured before regions are >> > created. If an AEQ listener is operating on a secondary region, this >> could >> > cause listener to operate on a region which is not yet created or fully >> > initialized (for region with co-located regions) which could result in >> > missing events or dead-lock scenario between region (co-located region) >> > creation threads. This scenario is likely to happen during persistence >> > recovery; when AEQs are created in the start, the recovered AEQ events >> are >> > dispatched immediately, thus invoking the AEQ listeners.* >> > Anti-Goals >> > >> > None >> > *Solution* >> > >> > *The proposed solution is to provide a way to control dispatching AEQ >> > events to the AEQ Listeners, this could be done by adding "pause" and >> > "resume" capability to the AEQ, which will allow application to decide >> when >> > to dispatch events to the listeners. * >> > >> > >> > *The proposal is similar to existing "pause" and "resume" behavior on >> the >> > GatewaySender, on which the AEQ is based on (AEQ implementation is a >> > wrapper around GatewaySender). * >> > Changes and Additions to Public Interfaces >> > >> > *The proposed APIs are:* >> > >> > *On "AsyncEventQueueFactory" interface - * >> > >> > *AsyncEventQueue pauseEventDispatchToListener();* >> > >> > *On "AsyncEventQueue" interface -* >> > >> > *boolean resumeEventDispatchToListener(); **returns true or false if the >> > event dispatch is resumed successfully.* >> > >> > >> > *The constraints on the pauseEventDispatchToListener() will remain >> similar >> > to as in "GatewaySender.pause()" :* >> > >> > "It should be kept in mind that the events will still be getting queued >> > into the queue. The scope of this operation is the VM on which it is >> > invoked. In case the AEQ is parallel, the AEQ will be paused on >> individual >> > node where this API is called and the AEQ on other VM's can still >> dispatch >> > events. In case the AEQ is not parallel, and the running AEQ on which >> this >> > API is invoked is not primary then primary AEQ will still continue >> > dispatching events." >> > Performance Impact >> > >> > >> > *This will have similar performance and resource implication as with the >> > "GatewaySender.pause()" functionality. If the AEQ is not resumed or >> kept in >> > "pause" state for long, it may start consuming the configured memory and >> > overflow it into disk and may cause disk full scenario.* >> > Backwards Compatibility and Upgrade Path >> > >> > *Impact with rolling upgrade: * >> > >> > *As the api is applicable at individual VM level, there is no message >> > serialization changes involved. And only applicable to the events >> getting >> > dispatched to the listeners on that VM. And the AEQ which are replicated >> > (for redundancy) continues to work as before.* >> > >> > *Backward compatibility requirements: * >> > >> > *None. The AEQs are configured and managed at the server side. There is >> no >> > messaging involved between client/server.* >> > >> > *Disk formatting changes:* >> > >> > *None.* >> > >> > *Deprecation and Application Changes:* >> > >> > >> > *None. If needed, the existing application can be modified to control >> event >> > dispatch with AEQ listener.* >> > Prior Art >> > >> > *Without this, the AEQ listeners operating on other regions could >> > experience missing events or dead lock, if there are co-located >> regions.* >> > >> > *This approach is simple and can take advantage of the existing >> > functionality that is already supported in GatewaySender on which AEQ is >> > based on.* >> > >> >
