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-358 ovsdb <p>The RPC timeout in JsonRPCEndpoint/getClient method is 300 ms:<br/> private static final int REAPER_INTERVAL = 300;</p> <p>This timeout is not configurable, and it can be quite aggressive for heavy-weight operations on OVSDB. This leads to the following exception:<br/> java.util.concurrent.CancellationException: Task was cancelled.</p> <p>One of the solutions would be to retry if the task was cancelled. However, for operations on OVSDB that genuinely take &gt; 300 ms, this will not work &#8211; The task will be cancelled again.</p> <p>Operating System: All<br/> Platform: All</p> OVSDB-358

[SR3] RPC timeout in JsonRPCEndpoint is not configurable

Bug Resolved Done Unassigned Ashwin P Sat, 6 Aug 2016 18:41:41 +0000 Thu, 19 Oct 2017 21:27:05 +0000 Wed, 10 Aug 2016 20:14:14 +0000 unspecified Library 0 1 <p>Hi Ashwin,</p> <p>I pushed the patch to fix the issue. It increases the timeout to 1000 ms and also providers the config knob to change it.</p> <p>stable/beryllium : <a href="https://git.opendaylight.org/gerrit/#/c/43273/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/43273/</a></p> <p>Can you please test it in your environment and update the bug with your findings.?</p> <p>Thanks<br/> Anil</p> <p>Since this is a reaper timeout (and has no performance impact under normal operating conditions), I'd suggest setting it to a much larger default value (e.g. 60 sec). I tried this patch with a 60 sec timeout in the config file, and it seems to be working fine.</p> <p>I believe 60 second is too long to wait for a single device operation. Do you see any scenario where any single ovsdb rpc operation can take 60 seconds?</p> <p>Waiting longer for task has a memory overhead, because all the task are getting accumulated and their respective reaper task as well. So if you connect 1000 nodes, waiting for 60 seconds probably accumulate lot of short lived object and cleaning them up will trigger major GC and that can be issues in clustered environment. So until and unless there is any specific scenario where default value of 1000 second is not appropriate, in my opinion we should keep the timeout minimum. For specific scenario user can always tweak the provided config knob.</p> <p>Thanks for the detailed explanation. I agree with the reasoning.</p> <p>(In reply to Anil Vishnoi from comment #3)<br/> &gt; I believe 60 second is too long to wait for a single device operation. Do<br/> &gt; you see any scenario where any single ovsdb rpc operation can take 60<br/> &gt; seconds?<br/> &gt; <br/> &gt; Waiting longer for task has a memory overhead, because all the task are<br/> &gt; getting accumulated and their respective reaper task as well. So if you<br/> &gt; connect 1000 nodes, waiting for 60 seconds probably accumulate lot of short<br/> &gt; lived object and cleaning them up will trigger major GC and that can be<br/> &gt; issues in clustered environment. So until and unless there is any specific<br/> &gt; scenario where default value of 1000 second is not appropriate, in my<br/> &gt; opinion we should keep the timeout minimum. For specific scenario user can<br/> &gt; always tweak the provided config knob.</p> <p>Small Correction, it's 1000 millisecond and not 1000 seconds.</p> <p>master : <a href="https://git.opendaylight.org/gerrit/#/c/43276/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/43276/</a></p> Development External issue ID 6352 External issue URL Priority Rank 0|i0228n: