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

http://docs.janusgraph.org/latest/tx.html

> 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