[OVSDB-454] OvsdbConnectionService background thread (from netty?) should be daemon (and have a proper thread name) Created: 19/Feb/18 Updated: 07/May/20 Resolved: 07/May/20 |
|
| Status: | Resolved |
| Project: | ovsdb |
| Component/s: | None |
| Affects Version/s: | Nitrogen-SR3, Fluorine-SR2 |
| Fix Version/s: | Nitrogen-SR4, Fluorine-SR1 |
| Type: | Bug | Priority: | High |
| Reporter: | Michael Vorburger | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
I suspect that this OFP thread could be (part of / contributing to) "Thread-39" #283 prio=5 os_prio=0 tid=0x00007fbd6c028780 nid=0x3d79 in Object.wait() [0x00007fbd45884000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:232) - locked <0x000000008a617300> (a io.netty.channel.AbstractChannel$CloseFuture) at io.netty.channel.DefaultChannelPromise.await(DefaultChannelPromise.java:129) at io.netty.channel.DefaultChannelPromise.await(DefaultChannelPromise.java:28) at io.netty.util.concurrent.DefaultPromise.sync(DefaultPromise.java:333) at io.netty.channel.DefaultChannelPromise.sync(DefaultChannelPromise.java:117) at io.netty.channel.DefaultChannelPromise.sync(DefaultChannelPromise.java:28) at org.opendaylight.ovsdb.lib.impl.OvsdbConnectionService.ovsdbManagerWithSsl(OvsdbConnectionService.java:362) at org.opendaylight.ovsdb.lib.impl.OvsdbConnectionService.ovsdbManager(OvsdbConnectionService.java:300) at org.opendaylight.ovsdb.lib.impl.OvsdbConnectionService.lambda$startOvsdbManager$1(OvsdbConnectionService.java:249) at org.opendaylight.ovsdb.lib.impl.OvsdbConnectionService$$Lambda$1133/1995495413.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) Should this not be a Thread.setDaemon(true) thread? Could it be made to have a better name than the generic "Thread-39" ? You could use org.opendaylight.infrautils.utils.concurrent.ThreadFactoryProvider, if you like. Can OvsdbConnectionService have clean shut-down logic which stops the thread? |
| Comments |
| Comment by Michael Vorburger [ 19/Feb/18 ] |
|
Changed Serverity to Minor, because |
| Comment by Anil Vishnoi [ 06/Mar/18 ] |
|
vorburger Looking at the stack trace it looks like this is spawned from OVSDB code. Just wanted to understand the relevance here with the OpenFlow plugin. Can you please provider some more context here? probably logs ? |
| Comment by Michael Vorburger [ 06/Mar/18 ] |
|
Avishnoi I've moved this from OFP to OVSDB - sorry for confusing projects. |
| Comment by Robert Varga [ 04/Dec/19 ] |
|
There are a number of issues – one of them is the thread pointed out in the description, but OVSDB both client and server connection code uses completely anonymous threads. Furthermore client connections are leaking EventLoopGroups, which needs to also be address. |
| Comment by Chetan Arakere Gowdru [ 25/Mar/20 ] |
|
rovarga Do we have any further action items in ovsdb to address this issue(as most of the related review need merged) |