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/INFRAUTILS-23 infrautils <p>motivated by <a href="https://jira.opendaylight.org/browse/GENIUS-97" title="IdPoolListener OOM" class="issue-link" data-issue-key="GENIUS-97"><del>GENIUS-97</del></a> :</p> <p><a href="https://lists.opendaylight.org/pipermail/infrautils-dev/2017-November/000487.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/infrautils-dev/2017-November/000487.html</a></p> <p>Now that <a href="https://git.opendaylight.org/gerrit/#/c/63805/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/63805/</a> has gone in, let us after all use org.opendaylight.yangtools.util.concurrent.SpecialExecutors's newBoundedSingleThreadExecutor everywhere in genius / netvirt / SFC <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/help_16.png" height="16" width="16" align="absmiddle" alt="" border="0"/> instead of org.opendaylight.infrautils.utils.concurrent.Executors.newSingleThreadExecutor() introduced in <a href="https://git.opendaylight.org/gerrit/#/c/55251/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/55251/</a>.</p> <p>Then remove the newSingleThreadExecutor method, but keep the Executors class around and write JavaDoc to point surprised existing users to SpecialExecutors with an explanation copy/pasted from my infrautils-dev list thread why it's very important to use maximumQueueSize.</p> <p>Wondering what a sensible maximumQueueSize e.g. for async DTCL is... thoughts, anyone?</p> <p>PS: In an ideal world I would have wanted to move SpecialExecutors from yangtools to infrautils, but that won't be possible due to <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> refusal to let yangtools depend on infrautils. <a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=tpantelis" class="user-hover" rel="tpantelis">tpantelis</a> is happy to contribute SpecialExecutors to infrautils, but I think a fork is a shame to be avoid, if at all possible. Only if anywhere in infrautils we needed to use a newBoundedSingleThreadExecutor then this would be justified.</p> INFRAUTILS-23

Remove Executors.newSingleThreadExecutor() and replace users with SpecialExecutors.newBoundedSingleThreadExecutor()

Improvement High Confirmed Unresolved Unassigned Michael Vorburger Sat, 4 Nov 2017 01:29:45 +0000 Tue, 5 Oct 2021 20:47:30 +0000 utils, incl. inject 0 1 <p>If you're going to bound the queue then you have to handle rejected tasks. Most likely you don't want to drop tasks so use CallerRunsPolicy or ODL's WaitInQueueExecutionHandler - both put back pressure on the producer which might allow the system to recover gracefully. SpecialExecutors.newBoundedSingleThreadExecutor uses AbortPolicy. We can use SpecialExecutors.newBlockingBoundedCachedThreadPool (which uses CallerRunsPolicy) with 1 thread but I think it would be useful to add a newBlockingBoundedSingleThreadExecutor to Executors using either CountingRejectedExecutionHandler's newCallerRunsPolicy or newCallerWaitsPolicy. </p> Blocks GENIUS-97 Development Rank 0|i0379r: