IO Service Association in Win32NamedPipeClientTransport

[joel]

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

[jarl]

Hi Joel,

The intent of the code is to create one deadline timer object for each callback connection, lasting for the duration of that connection. So if you are seeing deadline timers created for each read/write that's a definite bug... Is that what's happening in your program?

I think associating the deadline timers with the same server io service as the other async operations is a good idea. Are you able to send me a patch with your changes? Or just the source code files is fine, and I can diff them here.

Thanks,

[joel]

Hi Jarl,

Sorry if my previous email was too vague. There's only one deadline timer per callback connection, but the deadline timer is rescheduled for each async read/write, and a new AmiTimerHandler object is allocated for each new reschedule. In my case, when I run my stress tests with high load, this handler object is always cancelled upon I/O completion but the object is still a work item which the AMI thread needs to process even though its got a cancellation error code.
Since I've more or less always have data available for send, the server threads do async write/async reads at a rather furios pace, littering the AMI thread with cancelled timer handler objects, which it just cant keep up with. Moving the deadline timer to the server's thread pool's io_service forces the server's threads, which are responsible for the I/O completion work items to also handle the timer cancellation cleanups, which makes the system behave more reliable (i.e. I dont get the asio cache AmiTimerHandler vector expansion).

I'll send you my patched file. The "fix" is quite small.

Regards,
Joel Hortelius

[jarl]

Thanks for the patch. This has been fixed in RCF 2.1.0.0 .