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-362 netconf <p>When two (or more) standalone applications write to the same netconf device different data tree at the same time one transaction will fail. <br/> The problem that we encountered is: <br/> Two standalone applications (VBD and GBP) are writing data to the same node but different data tree at the same time. Since Netconf is not capable to handle concurrent transactions from more sources to the same device at once, one of the transaction will fail with an exception: <br/> 2017-03-03 15:17:05,041 | ERROR | CommitFutures-4 | NetconfProxyDOMTransaction | 311 - org.opendaylight.netconf.topology-singleton - 1.2.0.SNAPSHOT | RemoteDevice</p> {overcloud-controller-0.opnfv.org} <p>: Failed to open new transaction<br/> java.lang.IllegalStateException: Transaction is already opened for another user</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-362

Unable to open multiple transactions to a single netconf device at a time

Bug Highest Resolved Duplicate Jakub Morvay Michal Cmarada Tue, 7 Mar 2017 14:35:37 +0000 Fri, 15 Mar 2019 22:22:36 +0000 Mon, 1 Oct 2018 18:26:35 +0000 netconf 0 5 <p>Currently, netconf mountpoints provide DataBroker implementation that supports just one open write or read/write transaction at a time. Hence, when opening a second transaction, you can see this error.</p> <p>The reason behind this single open transaction restriction is that every transaction locks the device. Lock is released upon transaction completion. Since the device is locked for the whole transaction life time, we can be sure that no one else can change device configuration.</p> <p>Some possible solutions how to enable more than one open transaction:</p> <p>1) Do not enable them. Netconf mountpoints do not provide DataBroker service but our own service that has this restriction documented properly.</p> <p>2) Block on creating new transactions and wait until previous transaction completes.</p> <p>3) Cache modifications done by multiple transactions, validate them on netconf southbound and validate them also against possible changes made concurrently on device independently from provided DataBroker. This is something we should consult with DataBroker API and most importantly with netconf RFC.</p> <p>To clarify the problem scope and trade-offs. A mount point is backed by a single NETCONF session and all transactions execute on it.</p> <p>Since netconf does not allow for multiple candidate stores for a particular session, we do not get any help from the RFC6241/device. Given that the candidate store may be shared across sessions, and there is no standardized way of discovering this, establishing multiple concurrent sessions may not provide a scalable solution (due to the need to lock) and may hit device connection limits.</p> <p>Hence we have a three-dimensional solution space to search, with no single solution being the best fit for all devices because:</p> <ul class="alternate" type="square"> <li>having more than one session if there are no active applications is a waste both controller and device resources</li> <li>multiple sessions in case of shared candidate store is wasteful</li> <li>transactions have a logical order which must be preserved (i.e. DOMTransactionChain concrept)</li> <li>establishing a session is slow and may fail</li> </ul> <p>Do VBD and GBP use TransactionChains?</p> <p>As a quick fix for this problem we can use my second solution proposal, that is:</p> <p>2) Block on creating new transactions and wait until previous transaction completes.</p> <p>We can make this more general, by allowing to specify a timeout for blocking on creating a new transaction. After timeout, opening a new transaction will fail with a specific exception, rather than just general TimeoutException or IllegalStateExpcetion. This timeout can be specified in netconf node configuration. Also, we should document this DataBroker implementation properly, what are the restrictions and limitations to it.</p> <p>Since this is a quick fix and it does not really allow for multiple transactions open at a time, I also opened a milestone <a href="https://jira.opendaylight.org/browse/ODLPARENT-77" title="[Karaf 4] SFT ChannelException: Failed to bind to: /127.0.0.1:2550" class="issue-link" data-issue-key="ODLPARENT-77"><del>ODLPARENT-77</del></a> where we can continue to track this multiple transactions open issue (and also other related issues).</p> <p>Sorry the milestone bug is <a href="https://jira.opendaylight.org/browse/NETCONF-370" title="Milestone: Implement DataBroker API for netconf mountpoints properly" class="issue-link" data-issue-key="NETCONF-370">NETCONF-370</a> not <a href="https://jira.opendaylight.org/browse/ODLPARENT-77" title="[Karaf 4] SFT ChannelException: Failed to bind to: /127.0.0.1:2550" class="issue-link" data-issue-key="ODLPARENT-77"><del>ODLPARENT-77</del></a></p> <p>Moving correctly to next service release, Carbon Sr1, the closest release, for bugfix.</p> <p>We should track this under <a href="https://jira.opendaylight.org/browse/NETCONF-370" title="Milestone: Implement DataBroker API for netconf mountpoints properly" class="issue-link" data-issue-key="NETCONF-370">NETCONF-370</a> (which is about mountpoint concurrent transactions in general) , closing this as a duplicate of that milestone.</p> Duplicate NETCONF-370 Development External issue ID 7918 External issue URL Issue Type ODL SR Target Milestone Rank 0|i01y2n: