sluebbert

It is interesting that even commenting out the module in the web.config `` still results in a memory leak. As expected, no transactions or metrics get sent to the apm...

We have a few other working services now to compare with. Services that are not hogging up memory are those that just enable the apm agent and that's it. Each...

Thanks for checking it out. I seemed to have recreated it from creating a new .net framework webapi service within this repo's source code. I just: - added in a...

@gregkalapos, Thanks for the quick responses. I added that setting to the web config for one of our impacted services and it seems to have done the trick. I haven't...

A few days later and still no issues with memory.

I'll add my use case to this as well. We have a less critical environment where we allow our services in Nomad to auto-scale from 1 instance up to 4...

It looks like autoscaling is just a trigger. We encountered the same issue with another job this morning, but due to migrations from draining a node. Something just seems out...

We had the same issue. We were using robot accounts in Harbor to use in Octopus Deploy. Harbor defaults to the robot username prefix of `robot$`. While this works in...

We just found a job stalled like this for 15 days. Over that time the existing allocations from the previous "version" exited for natural reasons and we ended up with...

FWIW, we were getting this same error, but it came down to the simple issue of us giving existing ConnectionMultiplexer connections to the RedLockFactory and then later disposing those connections...