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/NETCONF-94 netconf <p>In current implementation, Netconf session send subsequent rpc messages to device <br/> before receiving previous rpc reply, the session will queue the message for acknowledgement of reply message.</p> <p>Some device may discard subsequent messages before current message is processed over. thus will cause the message in queue never get the reply. and can't guarantee the message process pipeline in the device.</p> <p>my recommendation is this:</p> <p>Netconf session queue all the messages to be sent and send the first message in queue to device, after receiving the reply message ,dequeue the message and get the next message and send to device.</p> <p>Thanks.</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-94

Netconf send subsequent rpc messages to device before receiving previous rpc reply.

Bug Resolved Duplicate Nanfei Chen zhaohaiping Thu, 29 Oct 2015 01:21:32 +0000 Fri, 15 Mar 2019 22:22:16 +0000 Fri, 21 Oct 2016 08:16:38 +0000 netconf 0 5 <p>Changing type to Change Request - since it requires change of existing functionality.</p> <p>I would suggest not to change default behaviour (basicly has performance implications, which will not allow NETCONF to use full potential of correctly<br/> implemented NETCONF 6241 devices).</p> <p>I can envision some type of compatibility settings per device which will allow / disable this behaviour.</p> <p>I agree with you, options could be added to sal-netconf-connector on a module basis, so whether or not RPCs need to be send sequentially is session based. BTW, for compatibility with device it should be the default behavior to send the RPCs sequentially.</p> <p>Move to NETCONFI project.</p> <p>@zhaohaiping</p> <p>Can you take this bug if you are still working on it? I'm assuming you are since you put it as in progress.</p> <p>(In reply to Tomas Cere from comment #5)<br/> &gt; @zhaohaiping<br/> &gt; <br/> &gt; Can you take this bug if you are still working on it? I'm assuming you are<br/> &gt; since you put it as in progress.</p> <p>we take a temporary approach for our use which can't be compatible with current version.</p> <p> We don't have resources currently to work on this bug, so we change the bug state to confirmed.</p> <p>I have submitted a change for this bug.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/36775/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/36775/</a></p> <p>There is a more generic solution in the patch for <a href="https://jira.opendaylight.org/browse/NETCONF-173" title="implement concurrent message limit" class="issue-link" data-issue-key="NETCONF-173"><del>NETCONF-173</del></a></p> <p>With concurrent message limit (<a href="https://jira.opendaylight.org/browse/NETCONF-173" title="implement concurrent message limit" class="issue-link" data-issue-key="NETCONF-173"><del>NETCONF-173</del></a>), for your scenario you can set the limit to 1.</p> <p>This should force netconf session to behave as you demanded.</p> Blocks NETCONF-173 Duplicate NETCONF-173 CONTROLLER-1436 Development External issue ID 4548 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01wf3: