Possible memory/thread leak

[johny65]

We have a web application that connects to a OrientDB server. When an user connects, we initialize a pool:

this.orientDB = new OrientDB(...);
this.dbPool = new ODatabasePool(this.orientDB, ...);

And then use it:

try (var session = dbPool.acquire()) {
    ...
}

When the user ends, we close all:

this.dbPool.close();
this.orientDB.close();

The app has a few users, but every amount of days it throws:

java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
	at java.base/java.lang.Thread.start0(Native Method)
	at java.base/java.lang.Thread.start(Thread.java:803)
	at java.base/java.util.Timer.<init>(Timer.java:177)
	at com.orientechnologies.orient.core.db.OrientDBRemote.<init>(OrientDBRemote.java:73)
        ...

and we have to restart it. Inspecting a heap dump, we see this numbers:

• instances of OrientDB: 36
• instances of ODatabasePool: 36
• instances of ODatabasePoolmpl: 2362
• instances of OrientDBRemote: 2362

Evidently there are instances not being liberated but we don't know why. What could be the cause?

[timw]

@johny65 - are you able to see the paths to GC root for those objects?
If you're not experienced in heap dump analysis, if you can post the heap dump somewhere we could possibly have a look.
Eclipse Memory Analyzer has a heap dump redaction function that you can use to strip out object contents if it's a production heap dump.

Do you need a distinct pool for each end-user?
We tend to just use a single pool kept open for the lifetime of the application for all requests, which is perhaps why other people haven't noticed a problem.

[johny65]

Thanks for your reply @timw. I'll see if I can post a heap dump.

Do you need a distinct pool for each end-user?

No necessarily... Does having only one not cause you problems? What size are you using? We can try this approach.

[timw]

Having one pool doesn't cause a problem for us - currently just using the defaults of 1-100 connections.