geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McMahon <rmcma...@pivotal.io>
Subject Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)
Date Tue, 20 Aug 2019 16:02:11 GMT
+1 to Juan's comment.  I wonder if it would make sense just to have a
variation on the existing create() method.  Either have a createPaused()
method or add an overload for create() that takes a startPaused boolean.
That will really drive home that the AsyncEventQueue will be created in a
paused state.  I personally would prefer the overload with extra parameter,
but I think either approach would be fine.

Thanks,
Ryan

On Tue, Aug 20, 2019 at 8:56 AM Juan José Ramos <jramos@pivotal.io> wrote:

> Hello Anil,
>
> +1 for the proposed solution.
> I'd change the method name from *pauseEventDispatchToListener* to something
> more meaningful and understandable for our users, maybe *startPaused*?,
> *setManualStart* (as we currently have for the *GatewaySenderFactory*)?,
> *startWithEventDispatcherPaused*?.
> Best regards.
>
>
>
> On Sat, Aug 17, 2019 at 12:55 AM Anilkumar Gingade <agingade@pivotal.io>
> wrote:
>
> > 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.*
> > >> >
> > >>
> > >
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Software Engineer
> Email: jramos@pivotal.io
>

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