https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-1223 controller <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1223

Clustering : Chunk an append entry to ensure that we not exceed akka-remoting size limit

Bug Resolved Done Tom Pantelis Moiz Raja Tue, 24 Mar 2015 15:47:27 +0000 Mon, 3 Jul 2017 21:43:03 +0000 Mon, 3 Jul 2017 21:43:03 +0000 Post-Helium clustering 0 3 <p>A large transaction with a lot of operations can result in a really large append entry which may need to be chunked the same as snapshot chunking.</p> <p>If a single AppendEntries exceeds the max size, maybe we should just send a snapshot.</p> <p>This is related to maximum-frame-size. This affects not only AppendEntries, but also other messages. Rather than dealing with this in the business logic, I think we should be plugging into the transport and implement some sort of fragmentation/defragmentation component &#8211; if that is possible.</p> <p>We can solve this by switching to Artery (and perhaps allocating a dedicated channel to carry these messages).</p> <p>Patch to switch to Artery: <a href="https://git.opendaylight.org/gerrit/49466" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/49466</a></p> <p>One additional improvement we can do with Artery is to separate messages into separate subchannels, hence eliminating latency cross-talk between components.</p> <p>Specifically:</p> <ul class="alternate" type="square"> <li>RAFT messages should use one subchannel</li> <li>Frontend -&gt; Backend messages should use another subchannel</li> <li>Backend -&gt; Frontend messages should use yet another subchannel</li> </ul> <p>This should result in RAFT not being blocked by anything going on in the FE/BE interface and Shards being able to make forward progress irrespective of frontend request being made from their local node to shard leaders on other nodes.</p> <p>It does not appear Artery itself solves this - while the aeron layer will fragment messages into smaller chunks, akka still imposes an upper limit governed by artery.advanced.maximum-frame-size. We'll need to bump this up as we did with netty.tcp.maximum-frame-size. </p> <p>From what I've read, Artery defines 3 sub channels: 1 for system/heartbeat messages, 1 for ordinary messages and 1 for large messages. By default all user messages go into the "ordinary" sub channel and are thus isolated over the wire from system messages. You can specify particular actors to utilize the large message channel via the artery.large-message-destinations setting. We may want to use this for the FE actors (i.e. read replies can be large). I have not seen anything in the akka docs whereby you can define your own custom sub channels.</p> <p>Artery does allow for the configuration of inbound and outbound "lanes" such that ser/des can be performed in parallel for different destination actors, although the messages still share the same transport sub channel. However this feature is not supported or recommended for use yet (needs more hardening).</p> <p>I have committed a component to the gerrit，which does the job of fragmentation and defragmentation mentioned above， it has past the test of reading large data in one go of in three nodes cluster that would not broke the heartbreak of raft.<br/> Looking forward to a more in-depth discussion.</p> <p>Some links：<br/> <a href="https://bugs.opendaylight.org/show_bug.cgi?id=7841" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7841</a> ,in which attached the UML squences for its usage.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/54753/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/54753/</a></p> <p>Submitted <a href="https://git.opendaylight.org/gerrit/#/c/57301/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/57301/</a></p> Development External issue ID 2890 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02p8v: