http_listener odd behavior

[kreuzerkrieg]

Before I'm starting to debug cpp REST SDK code...
I've implemented server/client using http_listener and http_client. Everything is made by the book, every get/wait wrapped with try/catch and, surprisingly, everything works as expected. Except one thing. The client API has function in two flavors sync and async, the sync just uses the async and calls get. I have two tests, one "for" loop running sync client function 100 times and the same "for" loop for async. Everything is OK, even if I run above "for"s in infinite loop for an hour. BUT, if I increase the number of repetitions in the async "for" loop from 100 to 1000 the following happens, the server jumps to ~570 threads, client dies on timeout and the server is no more responding. is there some kind of internal thread pool which cant grow beyond some point and crossing that bound kills the listener? is it configurable? any workaround in case I have to accept large number of requests simultaneously?

[ras0219-msft]

We do use a threadpool, however there should be no strict maximum that kills the program. On Windows with VS 2015, we use the Windows Threadpool (which dynamically scales as needed). On OSX/iOS we use Grand Central Dispatch (I believe this also dynamically scales). On Linux/Android we use a fixed size boost threadpool which defaults to 40 threads.

I'm not sure why you'd see the program crash though; all the above pools should support at least 1000 open connections.

Could you try testing the listener and client separately against some "known good" implementations? Our client is much more polished than the listener, so it would be useful to know where the problem lies between the two.

[kreuzerkrieg]

I dont suspect the client, we use it extensively and it runs on various scenarios in production code and everything is just fine. I will try to setup simple tester to reproduce the problem in the listener.