geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anilkumar Gingade <aging...@pivotal.io>
Subject Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)
Date Fri, 16 Aug 2019 23:54:53 GMT
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 <agingade@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 <dsmith@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 <agingade@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.*
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message