[NETCONF-94] Netconf send subsequent rpc messages to device before receiving previous rpc reply. Created: 29/Oct/15  Updated: 15/Mar/19  Resolved: 21/Oct/16

Status: Resolved
Project: netconf
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: zhaohaiping Assignee: Nanfei Chen
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Blocks
is blocked by NETCONF-173 implement concurrent message limit Resolved
Duplicate
duplicates NETCONF-173 implement concurrent message limit Resolved
is duplicated by CONTROLLER-1436 Netconf send subsequent rpc messages ... Resolved
External issue ID: 4548

 Description   

In current implementation, Netconf session send subsequent rpc messages to device
before receiving previous rpc reply, the session will queue the message for acknowledgement of reply message.

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.

my recommendation is this:

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.

Thanks.



 Comments   
Comment by Tony Tkacik [ 29/Oct/15 ]

Changing type to Change Request - since it requires change of existing functionality.

I would suggest not to change default behaviour (basicly has performance implications, which will not allow NETCONF to use full potential of correctly
implemented NETCONF 6241 devices).

I can envision some type of compatibility settings per device which will allow / disable this behaviour.

Comment by zhaohaiping [ 29/Oct/15 ]

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.

Comment by Robert Varga [ 13/Nov/15 ]

Move to NETCONFI project.

Comment by Tomas Cere [ 24/Nov/15 ]

@zhaohaiping

Can you take this bug if you are still working on it? I'm assuming you are since you put it as in progress.

Comment by zhaohaiping [ 30/Nov/15 ]

(In reply to Tomas Cere from comment #5)
> @zhaohaiping
>
> Can you take this bug if you are still working on it? I'm assuming you are
> since you put it as in progress.

we take a temporary approach for our use which can't be compatible with current version.

We don't have resources currently to work on this bug, so we change the bug state to confirmed.

Comment by Nanfei Chen [ 26/Mar/16 ]

I have submitted a change for this bug.

https://git.opendaylight.org/gerrit/#/c/36775/

Comment by Tomas Cere [ 28/Apr/16 ]

There is a more generic solution in the patch for NETCONF-173

Comment by Jakub Morvay [ 21/Oct/16 ]

With concurrent message limit (NETCONF-173), for your scenario you can set the limit to 1.

This should force netconf session to behave as you demanded.

Generated at Wed Feb 07 20:14:09 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.