<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:15:29 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[NETCONF-621] Un-mounting a netconf device does not clean up MD-SAL DOM mountpoints</title>
                <link>https://jira.opendaylight.org/browse/NETCONF-621</link>
                <project id="10142" key="NETCONF">netconf</project>
                    <description>&lt;p&gt;&lt;span class=&quot;nobr&quot;&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/attachment/15219/15219_device_add.log&quot; title=&quot;device_add.log attached to NETCONF-621&quot;&gt;device_add.log&lt;sup&gt;&lt;img class=&quot;rendericon&quot; src=&quot;https://jira.opendaylight.org/images/icons/link_attachment_7.gif&quot; height=&quot;7&quot; width=&quot;7&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/sup&gt;&lt;/a&gt;&lt;/span&gt;Description:&lt;/p&gt;

&lt;p&gt;Un-mounting a netconf device does not clean up MD-SAL DOM mountpoints&lt;/p&gt;

&lt;p&gt;Topology:&lt;/p&gt;

&lt;p&gt;ODL-Neon---------(junos netconf device)&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;Steps to reproduce:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Mount Juniper-MX device to ODL with below payload.&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Mount URL:(operation PUT)&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://192.168.71.238:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/Man-2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://&amp;lt;IP&amp;gt;:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/Man-2&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;xml_playload&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;&amp;lt;node xmlns=&quot;urn:TBD:params:xml:ns:yang:network-topology&quot;&amp;gt;
 &amp;lt;node-id&amp;gt;Man-2&amp;lt;/node-id&amp;gt;
 &amp;lt;host xmlns=&quot;urn:opendaylight:netconf-node-topology&quot;&amp;gt;&amp;lt;device IP&amp;gt;&amp;lt;/host&amp;gt;
 &amp;lt;password xmlns=&quot;urn:opendaylight:netconf-node-topology&quot;&amp;gt;pwd&amp;lt;/password&amp;gt;
 &amp;lt;username xmlns=&quot;urn:opendaylight:netconf-node-topology&quot;&amp;gt;user&amp;lt;/username&amp;gt;
 &amp;lt;port xmlns=&quot;urn:opendaylight:netconf-node-topology&quot;&amp;gt;830&amp;lt;/port&amp;gt;
 &amp;lt;tcp-only xmlns=&quot;urn:opendaylight:netconf-node-topology&quot;&amp;gt;false&amp;lt;/tcp-only&amp;gt;
 &amp;lt;keepalive-delay xmlns=&quot;urn:opendaylight:netconf-node-topology&quot;&amp;gt;2&amp;lt;/keepalive-delay&amp;gt;
 &amp;lt;/node&amp;gt;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;


&lt;p&gt;2. observe that device status chages to connected , in couple of minutes. GET.&#160;&lt;a href=&quot;http://192.168.71.238:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/Man-2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://&amp;lt;IP&amp;gt;:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/Man-2&lt;/a&gt;&#160;&lt;/p&gt;

&lt;p&gt;3. Delete the device&#160;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;Operation DELETE:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://192.168.71.238:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/Man-2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://&amp;lt;IP&amp;gt;:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/Man-2&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;observe that ODL fails to clean up the mounted device properly.&lt;/p&gt;

&lt;p&gt;if the device is remounted again , it complains below.&lt;/p&gt;


&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;2019-05-21T14:15:08,756 | ERROR | remote-connector-processing-executor-14 | NetconfDevice | 293 - org.opendaylight.netconf.sal-netconf-connector - 1.9.0 | RemoteDevice\{Man-1}: Initialization in sal failed, disconnecting from device
 java.lang.IllegalStateException: Mount point already exists
 at com.google.common.base.Preconditions.checkState(Preconditions.java:507) ~[32:com.google.guava:25.1.0.jre]
 at org.opendaylight.mdsal.dom.broker.DOMMountPointServiceImpl.createMountPoint(DOMMountPointServiceImpl.java:48) ~[253:org.opendaylight.mdsal.dom-broker:3.0.6]
 at Proxy0f2bd717_d90b_4019_b6ab_2db555b4c1be.createMountPoint(Unknown Source) ~[?:?]
 at Proxy86cb11c3_dc67_4420_95b9_7eb4b50e7d58.createMountPoint(Unknown Source) ~[?:?]
 at org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceSalProvider$MountInstance.onTopologyDeviceConnected(NetconfDeviceSalProvider.java:130) ~[293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceSalProvider$MountInstance.onTopologyDeviceConnected(NetconfDeviceSalProvider.java:120) ~[293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at org.opendaylight.netconf.topology.singleton.impl.MasterSalFacade.registerMasterMountPoint(MasterSalFacade.java:148) ~[?:?]
 at org.opendaylight.netconf.topology.singleton.impl.MasterSalFacade.onDeviceConnected(MasterSalFacade.java:92) ~[?:?]
 at org.opendaylight.netconf.topology.singleton.impl.MasterSalFacade.onDeviceConnected(MasterSalFacade.java:79) ~[?:?]
 at org.opendaylight.netconf.topology.singleton.impl.MasterSalFacade.onDeviceConnected(MasterSalFacade.java:41) ~[?:?]
 at org.opendaylight.netconf.sal.connect.netconf.sal.KeepaliveSalFacade.onDeviceConnected(KeepaliveSalFacade.java:144) ~[293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at org.opendaylight.netconf.sal.connect.netconf.sal.KeepaliveSalFacade.onDeviceConnected(KeepaliveSalFacade.java:51) ~[293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.handleSalInitializationSuccess(NetconfDevice.java:243) [293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.access$500(NetconfDevice.java:79) [293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$SchemaSetup.setUpSchema(NetconfDevice.java:522) [293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$SchemaSetup.run(NetconfDevice.java:481) [293:org.opendaylight.netconf.sal-netconf-connector:1.9.0]
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
 at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125) [32:com.google.guava:25.1.0.jre]
 at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57) [32:com.google.guava:25.1.0.jre]
 at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78) [32:com.google.guava:25.1.0.jre]
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
 at java.lang.Thread.run(Thread.java:748) [?:?]
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;&#160;&lt;/p&gt;</description>
                <environment></environment>
        <key id="31699">NETCONF-621</key>
            <summary>Un-mounting a netconf device does not clean up MD-SAL DOM mountpoints</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.opendaylight.org/images/icons/priorities/major.svg">Medium</priority>
                        <status id="10003" iconUrl="https://jira.opendaylight.org/images/icons/status_generic.gif" description="">Confirmed</status>
                    <statusCategory id="2" key="new" colorName="blue-gray"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="Prathapkrishnamurthy">Prathap krishnamurthy</reporter>
                        <labels>
                            <label>pick-next</label>
                            <label>pt</label>
                    </labels>
                <created>Tue, 21 May 2019 14:40:48 +0000</created>
                <updated>Mon, 22 Jan 2024 21:55:37 +0000</updated>
                                            <version>Sodium SR3</version>
                    <version>Aluminium SR1</version>
                    <version>5.0.2</version>
                                    <fixVersion>7.0.0</fixVersion>
                    <fixVersion>5.0.10</fixVersion>
                    <fixVersion>6.0.7</fixVersion>
                                    <component>netconf</component>
                        <due></due>
                            <votes>1</votes>
                                    <watches>11</watches>
                                                                                                                <comments>
                            <comment id="67104" author="ericmoore" created="Wed, 7 Aug 2019 11:18:26 +0000"  >&lt;p&gt;Has there been an progress on this issue and are there any plans to back port it into Oxygen release?&lt;/p&gt;</comment>
                            <comment id="67594" author="sanjana_babu" created="Fri, 27 Dec 2019 07:15:35 +0000"  >&lt;p&gt;Prathap krishnamurthy , is this specific to juniper device?&#160; I have validated the scenario in Netopeer but I&apos;m not able to reproduce it. &lt;br/&gt;
 Please provide your inputs on this.&lt;/p&gt;</comment>
                            <comment id="68665" author="JIRAUSER13146" created="Mon, 12 Oct 2020 10:42:08 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=metaljackL&quot; class=&quot;user-hover&quot; rel=&quot;metaljackL&quot;&gt;metaljackL&lt;/a&gt; &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=demskeq8&quot; class=&quot;user-hover&quot; rel=&quot;demskeq8&quot;&gt;demskeq8&lt;/a&gt; ... FYI...&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga&quot; class=&quot;user-hover&quot; rel=&quot;rovarga&quot;&gt;rovarga&lt;/a&gt;, just wondering if you already know if this is fixed&lt;/p&gt;

&lt;p&gt;We have the exact same problem in Sodium SR4.&lt;/p&gt;

&lt;p&gt;2020-10-12T08:19:25,925 | ERROR | remote-connector-processing-executor-39 | AbstractFuture | 36 - com.google.guava - 27.1.0.jre | - | RuntimeException while executing runnable CallbackListener{org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$1@e3fcead} with executor MoreExecutors.directExecutor()&lt;br/&gt;
java.lang.IllegalStateException: Mount point already exists&lt;br/&gt;
 at com.google.common.base.Preconditions.checkState(Preconditions.java:508) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.mdsal.dom.broker.DOMMountPointServiceImpl.createMountPoint(DOMMountPointServiceImpl.java:46) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;305:org.opendaylight.mdsal.dom-broker:4.0.17&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at Proxy66a84a00_3d40_4cf5_b701_878f56fd23ae.createMountPoint(Unknown Source) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;?:?&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at Proxye8cffb62_cb69_49c6_880b_190848679992.createMountPoint(Unknown Source) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;?:?&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceSalProvider$MountInstance.onTopologyDeviceConnected(NetconfDeviceSalProvider.java:130) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceSalFacade.onDeviceConnected(NetconfDeviceSalFacade.java:84) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceSalFacade.onDeviceConnected(NetconfDeviceSalFacade.java:42) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.sal.KeepaliveSalFacade.onDeviceConnected(KeepaliveSalFacade.java:142) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.sal.KeepaliveSalFacade.onDeviceConnected(KeepaliveSalFacade.java:48) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.handleSalInitializationSuccess(NetconfDevice.java:259) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.access$000(NetconfDevice.java:87) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$1.onSuccess(NetconfDevice.java:182) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice$1.onSuccess(NetconfDevice.java:179) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;343:org.opendaylight.netconf.sal-netconf-connector:1.10.4&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1076) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30) ~&lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1138) &lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:958) &lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.AbstractFuture.setFuture(AbstractFuture.java:789) &lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.AbstractTransformFuture$AsyncTransformFuture.setResult(AbstractTransformFuture.java:224) &lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.AbstractTransformFuture$AsyncTransformFuture.setResult(AbstractTransformFuture.java:202) &lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.AbstractTransformFuture.run(AbstractTransformFuture.java:163) &lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at com.google.common.util.concurrent.MoreExecutors$5$1.run(MoreExecutors.java:982) &lt;span class=&quot;error&quot;&gt;&amp;#91;36:com.google.guava:27.1.0.jre&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) &lt;span class=&quot;error&quot;&gt;&amp;#91;?:?&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) &lt;span class=&quot;error&quot;&gt;&amp;#91;?:?&amp;#93;&lt;/span&gt;&lt;br/&gt;
 at java.lang.Thread.run(Unknown Source) &lt;span class=&quot;error&quot;&gt;&amp;#91;?:?&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="68666" author="rovarga" created="Mon, 12 Oct 2020 10:53:48 +0000"  >&lt;p&gt;I am sorry, Sodium release stream is no longer supported by the community.&lt;/p&gt;</comment>
                            <comment id="68667" author="metaljackl" created="Mon, 12 Oct 2020 13:19:37 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga&quot; class=&quot;user-hover&quot; rel=&quot;rovarga&quot;&gt;rovarga&lt;/a&gt;&#160;Sorry but I have to make it clear. Is it fixed in magnesium? aluminium? or you haven&apos;t seen this yet?&lt;/p&gt;</comment>
                            <comment id="68668" author="rovarga" created="Tue, 13 Oct 2020 10:56:35 +0000"  >&lt;p&gt;I don&apos;t know, it will have to be triaged by someone to ascertain that. What I was implying that even if it gets fixed, it will not get fixed on sodium stream.&lt;/p&gt;</comment>
                            <comment id="68700" author="JIRAUSER13150" created="Tue, 13 Oct 2020 14:23:24 +0000"  >&lt;p&gt;Thanks for the answer. Related ONAP Guilin (ODL Sodium) ticket: &lt;a href=&quot;https://jira.onap.org/browse/SDNC-1380&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://jira.onap.org/browse/SDNC-1380&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;We plan to do the same test with Aluminium.&lt;/p&gt;</comment>
                            <comment id="68933" author="JIRAUSER13146" created="Tue, 19 Jan 2021 11:16:11 +0000"  >&lt;p&gt;We tested this with Aluminium SR1 and observe the same error.&lt;/p&gt;</comment>
                            <comment id="69414" author="rovarga" created="Tue, 13 Jul 2021 20:14:57 +0000"  >&lt;p&gt;Preliminary target to 2.0.1 to keep this on at least some radar.&lt;/p&gt;</comment>
                            <comment id="69417" author="tcere" created="Thu, 15 Jul 2021 11:51:28 +0000"  >&lt;p&gt;I&apos;m unable to reproduce this locally, mount-&amp;gt; unmount -&amp;gt; mount seems to be working for me with testtool.&lt;/p&gt;

