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-8 infrautils <p>In order to better understand root causes of issues such as e.g. <a href="https://jira.opendaylight.org/browse/GENIUS-58" title="DataStoreJobCoordinator ModifiedNodeDoesNotExistException: Node /(urn:ietf:params:xml:ns:yang:ietf-interfaces?revision=2014-05-08)interfaces-state/interface does not exist. Cannot apply modification to its children." class="issue-link" data-issue-key="GENIUS-58"><del>GENIUS-58</del></a> in the future, it would be useful if the JobCoordinator (ex-DataStoreJobCoordinator; about to be moved from genius to infrautils in <a href="https://git.opendaylight.org/gerrit/#/c/51431/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/51431/</a>) for job failures should indicate stack trace of original caller who submitted job.</p> <p>NB: <a href="https://bugs.opendaylight.org/show_bug.cgi?id=7917#c3" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7917#c3</a></p> <p>"Adding appropriate info in the caller's mainWorker toString would help to identify the originator. However I think capturing the caller's stack trace would be too expensive in production although it could be done in a debug mode."</p> <p>I'm wondering how other Java frameworks deal with not loosing the stack of the original caller when working with async lambdas in Java .. there must be some.. "prior art" in this domain? Perhaps worth trying to learn a bit more about this through online research, before jumping into an implementation.</p> <p>Operating System: All<br/> Platform: All</p> INFRAUTILS-8

JobCoordinator (ex-DataStoreJobCoordinator) job failures should indicate stack trace of original caller who submitted job

Improvement Resolved Won't Do Unassigned Michael Vorburger Thu, 9 Mar 2017 14:04:04 +0000 Fri, 24 Sep 2021 14:35:55 +0000 Fri, 24 Sep 2021 14:35:55 +0000 (unspecified) General 0 2 <p><a href="https://bugs.opendaylight.org/show_bug.cgi?id=7917#c5" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7917#c5</a> :</p> <p>&gt; The only way to capture caller identity is to capture it via a Throwable.<br/> &gt; That is going to hurt performance a <b>lot</b>.</p> <p>&gt; Clean way of achieving this is to route the failure back to the requestor &#8211; <br/> &gt; which can then identify itself and provide any useful context.</p> <p>&gt; I mean, at the end of the day, the requestor needs to know about the failure, right?</p> <p>Right... so the REAL problem here is that all the enqueueJob methods in the JobCoordinator (ex-DataStoreJobCoordinator) really instead of void should be returning a ListenableFuture that you can attach some sort of LoggingFutureCallback to (via Futures.addCallback), right?</p> <p>But if with this, you still wouldn't get a nice stack trace in a log, would you? You would just get an ERROR log from the Lambda you passed as the onFailure to the FutureCallback... so this, alone, still wouldn't actually solve the real problem I was after above, I believe. Is there any solution to that?</p> <p>But returning Future from JobCoordinator enqueueJob would actually be very interesting for testability as well (it's something I've been battling with for the component tests).</p> <p>Once <a href="https://git.opendaylight.org/gerrit/#/c/51431/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/51431/</a> is in (I don't want to hold it back further), we probably should be changing &amp; adding that then...</p> <p>New <a href="https://jira.opendaylight.org/browse/INFRAUTILS-16" title="JobCoordinator enqueueJob must return a ListenableFuture instead of void" class="issue-link" data-issue-key="INFRAUTILS-16"><del>INFRAUTILS-16</del></a> opened for the return Future part; this issue for stack trace.</p> <p>On further thought, I think (optionally, due to perf impact) capturing is a low priority, because e.g. in <a href="https://jira.opendaylight.org/browse/GENIUS-58" title="DataStoreJobCoordinator ModifiedNodeDoesNotExistException: Node /(urn:ietf:params:xml:ns:yang:ietf-interfaces?revision=2014-05-08)interfaces-state/interface does not exist. Cannot apply modification to its children." class="issue-link" data-issue-key="GENIUS-58"><del>GENIUS-58</del></a> one <b>DOES</b> actually get a clue of the origin - via the JobEntry mainWorker (it was InterfaceStateRemoveWorker, in that case).</p> <p>One thing we <b>ARE</b> missing badly is context in case of thread death due to "Thread terminated due to uncaught exception" - such as in <a href="https://jira.opendaylight.org/browse/NETVIRT-937" title="DataStoreJobCoordinator java.lang.NullPointerException: at index 0" class="issue-link" data-issue-key="NETVIRT-937"><del>NETVIRT-937</del></a>... and I've added that in <a href="https://git.opendaylight.org/gerrit/#/c/63965/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/63965/</a>.</p> <p><a href="https://jira.opendaylight.org/browse/INFRAUTILS-75" title="Remove jobcoordinator" class="issue-link" data-issue-key="INFRAUTILS-75"><del>INFRAUTILS-75</del></a> removed JobCoordinator, hence this is a non-issue.</p> Blocks INFRAUTILS-16 Development External issue ID 7944 External issue URL Issue Type Priority Rank 0|i01mhb: