Neo4JSession session leakages

[indrajra]

Version used - 0.2.27 We are observing that a database with 50000 nodes ends up leaking sessions on subsequent add/update/read operations. At first we thought it is because we were using a single instance of graph and creating multiple transactions. After the database is populated, we restarted our app and invoked just 1 call - read/write doesn't matter and it ends up in this error. Could it be memory related? I think not because the node is either written or read properly. Please advise on the possible next steps.

Finalizing Neo4JSession [227030447] without explicit call to close(), the code is leaking sessions!

[rjbaucells]

Please update issue with sample code, I am using this library on three applications on production for more than a year without any problems (more than 50K nodes). Make sure you are using it like this:

    // create graph instance
    try (Graph graph = new Neo4JGraph(driver, vertexIdProvider, edgeIdProvider)) {
        // begin transaction
        try (Transaction transaction = graph.tx()) {
            // use Graph API to create, update and delete Vertices and Edges

            // commit transaction
            transaction.commit();
        }
    }

The scope of the graph instance is limited to a single transaction (short lived) (unit of work)

[indrajra]

Thanks @rjbaucells. I see no more leaks, but my application that used to run at 45 (RPS) requests per second is now running at < 5. If you may share info, can you let know whats the throughput possible with this library and any suggestions to improvise? fyi - We use the default Neo4JNativeElementIdProvider both vertex and edge.

[rjbaucells]

Without any information on how you are using the library is impossible to provide suggestions... Make sure you are invoking CYPHER commands and not using gremlin traverse, the library is not optimized for that.

[indrajra]

ok, closing this.

• The leaks observed have gone away by making graph instance as short lived unit.
• One of the dependent services had some issues that caused slow turn around time. So highly likely that the library is not inducing the slowness.

[rjbaucells]

Good to hear you got it fixed