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/OVSDB-345 ovsdb <p>just do this in a loop:</p> <p>ovs-vsctl set-manager ${ODL_IP} 6640<br/> sleep 1;<br/> ovs-vsctl del-manager<br/> sleep 1;</p> <p>each connection is generating some threads but they are not cleaned<br/> up after the disconnection or after waiting for some period of time.</p> <p>feature installed is odl-ovsdb-southbound-impl-rest</p> <p>Operating System: All<br/> Platform: All</p> OVSDB-345

thread leak when connecting/disconnecting ovs nodes in a loop

Bug Resolved Done Dileep Ranganathan Jamo Luhrsen Fri, 27 May 2016 19:44:52 +0000 Wed, 15 Jun 2016 01:16:26 +0000 Wed, 15 Jun 2016 01:16:26 +0000 unspecified Library 0 3 <p>Adding more details from the mail discussion.</p> <p>This is what i did:</p> <p>1) Started the controller with ovsdb<br/> 2) Connected profiler<br/> 3) Once controller was up and stable took the first thread dump<br/> 4) Then i started the script that set-controller and delete-controller (ovs-vsctl set-manager tcp:192.168.122.1:6640;sleep 4;ovs-vsctl show;sleep 4;ovs-vsctl del-manager ; ovs-vsctl show) for 200 times<br/> 5) went to sleep <br/> 6) Next morning stopped the controller and thread monitor was constant, so it means controller was cooled down after these 200 connection/disconnection<br/> 7) Took another thread dump.</p> <p>You can look at these thread dump at following urls<br/> First Thread Dump (Step 3 above) : <a href="https://gist.githubusercontent.com/vishnoianil/c87bc620f0b35a87cd698bcadc244cc4/raw/4010fe1b758015cb2fd1f6f0d801eaafd171dcbd/first-thread-dump.txt" class="external-link" target="_blank" rel="nofollow noopener">https://gist.githubusercontent.com/vishnoianil/c87bc620f0b35a87cd698bcadc244cc4/raw/4010fe1b758015cb2fd1f6f0d801eaafd171dcbd/first-thread-dump.txt</a><br/> Last Thread Dump (Step 7 above) : <a href="https://gist.githubusercontent.com/vishnoianil/48d3be92630d93f4e5317474b01a681e/raw/75da31ef97a0e59431c1f7d02d62d8d7f3894363/last-thread-dump" class="external-link" target="_blank" rel="nofollow noopener">https://gist.githubusercontent.com/vishnoianil/48d3be92630d93f4e5317474b01a681e/raw/75da31ef97a0e59431c1f7d02d62d8d7f3894363/last-thread-dump</a><br/> Threads that are additional in Last thread dump compared to First Thread Dump : <a href="https://gist.githubusercontent.com/vishnoianil/56b9e5ce8b8b25203d09d1a4b7d67049/raw/3f108b62a0cef6c9d4681636fb8b664ada17e81b/newly-created-and-not-reaped-threads.txt" class="external-link" target="_blank" rel="nofollow noopener">https://gist.githubusercontent.com/vishnoianil/56b9e5ce8b8b25203d09d1a4b7d67049/raw/3f108b62a0cef6c9d4681636fb8b664ada17e81b/newly-created-and-not-reaped-threads.txt</a></p> <p>This is what i see:</p> <p>Total Threads in First Dump : 98<br/> Total Threads in Last Dump : 313<br/> Additional Thread spawned : ~215.</p> <p>I see three category of threads </p> <p>Thread "PassiveConnection-X" (9 threads) &#8211; These are expected.<br/> Thread "nioEventLoopGroup-5-X" ( 7 Threads) &#8211; These are expected as well for netty library.</p> <p>Thread "pool-XX-thread-Y" (197 threads) &#8211; These threads are problem. Each thread has the same stack. This stack related to is executor pool threads.<br/> Thread "pool-95-thread-1":<br/> at sun.misc.Unsafe.park(boolean, long)<br/> at java.util.concurrent.locks.LockSupport.park(java.lang.Object) (line: 175)<br/> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() (line: 2039)<br/> at java.util.concurrent.LinkedBlockingQueue.take() (line: 442)<br/> at java.util.concurrent.ThreadPoolExecutor.getTask() (line: 1067)<br/> at java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) (line: 1127)<br/> at java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 617)<br/> at java.lang.Thread.run() (line: 745)</p> <p>As of now I am not sure whether we are creating these threads or any of the core controller component is causing these. I am working on a patch, that actually name all executor pools in the ovsdb code, so that we can figure out whether these "pool-xxx-thread-y" are created by us or someone else. BUT indeed it's a thread leak somewhere.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/39917/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39917/</a></p> <p>be: <a href="https://git.opendaylight.org/gerrit/#/c/39986/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39986/</a><br/> b: <a href="https://git.opendaylight.org/gerrit/#/c/39917/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/39917/</a></p> <p>I'm going to bring a CSIT test case to check for this. Once I do, I'll<br/> mark this verified/fixed.</p> <p>I was about to ask this and you sensed it <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/biggrin.png" height="16" width="16" align="absmiddle" alt="" border="0"/>, thanks a lot jamo. I need to create the wiki page that actually should list all these bugs for which we need to write a integration tests. I will do that as soon as possible</p> <p>Anil, Jamo,</p> <p>add the test cases to the spreadsheet Venkat and Josh started: <a href="https://docs.google.com/spreadsheets/d/1n4yCFc9kogkkRrWwFjrVJyDPeO4lu79PZtwjuourDWg/edit#gid=0" class="external-link" target="_blank" rel="nofollow noopener">https://docs.google.com/spreadsheets/d/1n4yCFc9kogkkRrWwFjrVJyDPeO4lu79PZtwjuourDWg/edit#gid=0</a></p> Development External issue ID 5976 External issue URL Rank 0|i0225r: