On 04/09/2013, at 5:50 PM, Ulrich Windl <[email protected]> wrote:
>>>> Andrew Beekhof <[email protected]> schrieb am 04.09.2013 um 08:27 in >>>> Nachricht > <[email protected]>: > >> On 04/09/2013, at 4:09 PM, Vladislav Bogdanov <[email protected]> wrote: >> > > [...] >>> Are there any possibilities/plans to implement "partial" messages? >> >> This is part of the reason we send only the changes that result from an >> update. > > I haven't checked recently, but when a lot of communication happened, > applying the diffs frequently failed , and a full copy was transferred. > I guess it's due to the fact that the protocol is not a two-way (request & > response) diff protocol, but just a one-way "diff broadcast" protocol. So if > a node didn't have the previous version it cannot process the latest diff and > needs a full copy instead. In this case it asks for and is sent a full copy to get it back on track. Frequently failing diffs is symptomatic of a bug[1], not a design flaw. [1] Eg. the one fixed by + Andrew Beekhof (11 months ago) 19589ee: High: Core: Prevent ordering changes when applying xml diffs > I don't know how well this scales for big clusters with massive updates. > > BTW: What are the reasons why a DC changes node while current DC-node is fine? Communication difficulties and cib replace operations (its a low cost way to regenerate the status section). > Occasionally this also happens, causing some extra communication... > >> Message fragmenting would have to happen at the corosync/libqb level. > > Regards, > Ulrich > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
