On Thu, Aug 24, 2017 at 9:06 AM, Michael Vorburger <vorbur...@redhat.com> wrote:
> On Wed, Aug 23, 2017 at 8:54 PM, Robert Varga <n...@hq.sk> wrote: > >> On 23/08/17 20:21, Michael Vorburger wrote: >> > On Wed, Aug 23, 2017 at 2:11 PM, Robert Varga <n...@hq.sk >> > <mailto:n...@hq.sk>> wrote: >> > >> > On 23/08/17 13:48, Michael Vorburger wrote: >> > > >> > > Robert> Actually no. The backend side of things looks okay, as >> chains >> > > are being >> > > both closed and purged when requested from the frontend. I suspect >> > > somebody is forgetting to close their transaction chains... >> > > >> > > Michael> Is a "transaction chain" the same as a transaction - the >> > > objects returned from DataBroker's newReadWriteTransaction / >> > > newReadWriteTransaction / newWriteOnlyTransaction? I did stumble >> upont >> > > something - could https://git.opendaylight.org/gerrit/#/c/62196/ >> > <https://git.opendaylight.org/gerrit/#/c/62196/> fix >> > > this problem? Or is that unlikely to fix this OOM, but still a >> Good >> > > Idea? Or doesn't matter to do cancel() if not submit() ? >> > >> > 'the same' in the sense that both are resources which need to be >> closed. >> > So yes, it does matter that they are properly closed. >> > >> > >> > Thanks. I spent the afternoon shooting in a couple of directions related >> > to this (details in https://bugs.opendaylight.org/show_bug.cgi?id=9034# >> ). >> > >> > But the problem is what I've found so far is all just "stabs in the >> > dark". What we really need is a way to more reliably find the origin of >> > code where transactions (or TransactionChain) are created but never >> > closed... >> > >> > You mentioned on IRC that a datastore.cfg may have some option for that, >> > but I could not find this - does anyone know any details about that? >> >> nite@nitebug : ~$ cd distribution-karaf-0.6.2-SNAPSHOT/ >> nite@nitebug : ~/distribution-karaf-0.6.2-SNAPSHOT$ ./bin/karaf >> opendaylight-user@root>feature:install odl-mdsal-broker >> nite@nitebug : ~/distribution-karaf-0.6.2-SNAPSHOT$ ls -l >> etc/org.opendaylight.controller.cluster.datastore.cfg >> -rw-rw-r--. 1 nite nite 4896 Aug 23 20:47 >> etc/org.opendaylight.controller.cluster.datastore.cfg >> >> for some reason debug-transactions is not documented. >> https://git.opendaylight.org/gerrit/62224 fixes that. >> > > Tom, I've tried to dig into this (supposed) debug-transactions flag, but > am starting to have doubts if this feature actually really exists / works > (anymore? or ever did?) ... do you know anything more about the history of > this, or can take a moment to help us find out more? Cauz Robert on IRC > said: "yeah ... I don't know the exact story // the yang models was > definitely used hen we use CSS // what the exact state is these days ... > best ping tpantelis". So here's what I've found so far: > > sal-distributed-datastore/src/main/yang/distributed-datastore-provider.yang > is where this "debug-transactions" should be, because that is the model for > datastore.cfg. That YANG model does have all the other properties used in > that datastore.cfg, just not debug-transactions. > It's defined in the yang as transaction-debug-context-enabled so the .cfg file must have the same name. > sal-inmemory-datastore/src/main/yang/opendaylight- > inmemory-datastore-provider.yang does have a "debug-transactions" - so > its ...inmemory.datastore.provider.rev140617.DatastoreConfiguration has > an isDebugTransactions() - but I cannot find any usage of it, even in > inmemory-datastore. > > So it seems to be that something got lost here somewhere along the way - > is that possible? Or am I just too dumb, and not understanding what's where > in all this controller mdsal code?? ;-) > > BTW: What's the story for what is used and what is not used - > inmemory-datastore is history? Want me to raise a Gerrit to remove it? Or > still use for the test DataBroker (which I myself am I user of in our test > in genius and netvirt) ? > It's not used in production but still used in unit tests. It will be removed once we switch to mdsal project. > > >> > Otherwise, an idea I just had in >> > https://bugs.opendaylight.org/show_bug.cgi?id=9034#c7 would be to see >> if >> > I could bolt something onto that mdsal-trace we have (originally >> > contributed by Josh) to keep track of opened-but-not-yet-closed >> > transactions. See the idea? Could be very useful to get to the bottom of >> > this kind of problem, no? >> >> No need, as mentioned above. >> > > Well, until proven otherwise, it would seem there is a need after all > then? ;-) > > Let me spend some more time to see if I could build this feature - I'll > try to start rebuilding it from scratch; if there's existing code for this > (which I cannot find), please point me to it so I don't redo what already > exists somewhere! > > >> > > > As far as I can see, with my still very limited >> understanding of mdsal >> > > > internals, this does not seem to be the same as our earlier >> > > > https://bugs.opendaylight.org/show_bug.cgi?id=8941 >> > <https://bugs.opendaylight.org/show_bug.cgi?id=8941> >> > > <https://bugs.opendaylight.org/show_bug.cgi?id=8941 >> > <https://bugs.opendaylight.org/show_bug.cgi?id=8941>> raised by >> > > Stephen and >> > > > fixed by Robert (which is being follow-up on in >> > > > https://bugs.opendaylight.org/show_bug.cgi?id=9028 >> > <https://bugs.opendaylight.org/show_bug.cgi?id=9028> >> > > <https://bugs.opendaylight.org/show_bug.cgi?id=9028 >> > <https://bugs.opendaylight.org/show_bug.cgi?id=9028>> by Robert and >> > > Tom) - >> > > > does this initial quick analysis seem accurate to you? >> > > >> > > 9034 looks like 8941, except it's not transactions, but >> chains. I'll >> > > cook up a prototype. >> > > >> > > Thanks a lot !!! We'd love to out anything you come up with. >> > >> > As mentioned above, this is something else, so no patch coming from >> me >> > righ tnow ;) >> > >> > OK, misunderstood because you wrote "I'll cook up a prototype" ... ? >> >> Yeah, I checked the code out and responded with "Actually no...", which >> you quoted above ;-) >> >> Bye, >> Robert >> >> >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
