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.* > > >
