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.