Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not all members in Multicastclient are disposed #93

Open
fgheysels opened this issue Jan 27, 2020 · 10 comments
Open

Not all members in Multicastclient are disposed #93

fgheysels opened this issue Jan 27, 2020 · 10 comments

Comments

@fgheysels
Copy link

fgheysels commented Jan 27, 2020

When instantiating a MulticastService object, I see that 2 UdpClient instances are created. However, those 2 instances are not disposed when disposing the MulticastService object. Since UdpClient implements IDisposable, I believe those 2 instances should be disposed as well ?

It seems that not disposing the UdpClient instances causes a memory leak.

@fgheysels
Copy link
Author

I've created pull-request 94 for this.

@fgheysels
Copy link
Author

@richardschneider : Do you have any chance to take a look at this issue and the corresponding PR since this is a bug that is hurting us.

Thanks in advance

@queequac
Copy link

No contributions from @richardschneider for months now, no comments on issues. :(
Temporarily I am using a local built with this and my fix, since I don't want to create a competing fork.

@fgheysels
Copy link
Author

We're using a local build as wel ftm, but I'd like to get rid of it sooner then later :)

Hope @richardschneider is doing well.

@fgheysels
Copy link
Author

No contributions from @richardschneider for months now, no comments on issues. :(
Temporarily I am using a local built with this and my fix, since I don't want to create a competing fork.

Maybe we should, since it's almost 6 months since @richardschneider was active on github

@queequac
Copy link

@fgheysels In the meanwhile I also think at least a temporary fork might indeed be a good idea. Are you familiar with GitHub Actions and publishing NuGet packages?

@fgheysels
Copy link
Author

No, I'm not familiar with GitHub Actions, I mostly use Azure DevOps which also integrates well with Github repos.

@queequac
Copy link

The question remains open, how we would actually do this.
Who owns the fork and creates the NuGet packages? How to name those packages to make clear its a fork and not the official ones from @richardschneider, etc.?

@fgheysels
Copy link
Author

Should we fork it to a separate GitHub account instead of to one of our personal accounts ?
Do you have any experience with GitHub actions ? If not, I see 2 options: or we use Azure DevOps, or we learn something new and investigate on GitHub actions :)

@queequac
Copy link

I have also neither worked with GitHub Actions, nor published packages to NuGet. So it would more be the "learn something new" approach. ;)

Aside from this, I'd also prefer a separate account/organization rather than using our personal accounts. Nevertheless I wrote an email to Richard some minutes ago, just to give him yet another chance to stop us. And maybe we can switch to some other tool or good old email for further disucssions instead of flooding this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants