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/CONTROLLER-1879 controller <p>Submitting a great mount of ReadOnlyTransaction and WritingTransaction in turns causes OOM. </p> <p>We think it is the transaction id of ReadOnlyTransaction that splits the purged transaction range into lots of segments. </p> CONTROLLER-1879

OOM due to huge RangeSet of purgedTransactions in FrontendHistoryMetadataBuilder

Bug Highest Resolved Done Tomas Cere Huafei Zhang Mon, 24 Dec 2018 03:32:26 +0000 Tue, 9 Nov 2021 13:56:49 +0000 Thu, 23 May 2019 14:18:21 +0000 Fluorine SR1 Sodium Fluorine SR3 Neon SR2 clustering 0 3 <p>This is a controller issue, if confirmed. What are the steps to reproduce? Are you sure those ReadOnlyTransactions are being closed?</p> <p>Yes, ReaOnlyTransaction is explicitly closed.</p> <p> </p> <p>We have wrote a  endless loop structure to reproduce this issue.</p> <p>in each loop, we create a ReadOnlyTransaction and WriteTransaction to read and write the same network-topology node.</p> <p>in not a very long time , the 2G memory runs out.</p> <p> </p> <p>There are two issues here:</p> <ol> <li>in the remote case, aborting a read-only transaction causes a leak in closedTransactions, as the transaction will be tracked as closed but not purged</li> <li>in the local case, aborting a read-only transaction causes a hole in purgedTransactions to appear, as the abort will be purely-local and backend will never see the aborted transaction – which leads to the reported leak.</li> </ol> <p><a href="https://git.opendaylight.org/gerrit/81939" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/81939</a> deals with the first case.</p> Issue split CONTROLLER-1991 Development Rank 0|i03lpj: