<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 19:56:16 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-1715] 6 GB heap is not entirely enough for BGP ingest test with 1 million prefixes when tell-based protocol is used</title>
                <link>https://jira.opendaylight.org/browse/CONTROLLER-1715</link>
                <project id="10113" key="CONTROLLER">controller</project>
                    <description>&lt;p&gt;This failure started happening consistently in a BGP test with single node, but using tell-based protocol, so this may be related to cluster testing.&lt;/p&gt;

&lt;p&gt;The BGP job runs several scenarios. For this bug I compare 4 of them, differing on which side initiates BGP connection and whether ask- or tell- based protocol is used.&lt;/p&gt;

&lt;p&gt;The bug manifests as inability of ODL to clear ipv4 topology &lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; after the connection has been closed. This does not happen if ODL is not initiating the connection, perhaps because that scenario is run first in the suite and memory pressure is lower. This does not happen with the exact same suite running against ODL with ask-based protocol (both times it is the first suite after initial start or hard reboot).&lt;/p&gt;

&lt;p&gt;The title was chosen to reflect the only difference I have recognized in karaf.log &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt;:&lt;br/&gt;
 2017-06-09 06:33:50,808 | INFO | lt-dispatcher-20 | EmptyLocalActorRef | 155 - com.typesafe.akka.slf4j - 2.4.18 | Message &lt;span class=&quot;error&quot;&gt;&amp;#91;org.opendaylight.controller.cluster.datastore.messages.DataTreeChanged&amp;#93;&lt;/span&gt; from Actor&lt;span class=&quot;error&quot;&gt;&amp;#91;akka://opendaylight-cluster-data/deadLetters&amp;#93;&lt;/span&gt; to Actor&lt;span class=&quot;error&quot;&gt;&amp;#91;akka://opendaylight-cluster-data/user/$M&amp;#93;&lt;/span&gt; was not delivered. &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; dead letters encountered. This logging can be turned off or adjusted with configuration settings &apos;akka.log-dead-letters&apos; and &apos;akka.log-dead-letters-during-shutdown&apos;.&lt;/p&gt;

&lt;p&gt;Though subsequent messages suggest there is still some progress being done somewhere (those messages are also present in the preceding passing scenario):&lt;br/&gt;
 2017-06-09 06:33:51,408 | WARN | lt-dispatcher-41 | FrontendClientMetadataBuilder | 180 - org.opendaylight.controller.sal-distributed-datastore - 1.5.1.Carbon | member-1-shard-topology-operational: Unknown history for aborted transaction member-1-datastore-operational-fe-0-txn-31-1, ignoring&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/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/306/log.html.gz#s1-s9-t17&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/306/log.html.gz#s1-s9-t17&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/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/306/odl1_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/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/306/odl1_karaf.log.gz&lt;/a&gt;&lt;/p&gt;

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

&lt;p&gt;&#160;&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/vex-yul-odl-jenkins-1/bgpcep-csit-1node-bgp-ingest-all-silicon/216/robot-plugin/log.html.gz#s1-s9-t3-k2-k1&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/bgpcep-csit-1node-bgp-ingest-all-silicon/216/robot-plugin/log.html.gz#s1-s9-t3-k2-k1&lt;/a&gt;&lt;/p&gt;

&lt;p&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/vex-yul-odl-jenkins-1/bgpcep-csit-1node-bgp-ingest-all-silicon/216/robot-plugin/log.html.gz#s1-s9-t5-k2-k1-k1-k1-k2&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/bgpcep-csit-1node-bgp-ingest-all-silicon/216/robot-plugin/log.html.gz#s1-s9-t5-k2-k1-k1-k1-k2&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://github.com/opendaylight/integration-test/blob/master/csit/suites/bgpcep/bgpingest/singlepeer_prefixcount.robot#L51&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/opendaylight/integration-test/blob/master/csit/suites/bgpcep/bgpingest/singlepeer_prefixcount.robot#L51&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="26269">CONTROLLER-1715</key>
            <summary>6 GB heap is not entirely enough for BGP ingest test with 1 million prefixes when tell-based protocol is used</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="oleksii.mozghovyi">Oleksii Mozghovyi</assignee>
                                    <reporter username="vrpolak">Vratko Polak</reporter>
                        <labels>
                            <label>pt</label>
                    </labels>
                <created>Fri, 9 Jun 2017 15:41:03 +0000</created>
                <updated>Tue, 25 Jul 2023 08:24:43 +0000</updated>
                            <resolved>Fri, 2 Jul 2021 12:53:05 +0000</resolved>
                                                    <fixVersion>4.0.0</fixVersion>
                                    <component>clustering</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>3</watches>
                                                                                                                <comments>
                            <comment id="52409" author="tpantelis" created="Fri, 9 Jun 2017 15:59:40 +0000"  >&lt;p&gt;That indicates the DTCN generator actor&apos;s mailbox reached the limit. If it only happens with tell-based perhaps it&apos;s not throttling enough compared to ask-based.&lt;/p&gt;

