<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:15:07 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-470] Device access can fail shortly after cluster member is killed</title>
                <link>https://jira.opendaylight.org/browse/NETCONF-470</link>
                <project id="10142" key="NETCONF">netconf</project>
                    <description>&lt;p&gt;This manifests as a Robot failure, especially in &lt;del&gt;all&lt;/del&gt; tests, both on Carbon and Nitrogen.&lt;/p&gt;

&lt;p&gt;For example in this &lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; failure, post fail with:&lt;br/&gt;
java.lang.IllegalStateException: Can&apos;t create ProxyReadTransaction&lt;br/&gt;
	at org.opendaylight.netconf.topology.singleton.impl.ProxyDOMDataBroker.newReadWriteTransaction(ProxyDOMDataBroker.java:92)&lt;br/&gt;
...&lt;/p&gt;

&lt;p&gt;The real cause is:&lt;br/&gt;
Caused by:&amp;lt;/h3&amp;gt;&amp;lt;pre&amp;gt;java.util.concurrent.TimeoutException: Futures timed out after &lt;span class=&quot;error&quot;&gt;&amp;#91;5 seconds&amp;#93;&lt;/span&gt;&lt;br/&gt;
	at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:223)&lt;br/&gt;
	at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:227)&lt;br/&gt;
	at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)&lt;br/&gt;
	at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)&lt;br/&gt;
	at scala.concurrent.Await$.result(package.scala:190)&lt;br/&gt;
	at scala.concurrent.Await.result(package.scala)&lt;br/&gt;
	at org.opendaylight.netconf.topology.singleton.impl.ProxyDOMDataBroker.newReadWriteTransaction(ProxyDOMDataBroker.java:84)&lt;br/&gt;
	at org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.commitConfigurationDataPost(BrokerFacade.java:475)&lt;br/&gt;
...&lt;/p&gt;

&lt;p&gt;Looking at karaf.log &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;, new leaders were not elected at that time yet, so akka ask is expected to fail.&lt;/p&gt;

&lt;p&gt;Data broker now supports tell-based protocol, designed to work in such cases. As netconf does not use data broker, it should improve its own code to offer similar functionality, or at least document that accessing mounted devices can randomly fail during cluster HA events.&lt;/p&gt;

&lt;p&gt;Robot tests can be relaxed (by waiting for new leaders) if Netconf behavior is not going to be improved soon.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/399/log.html.gz#s1-s9-t7-k2-k1-k1-k4-k7-k1&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/399/log.html.gz#s1-s9-t7-k2-k1-k1-k4-k7-k1&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/399/odl2_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/netconf-csit-3node-clustering-all-carbon/399/odl2_karaf.log.gz&lt;/a&gt;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="21483">NETCONF-470</key>
            <summary>Device access can fail shortly after cluster member is killed</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10003">Cannot Reproduce</resolution>
                                        <assignee username="Kostiantyn">Kostiantyn Nosach</assignee>
                                    <reporter username="vrpolak">Vratko Polak</reporter>
                        <labels>
                    </labels>
                <created>Tue, 12 Sep 2017 12:23:08 +0000</created>
                <updated>Mon, 31 Jan 2022 17:44:09 +0000</updated>
                            <resolved>Mon, 31 Jan 2022 17:43:46 +0000</resolved>
                                                                    <component>netconf</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>1</watches>
                                                                                                                <comments>
                            <comment id="40223" author="tcere" created="Thu, 12 Oct 2017 13:11:11 +0000"  >&lt;p&gt;For now this is expected, to switch to a tell based protocol we would have to do a rewrite of the singleton again, however we should be able to leverage the tell-based stuff from controller if we switched mountpoints to Shards with a different behavior than the datastore counterparts - nonpersistent, no replication and without actually having a backend that stores data, only forwards it to the device.&lt;br/&gt;
This is pretty big task but should have the best payoff regarding clustered-netconf, and we would benefit from any future improvements to the tell-based protocol.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                            <attachment id="17110" name="[NETCONF-470] Steps to reproduce.rtf" size="1076" author="Kostiantyn" created="Mon, 20 Dec 2021 11:18:56 +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_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9148</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=9148]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10300"><![CDATA[Bug]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i01yqn:</customfieldvalue>

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