There was a timing problem with my 2.6 code, that I'd fixed last April and flagged to be backported. This might be another manifestation. I'd debugged it during transport shutdown. From the #132 commit notes: The thread scheduler doesn't necessarily do work in the order submitted. In this case, the scheduler can/will run the per transport cleanup task before other ready worker tasks, causing timing conflicts with the service request channel task. Use the channel task to free transports. Client call timeout is most likely increasing relative to other calls for the same connection, worst case for rbtree insertion. Profiling showed that rbtree was not a good choice, and TAILQ improved by 200%. Moreover, maintaining the potentially large list of timeouts in the service request was slowing event response. Instead, keep only one entry per transport, with callback timeouts maintained by transport.