B4J Question WebSocketException: RemoteEndpoint unavailable causing memory leak?

Chris2

Active Member
Licensed User
Longtime User
I have a long running UI app that appears to have a memory leak. I have a test run that has been going for almost a month. In the last couple of this has gone from using around 500MB to around 2GB as reported in Task Manager.
I realise that Task Manager is not the most accurate of reports so have also started VisualVM running and can see the baseline memory use increasing:
VisualVM.PNG

Following advice already in these forums (thanks to everyone!), I've downloaded Eclipse Memory Analyser and looked at a few Heap Dumps from Visual VM.
The Leak Suspects report seems to point in an obvious direction:

Problem Suspect 1
"The thread java.lang.Thread @ 0x701444f38 JavaFX Application Thread keeps local variables with total size 957,166,720 (68.16%) bytes.
The memory is accumulated in one instance of "java.lang.Thread", loaded by "<system class loader>", which occupies 957,166,720 (68.16%) bytes......"
Accumulated Objects by Class in Dominator Tree
Label Number of Objects Used Heap SizeRetained Heap Size
java.lang.RuntimeException
First 10 of 111,298 objects
111,2984,451,920957,158,848

These 111,2985 objects are all 'WebSocketException: RemoteEndpoint unavailable' errors. (full error: "java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: org.eclipse.jetty.websocket.api.WebSocketException: RemoteEndpoint unavailable, current state [CLOSED], expecting [OPEN or CONNECTED]")

The app uses websockets to message other clients based on the WebSocket Based Push Framework tutorial & jWebSocketClient library.
With the current setup I'd expect about 10 push messages to be sent every minute or so.

I accept that the websocket will break and reconnect sometimes so am not necessarily surprised that errors are being generated (although this seems like a lot!), but should the errors be retaining so much RAM?

Many thanks in advance for the help.
 

Attachments

  • LeakSuspects.PNG
    LeakSuspects.PNG
    12 KB · Views: 202
Last edited:

Pendrush

Well-Known Member
Licensed User
Longtime User
Used heap is not released, you have memory leak somewhere for sure.
You have ~200MB larger used heap (not released memory) in ~48 hours.
 
Upvote 0

Chris2

Active Member
Licensed User
Longtime User
Thanks for your response.
That's what I thought, and the issue seems to be all the websocket exceptions. So my question is how do I stop them retaining memory, or put another way, what could I be doing that would cause these exceptions to be held and not release their memory?

My (very basic) understanding of the Garbage Collector is that if I don't have a reference to an object, then its memory will be 'collected' (i.e. released). I don't understand how I can be retaining a reference to these exceptions though?
 
Upvote 0

agraham

Expert
Licensed User
Longtime User
So my question is how do I stop them retaining memory,
Its not the exception objects themselves retaining memory but it seems that local variables are building up in that particular thread and each is holding a reference to an exception object. Ideally those variables need to be identified and nulled - but there my expertise runs out :(
 
Upvote 0

Chris2

Active Member
Licensed User
Longtime User
It would be helpful if you upload a project showing the problem.
Or at least post all relevant Code.
Of course, sorry.
The project itself is quite big and sprawling. It connects to a jRDC2 based server app that has the Websocket Push framework server modules added.
The websocket messages from the client are sent from various places with:
B4X:
WSPushService.SendMessageToAll("TextMsg")
The messages are getting through to the other clients, so the connection is OK sometimes at least.

Attached is a project with the relevant websocket modules.
 

Attachments

  • TestWS.zip
    5.9 KB · Views: 197
Upvote 0

Chris2

Active Member
Licensed User
Longtime User
Also, in case it helps anyone in helping me, attached is the zipped HTML report that is generated by Eclipse Memory Analyser when you do a Leak Suspect Report.
Thanks.
 

Attachments

  • heapdump-1634807982903-20211021_Leak_Suspects.zip
    83.1 KB · Views: 209
Upvote 0
Top