> On 24 Feb 2015, at 8:10 pm, Christine Caulfield <ccaulfie@xxxxxxxxxx> wrote: > > On 23/02/15 23:48, Andrew Beekhof wrote: >> >>> 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? >> > > If the application gets CS_ERR_INTERRUPT* then it will need to resend > the message, it's a bit like EAGAIN in that sense. Fair enough. >From the looks of the pacemaker code, we don't care too much about specific return codes on sending. Any failure will just result in the message staying in our buffer and retried at some later point. Terminal errors (like broken connections) get picked up during reads. So it looks like pacemaker can make use of this already. > > Chrissie > > *If anyone has a better choice for a return code or thinks I should > invent a new one then please say so > > _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
