IO Service Association in Win32NamedPipeClientTransport
Posted: Thu Apr 23, 2015 12:08 pm
Hi Jarl!
In the IO service association methods and some specific constructors in the Win32NamedClientTransport the deadline timer is associated with the AMI Pool IO Service instead of the IO Service provided with the function.
In my setup I have a server which creates callback connections using the createCallbackConnection methods. This results in client transports that are associated with the server IO service, with the exception of the deadline timer. Since the deadline timer is allocated for each async read/write and I have numerous server threads handling a large number of clients, I end up with a huge number of timers which supposedly are to be managed by the AMI Thread, which does not cope with the load. The end result is an asio cache vector array of a couple of million entries before the process dies of memory usage issues.
When I modified the IO service association/constructor to point the deadline timer towards the provided service object, the program behaved as expected. Is this the intended behaviour?
Regards,
Joel Hortelius
In the IO service association methods and some specific constructors in the Win32NamedClientTransport the deadline timer is associated with the AMI Pool IO Service instead of the IO Service provided with the function.
In my setup I have a server which creates callback connections using the createCallbackConnection methods. This results in client transports that are associated with the server IO service, with the exception of the deadline timer. Since the deadline timer is allocated for each async read/write and I have numerous server threads handling a large number of clients, I end up with a huge number of timers which supposedly are to be managed by the AMI Thread, which does not cope with the load. The end result is an asio cache vector array of a couple of million entries before the process dies of memory usage issues.
When I modified the IO service association/constructor to point the deadline timer towards the provided service object, the program behaved as expected. Is this the intended behaviour?
Regards,
Joel Hortelius