On Wednesday, 4 December 2019 at 22:51:45 UTC, Steven Schveighoffer wrote:

I localized that the leak was actually being caused by websockets. I want to write down my experience because I did some weird stuff which seems to be working but I want to learn how it actually make sense and works.

I had a fancy work flow which caused by that bug https://github.com/vibe-d/vibe.d/issues/2169 which disallowed to open multiple sockets from my main process.

I solved that by lunching multiple process and using one web socket by one process. And communicated this process and my main process via zmqd.

My suggestion is; don't do that. Don't be super creative with current Vibe websockets. I had this unidentifable leak which took to much time to localize.

The bug I created around one year ago is solved now so I left creating processes approach and put web sockets in to a list.

Next problem I had while listening 300 websocket was I got some crushes within webSocket.dataAvailableForRead() function, I am not sure if it is a bug or my misusage some how so I haven't created a bug yet. But my question to vibe forum can be seen https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/112309/

I solved that ( I hope ) by using something like:

if ( webSocket.waitForData(0.msecs) && webSocket.dataAvailableForRead() )

I know it looks so wierd to wait for 0.msecs but things seems to be working :/ .

The last problem I had was with closing the socket because this sockets are getting disconnected time to time. I need to close and reopen. When I call webSocket.close() directly, after my program runs about 1 day it was freezing in a function called epoll while calling webSocket.close().

I also find another weird solution to that problem :

while ( true )
{
auto future = vibe.core.concurrency.async( { socket.socket.close(); return true;} );
    vibe.core.core.sleep(100.msecs);
    if ( future.ready() )
        break;
    writeln( " Couldn't close the socket retring ");
}
sockets.remove(uniqStreamName);// BTW order of this removal matters if you remove
   //from your list before closing the ticket you are screwed.


Which seems to be working with 300 websockets around 2 days without any leak nor crush neither freeze.

As I pointed in the beginning I don't have any question or problems now but I am very open to feedback if you guys have any.

Erdemdem






Reply via email to