B4J Question How to destroy a B4X object?

[LucaMs]

To protect my B4J web socket server, in some cases I want to destroy "web socket handler instances" automatically created when a user connects to my b4j web socket server.

Actually, we (or at least I) do not know how to destroy any object in B4X.
Using VB.Net (or C#) you can use the method Dispose; with B4X?

I have not found documentation in this regard, on site.

 

[LucaMs]

Once the WebSocket has disconnected then it will be released (assuming that you are not holding a reference yourself).

I have developed a very simple websocket server to test that.

I connect to the server and then a websocket handler instance is created; it calls a simple routine of a code module which logs the CurrentThreadIndex, then I disconnect.
There is nothing else, let alone there are references to the instance of that websocket handler.
I connected the client about 29 minutes after and the CurrentThreadIndex is increased (I don't know how to get the number of currently active threads, so I use CurrentThreadIndex).

 

[Erel]

It doesn't mean that the object was not released. The object was released.

Note that there are many B4J servers running for many months without any leak. If the websocket handlers would have not been released then the processes would have run out of memory pretty quickly.

 

[LucaMs]

It doesn't mean that the object was not released. The object was released.

Note that there are many B4J servers running for many months without any leak. If the websocket handlers would have not been released then the processes would have run out of memory pretty quickly.

If I undestand well, you mean:

although apparently they were not released, they have been so; the proof is that there are many b4j websocket active servers for months and they were going to crash, because of "out of memory" right?

 

[Erel]

No. CurrentThreadIndex is not the correct way to check whether they were released or not.

If you think that there is a memory leak in your program then you should use a tool such as VisualVM.

There are no internal memory leaks related to the handling of server handlers.

 

[OliverA]

I have developed a very simple websocket server to test that.

I connect to the server and then a websocket handler instance is created; it calls a simple routine of a code module which logs the CurrentThreadIndex, then I disconnect.
There is nothing else, let alone there are references to the instance of that websocket handler.
I connected the client about 29 minutes after and the CurrentThreadIndex is increased (I don't know how to get the number of currently active threads, so I use CurrentThreadIndex).

Case#1:

Assumption#1: Using Windows for "server"
Assumption#2: JDK installed on the same Windows machine

1) Start the server application
2) Go where the JDK is installed (example: C:\Program Files\Java\jdk1.8.0_92), go into the bin directory and start jconsole
3) Pick your server (it should show up in the "Local Process:" list)
4) Connect insecurely
5) Go to the threads tab and watch it as the clients connect/disconnect.

Case#2:

Assumption#1: Using Linux for server
Assumption#2: Using a Windows machine to monitor server application running on linux
Assumption#3: the JDK is installed on the Windows machine used for monitoring

It's a tad more complicated, but these links may help http://stackoverflow.com/questions/1922290/how-to-get-the-number-of-threads-in-a-java-process and http://stackoverflow.com/questions/834581/remote-jmx-connection.http://stackoverflow.com/questions/834581/remote-jmx-connection

In my case, I started a server on Linux via:

java -Djava.rmi.server.hostname=xxx.xxx.xxx.xxx \
 -Dcom.sun.management.jmxremote.port=54444 \
 -Dcom.sun.management.jmxremote.authenticate=false \
 -Dcom.sun.management.jmxremote.ssl=false \
 -jar CloudKVS_Server.jar 51043

Note#1: replace the xxx.xxx.xxx.xxx with the external IP address of the server (not 127.0.0.1)
Note#2: I did not use nohup to start it since I'm just playing here.

Then use the jconsole on the Windows machine to connect to the Linux machine and observe.