<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 19:56:03 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>[CONTROLLER-1637] Intermittent failure in DistributedDataStoreIntegrationTest.testChangeListenerRegistration</title>
                <link>https://jira.opendaylight.org/browse/CONTROLLER-1637</link>
                <project id="10113" key="CONTROLLER">controller</project>
                    <description>&lt;p&gt;This test failed on jenkins:&lt;/p&gt;

&lt;p&gt;00:50:06 Tests run: 50, Failures: 1, Errors: 0, Skipped: 2, Time elapsed: 10.977 sec &amp;lt;&amp;lt;&amp;lt; FAILURE! - in org.opendaylight.controller.cluster.datastore.DistributedDataStoreIntegrationTest&lt;br/&gt;
00:50:06 testChangeListenerRegistration&lt;span class=&quot;error&quot;&gt;&amp;#91;class org.opendaylight.controller.cluster.databroker.ClientBackedDataStore&amp;#93;&lt;/span&gt;(org.opendaylight.controller.cluster.datastore.DistributedDataStoreIntegrationTest)  Time elapsed: 0.108 sec  &amp;lt;&amp;lt;&amp;lt; FAILURE!&lt;br/&gt;
00:50:06 java.lang.AssertionError: Change 1 does not contain /(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test. Actual: {}&lt;br/&gt;
00:50:06 	at org.junit.Assert.fail(Assert.java:88)&lt;br/&gt;
00:50:06 	at org.junit.Assert.assertTrue(Assert.java:41)&lt;br/&gt;
00:50:06 	at org.opendaylight.controller.cluster.datastore.utils.MockDataChangeListener.waitForChangeEvents(MockDataChangeListener.java:66)&lt;br/&gt;
00:50:06 	at org.opendaylight.controller.cluster.datastore.DistributedDataStoreIntegrationTest$21.&amp;lt;init&amp;gt;(DistributedDataStoreIntegrationTest.java:1178)&lt;br/&gt;
00:50:06 	at org.opendaylight.controller.cluster.datastore.DistributedDataStoreIntegrationTest.testChangeListenerRegistration(DistributedDataStoreIntegrationTest.java:1162)&lt;/p&gt;

&lt;p&gt;It failed in the second run for the tell-based protocol. The test writes the test model container, registers a DCL, then expects the initial created data notification for the test container. Afterwards it writes a couple entries to the contained &quot;outer-list&quot; and  verifies the notification updates.&lt;/p&gt;

&lt;p&gt;However, in the failed run, the initial notification received by the DCL was: &lt;/p&gt;

&lt;p&gt;12:50:04,36 AM &lt;span class=&quot;error&quot;&gt;&amp;#91;cluster-test-akka.actor.default-dispatcher-10&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;DEBUG&amp;#93;&lt;/span&gt; DataChangeListener - Sending change notification DOMImmutableDataChangeEvent [created=[], updated=&lt;span class=&quot;error&quot;&gt;&amp;#91;/(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test&amp;#93;&lt;/span&gt;, removed=[/(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test/outer-list/outer-list[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)id=1}
&lt;p&gt;], /(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test/outer-list/outer-list[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)id=2}
&lt;p&gt;]/id, /(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test/outer-list/outer-list[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)id=2}
&lt;p&gt;], /(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test/outer-list, /(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test/outer-list/outer-list[&lt;/p&gt;
{(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)id=1}
&lt;p&gt;]/id]] to listener org.opendaylight.controller.cluster.datastore.utils.MockDataChangeListener@d65e2b4&lt;/p&gt;

&lt;p&gt;Right after it received the expected notification:&lt;/p&gt;

&lt;p&gt;12:50:04,38 AM &lt;span class=&quot;error&quot;&gt;&amp;#91;cluster-test-akka.actor.default-dispatcher-10&amp;#93;&lt;/span&gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;DEBUG&amp;#93;&lt;/span&gt; DataChangeListener - Sending change notification DOMImmutableDataChangeEvent [created=&lt;span class=&quot;error&quot;&gt;&amp;#91;/(urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:store:test?revision=2014-03-13)test&amp;#93;&lt;/span&gt;, updated=[], removed=[]] to listener org.opendaylight.controller.cluster.datastore.utils.MockDataChangeListener@d65e2b4&lt;/p&gt;