&lt;p&gt;You can try increasing the mailbox capacity in the akka.conf. Default settings are:&lt;/p&gt;

&lt;p&gt;  bounded-mailbox &lt;/p&gt;
{
    mailbox-capacity = 5000
    mailbox-push-timeout-time = 10ms
  }

&lt;p&gt;Perhaps we shouldn&apos;t use a bounded mailbox for DTCN generation especially since DTCL notification actor mailboxes are unbounded. As such, it seems using a bounded mailbox for the former doesn&apos;t really make sense.&lt;/p&gt;</comment>
                            <comment id="52410" author="vrpolak" created="Mon, 12 Jun 2017 13:58:40 +0000"  >&lt;p&gt;This still occurs in every run.&lt;/p&gt;

&lt;p&gt;One suspicious thing I have not mentioned is that read from ipv4-example-topology take significantly long time. For example 7 minutes &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt;, while the previous steps are able to reach stability in around two minutes.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/309/log.html.gz#s1-s9-t17-k2-k3-k7-k5-k1-k6-k1-k1-k1-k1-k1-k2-k1-k1-k1&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/309/log.html.gz#s1-s9-t17-k2-k3-k7-k5-k1-k6-k1-k1-k1-k1-k1-k2-k1-k1-k1&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="52411" author="vrpolak" created="Mon, 12 Jun 2017 14:07:14 +0000"  >&lt;p&gt;&amp;gt; significantly long time&lt;/p&gt;

&lt;p&gt;That is because Garbage Collection started being busy during that time, see &lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;.&lt;br/&gt;
But it is not clear who is eating the memory, Controller code or BGP code.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/309/gclogs-1/gc_1497252896.63.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/309/gclogs-1/gc_1497252896.63.log.gz&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="52412" author="vrpolak" created="Wed, 21 Jun 2017 11:29:05 +0000"  >&lt;p&gt;The test passed &lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; today, even though the garbage collection log &lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; still shows significant slowdown during its run.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/317/log.html.gz#s1-s9&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/317/log.html.gz#s1-s9&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/317/gclogs-1/gc_1498031207.07.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/317/gclogs-1/gc_1498031207.07.log.gz&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="52413" author="vrpolak" created="Thu, 6 Jul 2017 10:23:51 +0000"  >&lt;p&gt;Current runs around Carbon SR1 branch freeze show the suite does not fail &lt;span class=&quot;error&quot;&gt;&amp;#91;6&amp;#93;&lt;/span&gt;, but garbage collection &lt;span class=&quot;error&quot;&gt;&amp;#91;7&amp;#93;&lt;/span&gt; is still slowing the test down.&lt;/p&gt;

&lt;p&gt;[] &lt;a href=&quot;https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/334/robot/bgpcep-bgp-ingest.txt/Singlepeer%20Prefixcount_1/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/334/robot/bgpcep-bgp-ingest.txt/Singlepeer%20Prefixcount_1/&lt;/a&gt;&lt;br/&gt;
[] &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/334/gclogs-1/gc_1499325254.08.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/334/gclogs-1/gc_1499325254.08.log.gz&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="52414" author="vrpolak" created="Wed, 12 Jul 2017 07:36:42 +0000"  >&lt;p&gt;&amp;gt; Current runs around Carbon SR1 branch freeze show the suite does not fail&lt;/p&gt;

&lt;p&gt;But not 100% of the time, sometimes the test still fails &lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt;.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/339/log.html.gz#s1-s11-t17-k2-k3-k7-k5-k1-k6-k1-k1-k1-k1-k1-k2-k1-k1-k1&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/bgpcep-csit-1node-periodic-bgp-ingest-only-carbon/339/log.html.gz#s1-s11-t17-k2-k3-k7-k5-k1-k6-k1-k1-k1-k1-k1-k2-k1-k1-k1&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="52415" author="vrpolak" created="Tue, 12 Sep 2017 13:53:52 +0000"  >&lt;p&gt;Changed title to &quot;6 GB heap is not entirely enough for BGP ingest test with 1 million prefixes when tell-based protocol is used&quot;.&lt;/p&gt;</comment>
                            <comment id="69041" author="JIRAUSER12941" created="Thu, 8 Apr 2021 15:48:20 +0000"  >&lt;p&gt;I&apos;ve increased the number of prefixes to 1.000.000 for the following tests:&lt;br/&gt;
manypeers_prefixcount.robot&lt;br/&gt;
singlepeer_changecount.robot&lt;br/&gt;
singlepeer_prefixcount.robot &lt;br/&gt;
everything was fine, except for some unstable behavior of the play.py script on the tools VM. The problem might be related to environmental issues in the sandbox. &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>8649</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=8649]]></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|i02sa7:</customfieldvalue>

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