search

microsoft / cpprestsdk

The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.
Other
7.97k stars 1.65k forks source link

http_listener odd behavior #87

Open kreuzerkrieg opened 8 years ago

kreuzerkrieg commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.