[Mono-dev] WebRequest timeouts after ThreadPool exhaustion

Hi, We are running mono 4.2.2 in prod and the VM that the process was running on had SAN failure and after storage recovered, all outgoing requests were timing out, even though doing a curl was working fine. Theory was that thread pool starved and somehow things didn't recover properly. Managed

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

we’ve also seen instances of webrequest timeouts that don’t recover (but curl worked) as well but haven’t got to the bottom of it yet. we ran your test app and see the same issue with mono 3.12 on OpenSUSE 13.2 (kernel 3.16.7, libc 2.19). we’ll add the diagnostics from your test app into ours

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

Hey Seif We're also seeing this in production and it's causing a bit of pain. We can reproduce the issues with your gist. We're on 3.12 on prod too Cheers Jonathan On Friday, 12 February 2016, Seif Attar wrote: > Hi, > > We are running mono 4.2.2 in prod and the VM that

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

we’ve also seen instances of webrequest timeouts that don’t recover (but curl worked) as well but haven’t got to the bottom of it yet. we ran your test app and see the same issue with mono 3.12 on OpenSUSE 13.2 (kernel 3.16.7, libc 2.19). we’ll add the diagnostics from your test app into ours

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

Great, I'll try it out. Is the console app in that gist enough for a test case? @Mike @Jonathan we've faced bugs with previous versions of libc and networking before, also some kernel issues. Update to latest if you can. I can't reproduce with 3.12. I get timeouts but then it recovers when there

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

Happens on mono-4.3.2-branch/9f44a62 as well... Alan: the PR you linked doesn't seem to be related, did you have another PR in mind? - Alex 2016-02-12 15:07 GMT+01:00 Alexander Köplinger < alexander.koeplin...@xamarin.com>: > I tried the testcase on master and couldn't reproduce there. I

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

Sorry, turns out I made an error when testing on master. I can actually see the request timeout there too, so it's not fixed on master. I filed a bug with your repro code: https://bugzilla.xamarin.com/show_bug.cgi?id=38715 - Alex 2016-02-12 15:13 GMT+01:00 Alexander Köplinger <

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

Hey, We have just fixed some issues in that area. They are expected to ship as part of a the next mono 4.3+ release. If you want to test them out in the meantime you could try building mono with this PR [0] and see if it resolves all your issues. If it doesn't then a testcase and bug report on

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

It's also worth pointing out that the threadpool implementation has changed completely since mono 4.0. I believe the new threadpool implementation shipped as the default starting with mono 4.2 (or thereabouts). If you're on older Monos the odds are high whatever issue you have has been fixed

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

I tried the testcase on master and couldn't reproduce there. I could, however, reproduce it on the 4.3.2 build I had installed (mono-4.3.2-branch/0df254d). I'm downloading a later 4.3.2 build right now to see if it still happens there, if it does then we need to backport something from master. -

Re: [Mono-dev] Unsafe code performance on Mono

Thank you for your response, Vladimir. > Could you please provide detailed step-by-step instructions on how you got > those results, or (ideally) a self-contained benchmark that would expose that > difference? I coded a simple example that performs three compress-decompress cycles, measuring

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

I like those long meaningful commit messages :) seems related but then again it is threading. Thanks for opening the bug report Alexander, I'll keep an eye on it. On Fri, 12 Feb 2016 15:59 Alan wrote: > Ah, sorry, i meant this commit >