Closed postry closed 5 years ago
ecorm
commented
5 years ago Messages in AsioTransport are indeed queued, but I see now that the logic is faulty. AsioTransport::transmit is where it happens. The problem is that txQueue_.empty() can return true while an async_write operation is in progress. There needs to be another member variable added that keeps track of the pending write operation.
ecorm
commented
5 years ago I'd like to give credit to @postry for his hard work in troubleshooting the problem. He spent much time consulting the WAMP spec, corresponding with the Crossbar team, debugging Crossbar & CppWAMP, and analyzing wire traffic.
Because of the urgency of solving this problem (due to a company deadline), and because I work different time shifts than @postry , it was not possible for me to walk him through the changes needed in #118 so that the CppWAMP unit tests would pass.
I therefore had to proceed with my own solution, which I had independently drafted before I saw his. Because @postry had isolated the problem to a specific module, it was easy for me to come up with my own independent solution.
The lion's share of the effort was in the troubleshooting the problem, and thank @postry for his hard work. :+1:
Messages in AsioTransport are not queued. So when the first message that is being sent is large and takes a "long time" to transfer it a second call to AsioTransport::send is invoked from a different place in the code causing async_write to be called before the first write operation completion. According to the documentation the boost::asio:async_write operation is implemented in terms of zero or more calls to the stream's async_write_some function, and is known as a composed operation. The program must ensure that the stream performs no other write operations (such as async_write, the stream's async_write_some function, or any other composed operations that perform writes) until this operation completes.