Leaking DISCONNECTED_INBOUND endpoints

[pcoffey42]

Hey guys,

First off, thanks so much for this project, it's helped me out an incredible deal.

I wanted to reach out because I'm running into an issue and am not sure if I'm just doing something wrong or have found an issue.

I'm using SqlServer 2016, and running the service in a pretty simple manner. I've got it running in a console window, monitoring a single table. Changing table records triggers the event just like it should, but what I found was the service would always crash when I stopped the app, crashing specifically in the Uninstall method.

What was happening was the cleanup method was timing out, which I eventually ran down to the fact that, after a few hours or days of the app running, was that the conversation_endpoints table was just filled with thousands, sometimes tens or even hundreds of thousands, of DISCONNECTED_INBOUND records.

Looking around, I was that things like this could happen when conversations weren't properly "ended" (A fire and forget kind of scenario, right?). Is there something else I need to do to prevent this from occurring?

[dyatchenko]

Hello,

Thanks for reporting this issue. Looks like when there are too many simultaneous notifications some of them fail to dispose. Let me run some tests and see what I can find. It would be great if you can provide more information like exact sql version, how many notifications you have per second and if you could run unit tests on your environment to check if some of the notifications fail to dispose (there is an integration test for it).

Thanks, Dmitrii

On Thu, 22 Aug 2019 at 18:05, Philip Coffey [email protected] wrote:

Hey guys,

First off, thanks so much for this project, it's helped me out an incredible deal.

I wanted to reach out because I'm running into an issue and am not sure if I'm just doing something wrong or have found an issue.

I'm using SqlServer 2016, and running the service in a pretty simple manner. I've got it running in a console window, monitoring a single table. Changing table records triggers the event just like it should, but what I found was the service would always crash when I stopped the app, crashing specifically in the Uninstall method.

What was happening was the cleanup method was timing out, which I eventually ran down to the fact that, after a few hours or days of the app running, was that the conversation_endpoints table was just filled with thousands, sometimes tens or even hundreds of thousands, of DISCONNECTED_INBOUND records.

Looking around, I was that things like this could happen when conversations weren't properly "ended" (A fire and forget kind of scenario, right?). Is there something else I need to do to prevent this from occurring?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dyatchenko/ServiceBrokerListener/issues/64?email_source=notifications&email_token=ACNTMP4MTOABLZIGFU75WTTQF2MJBA5CNFSM4IOVNERKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HGZPYIQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNTMP4TTAC4AT5GL6JSX4LQF2MJBANCNFSM4IOVNERA .

-- Best Regards, Dmitrii Diatchenko Phone: +1 (425) 615-4359 Skype: dyatchenkodv [image: Dmitriy Dyatchenko] http://linkedin.com/in/dyatchenko