[jbosscache-dev] Re: JGroups and concurrent FLUSHes

[Manik Surtani]

I'm happy for JBC 3.1.0 to ship with JGroups 2.7.x.   And apart from  
NBST, it would happily run with JGroups 2.6.x as well.


On 27 Feb 2009, at 16:34, Brian Stansberry wrote:

> Sounds like an overly large change for a micro release on the highly  
> stable 2.6 branch. JGroups' 2.7 branch seems more appropriate.  NBST  
> in JBC is not stable tech, so I don't like the idea of destabilizing  
> a highly stable branch to cater to it.
>
> From a technical POV, what's discussed sounds fine. ;)
>
> Bela Ban wrote:
>> Copied Brian, who will probably not like this. I guess... :-)
>> Actually, we should move this discussion over to jbosscache-dev...  
>> (copied). Please reply to jbosscache-dev from now on
>> Vladimir Blagojevic wrote:
>>> As Bela and I talked this option simplifies FLUSH quite a bit but  
>>> puts the burden and the *freedom* of retry management on  
>>> application code. My only concern is compatibility if we are going  
>>> to stick this into 2.6.9. This changes flush semantics quite a bit  
>>> and perhaps we can talk about this as well.
>>>
>>> On 2/27/09 9:52 AM, Bela Ban wrote:
>>>> Manik and I discussed this over the phone. Some items we came up  
>>>> with:
>>>>
>>>>   * Concurrent partial flushes won't happen because if a state
>>>>     requester or provider isin the process of transferring state,
>>>>     it'll reject the new state transfer
>>>>   * Concurrent total and partial flushes *are* possible: a view  
>>>> change
>>>>     and a partial state, executed concurrently
>>>>         o We cannot disable flushing for view changes, because the
>>>>           user probably wanted this with placing FLUSH into the  
>>>> stack.
>>>>           OTOH, because JBC NBST requires FLUSH (because of the
>>>>           partial flushing), we need to be able to disable flushing
>>>>           for view changes. Hence the previous email.
>>>>         o If a view change flush is in progress, currently a  
>>>> partial
>>>>           flush would fail. Manik will change code to make the  
>>>> partial
>>>>           flushing back off and retry, up to a number of times, if
>>>>           this happens
>>>>         o If a view change happens, but a partial flush is  
>>>> already in
>>>>           progress, the view change will fail ! We'll change code  
>>>> such
>>>>           that the coordinator backs off and retries a number of
>>>>           times, before giving up.
>>>>         o Because total flushes and partial flushes are usually  
>>>> very
>>>>           short, the backing off and retrying mechanism should work
>>>>           most of the time
>>>>         o Would establishing total order between total and partial
>>>>           flushes help ? Vladimir and Bela to investigate
>>>>         o Vladimir: make sure that if A flushes A,B and C
>>>>           successfully, but fails for D and E, A only aborts the  
>>>> flush
>>>>           on A,B and C, but *not* on D or E ! A member cannot abort
>>>>           flushes started by someone else !
>>>>
>>>>
>>>
>
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberry at redhat.com
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20090227/e3529a8d/attachment.html