We came across what looks like a potential leak of GLContexts in the class jogamp.opengl.GLContextShareSet.
Whenever we create a context that is linked to a master context we have here is what happen:
--> Adds the new context in destroyedShares Map
--> Removes the new context from destroyedShares Map
--> Adds the new context to createdShares Map
Then when we close the corresponding window it tries to destroy the context
--> Removes the context from createdShares Map
--> Adds the context to destroyedShares Map
So at the end of the day, the context is still referenced by the destroyedShares Map.
And it gets stranger when I look at the code, as there is no way to actually remove a context from destroyedShares Map. The only place where #remove() is called on destroyedShares is in contextCreated, which adds the context to the createdShares Map.
Our users use virtualized workstations, so each physical workstation is shared by many users.
The actual problem we encountered is that, after a while, the XServer returns an error when we try to create a new context.
Running the following command:
/usr/sbin/lsof -U | grep socket | grep java | wc -l
Has shown that everytime we open and close a window using a GL context the XSocket is not closed/released (value returned by the command above is increasing).
For some reasons it happens only on those virtual workstation, on a real one, the socket is actually closed.
Our assumption/hypothesis is that a proper local XServer is more aggressive and release the resources/native-context even if it's still referenced by the java application.
As many users use the same XServer, the limit is "quickly" reached.