&lt;p&gt;We will need debug logs for entire netconf (org.opendaylight.netconf) to proceed further. They also need to contain the previous iteration of the same device(basically need to see the how unregister went with debug logs).&lt;/p&gt;

&lt;p&gt;Also it would be helpfull if you could check if the same happens with the nonclustered version of netconf-topology feature so we can pinpoint which module the issue lies in.&lt;/p&gt;

&lt;p&gt;If odl-netconf-topology looks fine, I would suggest using it in the meantime if running in a single node scenario, while we get this figured out.&lt;/p&gt;</comment>
                            <comment id="69418" author="rovarga" created="Fri, 16 Jul 2021 17:47:54 +0000"  >&lt;p&gt;I think the problem here is lifecycle confusion between sal-netconf-connector and netconf-client re. reconnecting client. &lt;a href=&quot;https://jira.opendaylight.org/browse/NETCONF-784&quot; title=&quot;ReconnectPromise keep reconnecting after device unregistered&quot; class=&quot;issue-link&quot; data-issue-key=&quot;NETCONF-784&quot;&gt;&lt;del&gt;NETCONF-784&lt;/del&gt;&lt;/a&gt; might solve something, but it certainly not a complete solution, as we are violating API contract set out for the returned Promise.&lt;/p&gt;</comment>
                            <comment id="71927" author="ivanhrasko" created="Wed, 18 Jan 2023 12:36:42 +0000"  >&lt;p&gt;The problems can be caused by the fact that ODL/netconf is slow to mount Junos device (device with a lot of models). It takes minutes to move from connecting to connected status. I expect that there can be problems with synchronization of mount point creation/deletion process which are not discoverable when testing with device that has only a few models.&lt;/p&gt;

