January 08, 2021
On Tuesday, 5 January 2021 at 21:12:01 UTC, Selim Ozel wrote:
> On Monday, 4 January 2021 at 17:17:10 UTC, Steven Schveighoffer wrote:
>> On 1/2/21 12:52 PM, Selim Ozel wrote:
>>
>>> 
>>> After logging into to 127.0.0.1 for a single time in my browser, if I do a ctrl+c it still leaks two socket handles.
>>> 
>>> With connection Windows 10:
>>>> Running .\vibe_noleaks.exe
>>>> [main(----) INF] Listening for requests on http://[::1]:8080/
>>>> [main(----) INF] Listening for requests on http://127.0.0.1:8080/
>>>> [main(----) INF] Please open http://127.0.0.1:8080/ in your browser.
>>>> [00000000(----) INF] Received signal 2. Shutting down.
>>>> [main(----) INF] Stopped to listen for HTTP^ requests on C::1:8080
>>>> [main(----
>>>> ) INFC:\Software\vibe_noLeaks>] Stopped to listen for HTTP requests on 127.0.0.1:8080
>>>> Warning: 2 socket handles leaked at driver shutdown.
>>>> Warning: 2 socket handles leaked at driver shutdown.
>>
>> This is normal. The server uses keepalive connections, so that in case any more requests arrive on the same connection, the initial connection setup does not need to be established. Well, at least that is what I think is happening.
>>
>> If you want a few seconds (I think 5 or so), then you won't get these.
>>
>> It would be good if vibe-d could provide a way to shut down any keepalive connections when the server is shutting down.
>>
>> -Steve
>
> That's interesting. I actually started to dive deeper into those and tried to pinpoint the lines of code that result in additional open sockets upon new http connections; although my understanding of vibe-d is a bit too low at this point to figure out what's exactly happening.
>
> I think from a user perspective having something a bit friendlier on warning side would be helpful.

Bausshf built a wrapper around vibe.d sockets called cheetah. Haven't used it myself but it looks more abstracted than than actual vibe.d code. Can't speak of the quality since I haven't used it myself.

Also it's got both a server and client abstraction but only the server example is shown. Still not low-level though.

https://github.com/bausshf/cheetah/wiki/Simple-Socket-Server-Example


I've used the very vibe.d example you referenced in the past and didn't have any trouble with it. So it could possibly be a bug or regression.

If you've have wsl2 installed on Windows, try running on the Linux side too.

Do you have any
> suggestions in mind towards that? I have a bit of time this week and I could take a stab at it.
>
> B


January 08, 2021
On Friday, 1 January 2021 at 22:07:28 UTC, Selim Ozel wrote:

> [2] https://github.com/SelimOzel/vibe_noLeaks

I don't see anything abnormal in this code though. Will trying it later today myself.

Could you show the actual socket code causing that leak?
January 13

I am still getting this in 2024 and vibe.d 0.9.7:

Warning: 1 socket handles leaked at driver shutdown.

I was wondering if maybe someone has new info on this...

January 14

On Saturday, 13 January 2024 at 20:49:54 UTC, bomat wrote:

>

I am still getting this in 2024 and vibe.d 0.9.7:

Warning: 1 socket handles leaked at driver shutdown.

I was wondering if maybe someone has new info on this...

There should be a version you can enable that tells you where that socket handle was allocated. That might give you a further clue as to why it's not closed when the system shuts down.

I think the program tells you which version to enable when this happens, but if not, let me know and I'll find it.

-Steve

January 15

On Sunday, 14 January 2024 at 20:36:44 UTC, Steven Schveighoffer wrote:

>

There should be a version you can enable that tells you where that socket handle was allocated. That might give you a further clue as to why it's not closed when the system shuts down.

I think the program tells you which version to enable when this happens, but if not, let me know and I'll find it.

-Steve

Thanks for the response, Steve.
Hmmm, not sure if I'm missing something, but this is all the output I get from the program:

[main(----) INF] Listening for requests on http://[::1]:8080/
[main(----) INF] Listening for requests on http://127.0.0.1:8080/
[00000000(----) INF] Received signal 2. Shutting down.
[main(----) INF] Stopped to listen for HTTP requests on ::1:8080
[main(
----) INF] Stopped to listen for HTTP requests on 127.0.0.1:8080
Warning: 1 socket handles leaked at driver shutdown.
Warning: 1 socket handles leaked at driver shutdown.

Unless there's some switch to make it more verbose?

January 15

On Monday, 15 January 2024 at 17:24:40 UTC, bomat wrote:

>

On Sunday, 14 January 2024 at 20:36:44 UTC, Steven Schveighoffer wrote:

>

There should be a version you can enable that tells you where that socket handle was allocated. That might give you a further clue as to why it's not closed when the system shuts down.

I think the program tells you which version to enable when this happens, but if not, let me know and I'll find it.

Thanks for the response, Steve.
Hmmm, not sure if I'm missing something, but this is all the output I get from the program:

[main(----) INF] Listening for requests on http://[::1]:8080/
[main(----) INF] Listening for requests on http://127.0.0.1:8080/
[00000000(----) INF] Received signal 2. Shutting down.
[main(----) INF] Stopped to listen for HTTP requests on ::1:8080
[main(
----) INF] Stopped to listen for HTTP requests on 127.0.0.1:8080
Warning: 1 socket handles leaked at driver shutdown.
Warning: 1 socket handles leaked at driver shutdown.

Unless there's some switch to make it more verbose?

Which driver are you using? In the posix driver, it should mention (and use) the debug flag EventCoreLeakTrace.

https://github.com/vibe-d/eventcore/blob/7fa0a15fa541c3fcf65640ee332fd3a09c34730c/source/eventcore/drivers/posix/driver.d#L130

I didn't realize this wasn't across the board...

-Steve

January 15

On Monday, 15 January 2024 at 17:45:16 UTC, Steven Schveighoffer wrote:

>

Which driver are you using? In the posix driver, it should mention (and use) the debug flag EventCoreLeakTrace.

https://github.com/vibe-d/eventcore/blob/7fa0a15fa541c3fcf65640ee332fd3a09c34730c/source/eventcore/drivers/posix/driver.d#L130

I didn't realize this wasn't across the board...
-Steve

Sorry, I probably should have mentioned I was on Windows.
For testing it under Linux I commented out the call to connectMongoDB, since I don't have it installed there - and the warning went away.
Interesting, I did not suspect that as the source of the problem at all. :P

I'm now looking into how to clean up MongoDB connections properly, but don't see anything besides cleanupConnections() (which I'm already calling without any effect).
Maybe I need to initialize it differently... I'll experiment a bit.

January 15

On Monday, 15 January 2024 at 18:40:00 UTC, bomat wrote:

>

Sorry, I probably should have mentioned I was on Windows.
For testing it under Linux I commented out the call to connectMongoDB, since I don't have it installed there - and the warning went away.
Interesting, I did not suspect that as the source of the problem at all. :P

I'm now looking into how to clean up MongoDB connections properly, but don't see anything besides cleanupConnections() (which I'm already calling without any effect).
Maybe I need to initialize it differently... I'll experiment a bit.

You may have to do the same thing I did with redis:

https://github.com/vibe-d/vibe.d/pull/2372

Good luck! I would also say, I don't know why Windows doesn't do the same trace info debug thing, except that probably whomever added it didn't care about windows.

-Steve

January 16

On Monday, 15 January 2024 at 22:19:56 UTC, Steven Schveighoffer wrote:

>

You may have to do the same thing I did with redis:

https://github.com/vibe-d/vibe.d/pull/2372

Good luck! I would also say, I don't know why Windows doesn't do the same trace info debug thing, except that probably whomever added it didn't care about windows.

Many thanks for the assistance.

1 2
Next ›   Last »