> On 24 Feb 2015, at 12:08 am, Christine Caulfield <ccaulfie@xxxxxxxxxx> wrote: > > On 16/02/15 14:10, Christine Caulfield wrote: >> On 13/02/15 12:27, Jan Friesse wrote: >>> Chrissie, >>> >>> Christine Caulfield napsal(a): >>>> It occurs to me that, as this has the potential to break Virtual >>>> Synchrony, there should be an option to either disable message >>> >>> it took me a while until I've found what exactly you mean by break EVS. >>> This is something we (or at least I) totally forgot but it looks like >>> HUGE problem and I don't even think that pcmk is able to handle this >>> situation (I believe you are talking about situation when one node is >>> sending long message, and other node will leave and then join again into >>> membership during long message is sent, so it will not receive that >>> message). >>> >>>> fragmentation or to some indication of the maximum message size that >>>> will not be fragmented. >>>> >>>> Thoughts? >>> >>> I'm thinking about following solutions: >>> - implement deferral of delivery of membership change to client >>> - some kind of recovery... Both of them is like reimplementing totem >>> inside libcpg. >>> - Another solution may be to add extra callback parameter and deliver >>> also list of nodes who received message. >>> >>> Generally, I'm really not very happy with breaking EVS. Yes, loooong >>> messages use case is weird and not so common outside pcmk and yes, >>> satellite nodes will break EVS anyway, but for needle we should stay >>> very conservative. >>> >> >> Agreed, I didn't realise how bad it could be until late into the >> development here. The 'sledgehammer' solution would be to flag when a >> confchg has happened during the sending of a long message and if that >> happens, invalidate the whole send. It would then means retransmitting >> the whole message again from the start. >> > > > ... and here it is! > > I stopped short of checking the ring state when the message is finally > delivered, it just checks it at each transmission stage. Which is what > happens with normal sends, of course. Rather a small patch in the end, always a good sign :) One thing that wasn't completely clear... do the applications need to care about resending or will is the client library taking care of that? It seems to be the latter right? _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