&lt;p&gt;With my local cluster (3 nodes with 1GiB memory) I haven&apos;t even been able to connect such a device - my cluster nodes went down during connecting &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.opendaylight.org/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;.&lt;/p&gt;</comment>
                            <comment id="71976" author="petersuna" created="Thu, 9 Feb 2023 11:31:30 +0000"  >&lt;p&gt;I tested this issue with three cluster nodes, each equipped with 1 GB of RAM. The issue still persists in the current master NETCONF 5.0.2-SNAPSHOT. I have attached logs from all three clusters &lt;span class=&quot;error&quot;&gt;&amp;#91;Node1_karaf.log, Node2_karaf.log, Node3_karaf.log&amp;#93;&lt;/span&gt; and the exception is only present in the elected leader node 1.&lt;/p&gt;

&lt;p&gt;To reproduce the issue, I followed these steps:&lt;br/&gt;
&#160;1) Initialize the cluster with three nodes.&lt;br/&gt;
&#160;2) Start the NETCONF test tool with the following command:&#160;&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;
java -jar netconf-testtool-5.0.2-SNAPSHOT-executable.jar --device-count 1 --debug &lt;span class=&quot;code-keyword&quot;&gt;false&lt;/span&gt; --md-sal &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt; --schemas-dir PATH_TO_JUNIPER_MODELS --controller-ip 192.168.56.103 --ip 192.168.56.101 --generate-config-address 192.168.56.101 &lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;&#160;3) Verify the connected device.&lt;br/&gt;
&#160;4) Remove the connected device.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="71977" author="petersuna" created="Thu, 9 Feb 2023 15:07:56 +0000"  >&lt;p&gt;With steps described in this comment, I was able to encounter this error despite the netconf-testtool only having one model (ietf-inet-types@2013-07-15.yang), in the folder specified by the &lt;tt&gt;--schema-dir&lt;/tt&gt; path parameter at the 2) step.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="72032" author="rovarga" created="Wed, 1 Mar 2023 14:57:57 +0000"  >&lt;p&gt;The logs are a bit weird, as the exception is logged after the dust settled, so timing is ... interesting.&lt;br/&gt;
I will add better log message to the checkState(), but I think we also need to pepper some more debugs in NetconfNodeActor &amp;#8211; note that executeInSelf() gets scheduled through an explicit message to self, and hence we may be acting on outdated state by that time.&lt;br/&gt;
There is some form of a guard, but it is not exactly clear it is effective.&lt;/p&gt;</comment>
                            <comment id="72105" author="ivanhrasko" created="Wed, 29 Mar 2023 11:38:16 +0000"  >&lt;p&gt;The logs provided by &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=Prathapkrishnamurthy&quot; class=&quot;user-hover&quot; rel=&quot;Prathapkrishnamurthy&quot;&gt;Prathapkrishnamurthy&lt;/a&gt; shows that mount point is going to be created by &lt;b&gt;registerMasterMountPoint (MasterSalFacade)&lt;/b&gt;. On the other hand logs provided by &lt;a href=&quot;https://jira.opendaylight.org/secure/ViewProfile.jspa?name=PeterSuna&quot; class=&quot;user-hover&quot; rel=&quot;PeterSuna&quot;&gt;PeterSuna&lt;/a&gt; shows that here we call &lt;b&gt;registerSlaveMountPoint (SlaveSalFacade)&lt;/b&gt;.&lt;/p&gt;

