cog-rocks-print/print_range not working after cog-atomspace-clear about atomspace-rocks HOT 7 CLOSED

The problem is that rsn is an Atom -- specifically, it is (RocksStorageNode "rocks://something/or/other") and the (cog-atomspace-clear) has the effect of deleting it.

It's trivial to get it back, though; just define it again:

(define rsn (RocksStorageNode "rocks://whatever/it/was"))

and now the cog-rocks-print should work again.

Yes, it would seem the example is broken. Let me look.

from atomspace-rocks.

OK, I see that this is not part of the demo. A few comments, and then I'll close this issue (re-open if you feel it's necessary or have a better idea.)

That demo uses (cog-rocks-open "rocks:///tmp/foo.rdb") instead of using RocksStorageNode. This is actually a lucky accident. Some history:

Long ago, before the age of dinosaurs, there was a PostgresSQL backend to the AtomSpace. You opened and closed it using C++ code. When first creating the Rocks backend, this, too, was the simplest, most expedient solution. But C++ is ... tedious, so cog-rocks-open was created as a simple wrapper that could be used for testing ... and even for regular use. And all was good in the world.

And then ... a sequence of inspired dominoes: Instead of writing (cog-rocks-open "rocks://some/url") it would be nice to allow (cog-rocks-open (ConceptNode "rocks://some/url")) so that the URL itself could be stored. But that's too generic, so maybe it should be (cog-rocks-open (URLNode "rocks://some/url")) but what should the URL handler actually do? So maybe it should be (cog-generic-open (URLNode "rocks://some/url")) but what if some damn-fool nincompoop tries (cog-generic-open (URLNode "https://example.com/something")) and then starts spamming complaints on the mailing list when this doesn't work? Arghh.

So maybe instead (cog-generic-open (GenericStorageNode "rocks://some/url")) but that has issues figuring out how to find the actual C++ code that actually knows how to open the right thing with the right driver. And so .. the current solution: (cog-open (RocksStorageNode "rocks://some/url")) and maybe someday there could still be a GenericStorageNode but so far, it has not been needed.

Meanwhile, the StorageNode concept has proven to be very useful and reliable and flexible, and I am especially thrilled with ProxyNode's https://wiki.opencog.org/w/ProxyNode so it seems to be a solid, workable concept.

That demo predates the StorageNode idea, or at least, it's before it became brilliantly clear that StorageNodes are the right way to do things.

As a side effect, though, it accidentally avoids the bad things that happen if you create a StorageNode, and then delete it, and then wonder wtf???

Also: FYI, when you delete the rsn, it might close the connection automatically, and you might have to reopen it. Not sure. I can say for certain: it is a bad idea to mix both cog-rocks-open and also RocksStorageNode in the same code base.

There's a good argument to be made for getting rid of cog-rocks-open entirely, precisely because it can lead to convoluted logic and confusing flow of control.

from atomspace-rocks.

Just an afterthought:
I tried this example again only with rock storage node and didn't use cog-rocks-open at all. After cog-atomspace-clear, this happened:

scheme@(guile-user)> (define rsn (RocksStorageNode "rocks:///tmp/foo.rdb"))
scheme@(guile-user)> (cog-open rsn)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Atomspace C++ exception:
(cog-open Can't open file: IO error: lock hold by current process, acquire time 1679384119 acquiring thread 140464966962048: /tmp/foo.rdb/LOCK: No locks available (/home/opcwdir/repodock/atomspace-rocks/opencog/persist/rocks/RocksStorage.cc:110)
Function args:
((RocksStorage "rocks:///tmp/foo.rdb")
))

Looks like the handle of the DB doesn't get released or so.
(cog-close rsn) says that rsn is not open. It works if the RocksDB is closed before cog-atomspace-clear (if rocks is closed after the AS is cleared, there is also an exception been raised).

from atomspace-rocks.

I'm reopening this issue, the last comment describes what seems like a real bug. I'll look at it more closely "real soon now". I'm guessing that the delete of the RSN node should have also closed the connection, but didn't. Odd. Normally I'm careful with such things.

from atomspace-rocks.

Hmm. Tried debugging. This is actually difficult. The destructor is closing the connection, but the destructor is never called, because the use-count on the smart pointer stays above zero. I'm trying to track down where -- what code still holds a handle, but am having trouble doing this. It's all very ephemeral, and hard to track.

from atomspace-rocks.

Found it. Fixed in opencog/atomspace#3035

Even after you clear out the atomspace, there was still a (global) pointer to the currently open storage node. This pointer kept the StorageNode alive and open. This prevented the destructor from running, which prevented it from getting auto-closed. The fix was to make sure that the pointer to an un-owned storage node gets wiped before an attempt to (re-)open it is made.

from atomspace-rocks.

Closing again. Fix is merged, and there's a unit test for this now.

from atomspace-rocks.