How can oneway requests arrive out of order?
Sequentially sent oneway requests cannot arrive out of order, but the server may dispatch them out of order.
Assuming that oneway requests are not sent in parallel by multiple threads, and that all oneway requests use the same connection to the server (which is usually the case, unless different protocols or timeouts are used), then the client-side Ice run time ensures that the protocol messages for these requests are sent in order.
However, if the server employs a thread pool with multiple threads, then the server-side Ice run time will dispatch oneway requests in parallel, up to the maximum number of threads that is configured for the thread pool. It is therefore possible for oneway requests to be dispatched in an order that differs from the order in which they were received, depending on how the operating system schedules threads.
Out-of-order dispatch cannot happen with twoway invocations. For sequentially-sent twoway invocations, the client always waits until it has received a response from the server for an outstanding twoway before it sends another twoway. Since the server only sends a response once it has completed dispatching of the twoway call (or at least started dispatching, if the server uses asynchronous message dispatching), twoways cannot be dispatched out of order.
There are three ways to avoid out-of-order dispatching of oneway requests:
- The first way is to simply configure only one thread for the server-side thread pool. With only one thread, no requests can be dispatched in parallel. (This is the default configuration.)
- The second option is to force the thread pool to dispatch requests serially by setting one of the thread pool properties for serialization.
- Finally, you can use batched oneways. All oneway requests from a single batch are guaranteed to be dispatched in order by the same server thread, regardless of the number of threads in the thread pool.