&lt;p&gt;There can be only one mount point for one device. To create it is responsibility of leader not follower. Followers are creating theirs followers mount point as an action on message in &lt;b&gt;NetconfNodeActor&lt;/b&gt;.&lt;/p&gt;

&lt;p&gt;The fix can be to remove call to create mount point from &lt;b&gt;SlaveSalFacade&lt;/b&gt;.&lt;/p&gt;</comment>
                            <comment id="72109" author="JIRAUSER14403" created="Thu, 6 Apr 2023 09:01:12 +0000"  >&lt;p&gt;After some testing, results says that proposed solution will not work - this issue will require more deep investigation of &lt;b&gt;Master &#8596;&#65038; Slave&lt;/b&gt; interactions. Removing call to create mount point from &lt;b&gt;SlaveSalFacade&lt;/b&gt; is breaking cluster. Since problem occurred after disconnecting and connecting device for the second time it seems like something is wrong with &lt;b&gt;close()&lt;/b&gt; method of &lt;b&gt;SalFacade&lt;/b&gt; and problem might lie there.&lt;/p&gt;</comment>
                            <comment id="72124" author="JIRAUSER14403" created="Wed, 19 Apr 2023 19:13:41 +0000"  >&lt;p&gt;Debugging on cluster with adding additional logs via breakpoints showed that problem occurs when we sending &lt;b&gt;DELETE&lt;/b&gt; request. I uploaded log file with a little bit of formatting for understanding. There you can see that for some reason one of the slaves (&lt;b&gt;in my case&lt;/b&gt; - someone got this error log on leader node) started behave weird. On second time when I deleted device it for some reason called &lt;b&gt;MasterSalFacade.registerMasterMountPoint()&lt;/b&gt; on the &lt;b&gt;slave&lt;/b&gt; node. After this point it stopped sending any logs on DELETE request but device was still deleted from cluster. So the problem is there - in delete. Also attaching &lt;b&gt;same&lt;/b&gt; full logs from all nodes without formatting if someone needs it.&lt;/p&gt;</comment>
                            <comment id="72127" author="JIRAUSER14403" created="Thu, 20 Apr 2023 08:57:14 +0000"  >&lt;p&gt;Also adding screenshot with location of breakpoints that I used for logging. They mostly logging the time when we going through create/delete process and some vars like &lt;b&gt;YangInstanceIdentifier.&lt;/b&gt; It was used to see the order of these steps and timing between nodes.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10003">
                    <name>Relates</name>
                                            <outwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="34107">NETCONF-784</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="18712" name="Full logs cluster(3 nodes).7z" size="2371" author="ojo" created="Wed, 19 Apr 2023 19:13:55 +0000"/>
                            <attachment id="18711" name="Logs from debugging cluster.TXT" size="70653" author="ojo" created="Wed, 19 Apr 2023 18:57:38 +0000"/>
                            <attachment id="18510" name="Node1_karaf.log" size="371422" author="PeterSuna" created="Thu, 9 Feb 2023 11:33:04 +0000"/>
                            <attachment id="18511" name="Node2_karaf.log" size="347974" author="PeterSuna" created="Thu, 9 Feb 2023 11:33:20 +0000"/>
                            <attachment id="18512" name="Node3_karaf.log" size="351524" author="PeterSuna" created="Thu, 9 Feb 2023 11:33:42 +0000"/>
                            <attachment id="18713" name="cluster breakpoints for logs.png" size="48227" author="ojo" created="Thu, 20 Apr 2023 08:48:00 +0000"/>
                            <attachment id="15219" name="device_add.log" size="184983" author="Prathapkrishnamurthy" created="Tue, 21 May 2019 14:40:44 +0000"/>
                            <attachment id="15218" name="deviceunmount.log" size="267116" author="Prathapkrishnamurthy" created="Tue, 21 May 2019 14:40:44 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i03nwv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>