I have been wrestling with some kind of memory/reference leak using Aleph and JanusGraph in tandem
It looks like Aleph works fine on its own, and Janus works fine on its own
but when combined, memory increases without bounds
I have done some research and it looks like part of the problem is that Janus transactions are thread specific
So, if a transaction is opened on a thread, it must be closed on that same thread
I'm wondering how do I even debug this problem?
For instance, I am doing this
(stream/on-drained
source
(fn []
(log/debug "query complete")
(db/commit graph)
(db/rollback graph)))
But how do I guarantee this function is being called on the same thread that the transaction was opened on?
Do the on-drained
callbacks always get called from the same thread that the handler is using?
If not, how do I ensure they do?
@spangler I'm not exactly sure, but http://aleph.io/manifold/execution.html might be helpful
> Almost all interaction with JanusGraph is associated with a transaction. JanusGraph transactions are safe for concurrent use by multiple threads. Methods on a JanusGraph instance like graph.v(...) and graph.commit() perform a ThreadLocal lookup to retrieve or create a transaction associated with the calling thread. Callers can alternatively forego ThreadLocal transaction management in favor of calling graph.newTransaction(), which returns a reference to a transaction object with methods to read/write graph data and commit or rollback. I think that might be what you need to do?
@danielcompton Thank you! I now have some leads to follow. I will report back work how it turns out.
So do you know if in general the ondrained
callback is called in the same thread as the handler?
I sort of assume not