Re: [infinispan-dev] ISPN-232 - feedback needed

On 25 May 2010, at 18:16, Manik Surtani wrote: > > On 25 May 2010, at 16:06, Mircea Markus wrote: > >> >> On 25 May 2010, at 17:44, Manik Surtani wrote: >> >>> >>> On 25 May 2010, at 15:34, Mircea Markus wrote: >>> >>>> >>>> On 25 May 2010, at 17:22, Manik Surtani wrote: >>>> >>>>> >>>>> On 25 May 2010, at 15:09, Mircea Markus wrote: >>>>> >>>>>> >>>>>> On 25 May 2010, at 16:26, Manik Surtani wrote: >>>>>> >>>>>>> >>>>>>> On 25 May 2010, at 14:15, Mircea Markus wrote: >>>>>>> >>>>>>>>>> >>>>>>>>>> But, I'd be concerned about an Infinispan thread that's needed >>>>>>>>>> for doing a lot of critical work during a view change getting >>>>>>>>>> tied up >>>>>>>>>> making a ton of notifications. >>>>>>>>> >>>>>>>>> ^^ Yeah that's my concern. If during a rehash we need to stop >>>>>>>>> at every entry that is being moved and issue a notification, >>>>>>>>> that could be costly and really slow down the rehashing process. >>>>>>>> Can't we register an *async* notification listener on >>>>>>>> ViewChanged ? >>>>>>> >>>>>>> You'd still have a *lot* of notifications being queued up for >>>>>>> the notification executor since you will have 1 event *per >>>>>>> entry* that is moved. >>>>>> this would still happen in the same JVM as this information is >>>>>> needed. Just that we offer this as a service, so that users(AS >>>>>> being one of them) won't have to write this code. >>>>> >>>>> No, if the AS does it, it will be one notification (view change) + >>>>> a scan of known session ids (keys). If we do it, it will involve 1 >>>>> notification *per key* being migrated. >>>> I don't intend to register more than one ViewChange listener per >>>> service. Then AS (or other clients) can register as many keys with >>>> that service instance (and consequently with that single listener) >>>> and, in that listener to iterate over the keys etc. >>> >>> You may just register 1 listener, but the event gets dispatched by >>> the rehasher thread, which does: >> I was thinking about something totally different. >> 1. The NotificationService (NS) is started. Internally it registers a >> single listener: @ViewChange(async=true) >> 2. The user has registers to NS the set of keys for which he wants to >> be notified on topology changes. Whenever a key is registered, the NS >> calculates and holds current key address based on the CH. >> 3. View change happens, NS is notified with a thread from the async pool >> 4. It iterates over the set of registered keys and checks weather the >> prev address has changed. > > That's a whole alternate notification system to what we have. :) This is logic that Brian needs to write, and possibly others too - why not to offer it as a reusable service?