&lt;p&gt;There&apos;s 2 problems here. One is that the DistributedDataStoreIntegrationTest class doesn&apos;t clear the InMemoryJournal for each test case. So when testChangeListenerRegistration runs for the tell-based protocol it observes the data left over from the ask-based test run. So when the test overwrites the test model container, a remove notification is generated for the stale outer list entries.&lt;/p&gt;

&lt;p&gt;The second problem is why the DCL even received the remove notification in the first place since the initial write completes before the DCL is registered. It should just receive the created data notification. This is indirectly due to the sharing of the ListenerTree between the ShardDataTree and the ShardDataTreeNotificationPublisherActor. On registration, the listener is first added to the shared ListenerTree and then it sends a PublishNotifications message to the publisher actor to generate the initial notification using a local ListenerTree. The problem here is that listener is leaked to the shared ListenerTree prior to the initial notification so if the publisher actor already has a queued PublishNotifications message for a prior update, the listener will inadvertently observe that notification first.&lt;/p&gt;

&lt;p&gt;To alleviate this, we need to have the ListenerTree owned by the ShardDataTreeNotificationPublisherActor and not share it with the ShardDataTree. On registration, the ShardDataTree should send a message to the ShardDataTreeNotificationPublisherActor to perform the on-boarding of the new listener, ie atomically generate and send the initial notification and then add the listener to the ListenerTree.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="26191">CONTROLLER-1637</key>
            <summary>Intermittent failure in DistributedDataStoreIntegrationTest.testChangeListenerRegistration</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="10000">Done</resolution>
                                        <assignee username="tpantelis">Tom Pantelis</assignee>
                                    <reporter username="tpantelis">Tom Pantelis</reporter>
                        <labels>
                    </labels>
                <created>Fri, 14 Apr 2017 07:46:09 +0000</created>
                <updated>Tue, 25 Jul 2023 08:24:30 +0000</updated>
                            <resolved>Fri, 21 Apr 2017 16:12:24 +0000</resolved>
                                                                    <component>clustering</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>1</watches>
                                                                                                                <comments>
                            <comment id="51997" author="rovarga" created="Fri, 14 Apr 2017 14:13:18 +0000"  >&lt;p&gt;Right, which effectively means the registration requests are proxied by ShardDataTree, which attaches the current state of the tree and forwards the request to the notifier actor.&lt;/p&gt;

&lt;p&gt;An alternative is to take a snapshot of the listener tree at the time when we are sending the request. This has the downside of blocking the shard actor&apos;s ability to process register/unregister requests until all previous notifications are dispatched.&lt;/p&gt;</comment>
                            <comment id="51998" author="tpantelis" created="Fri, 14 Apr 2017 15:37:33 +0000"  >&lt;p&gt;(In reply to Robert Varga from comment #1)&lt;br/&gt;
&amp;gt; Right, which effectively means the registration requests are proxied by&lt;br/&gt;
&amp;gt; ShardDataTree, which attaches the current state of the tree and forwards the&lt;br/&gt;
&amp;gt; request to the notifier actor.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; An alternative is to take a snapshot of the listener tree at the time when&lt;br/&gt;
&amp;gt; we are sending the request. This has the downside of blocking the shard&lt;br/&gt;
&amp;gt; actor&apos;s ability to process register/unregister requests until all previous&lt;br/&gt;
&amp;gt; notifications are dispatched.&lt;/p&gt;

&lt;p&gt;yeah. &lt;/p&gt;

&lt;p&gt;Having the ShardDataTreeNotificationPublisherActor own the ListenerTree and sending s registration message to it as I proposed is also problematic b/c the Shard&apos;s support class needs the actual ListenerRegistration immediately in order to create the registration actor that closes it. We could also move the registration actor creation to the ShardDataTreeNotificationPublisherActor but other logic would have to move as well. Essentially we&apos;d have to basically refactor the support class into the ShardDataTreeNotificationPublisherActor - that might get a bit tricky. &lt;/p&gt;

&lt;p&gt;Another option is to initially disable the new listener (or drop notifications) until the initial notification is sent.&lt;/p&gt;

&lt;p&gt;I&apos;ll look at it further.&lt;/p&gt;</comment>
                            <comment id="51999" author="tpantelis" created="Mon, 17 Apr 2017 18:11:51 +0000"  >&lt;p&gt;master - &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/55108/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/55108/&lt;/a&gt;&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </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>8231</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=8231]]></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_10204" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>ODL SR Target Milestone</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10314"><![CDATA[Carbon-RC1]]></customfieldvalue>

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

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