Archived
This forum has been archived. Please start a new discussion on GitHub.
Sequential order processing?
Since Ice does not guarantee that method invocations are processed in order I was wondering if there were any recommendations or best practices.
What I have is a scenario, very simliar to the one Ice Mutex discussion, in which a number of methods are invoked, and then I need a way to wait on all of them to complete prior to processing the next command.
Client code looks as follows:
for (int i = 0; i < numSubWidgets; i++)
{
// Create new SubWidget.
subWidget = new SubWidget();
// Send the widget to the server for processing.
serverProxy->consume(subWidget(i));
}
// Inform that server that all sub-widgets have been sent.
serverProxy->end();
What I need to happen is that the server->end() method is invoked after all of server->comsume() commands have completed. Basically the server side processing of the end() method needs to wait on all previously dispatched consume() methods.
I guess I could limit the server thread pool to 1, but I'm hoping for a more general solution.
What I have is a scenario, very simliar to the one Ice Mutex discussion, in which a number of methods are invoked, and then I need a way to wait on all of them to complete prior to processing the next command.
Client code looks as follows:
for (int i = 0; i < numSubWidgets; i++)
{
// Create new SubWidget.
subWidget = new SubWidget();
// Send the widget to the server for processing.
serverProxy->consume(subWidget(i));
}
// Inform that server that all sub-widgets have been sent.
serverProxy->end();
What I need to happen is that the server->end() method is invoked after all of server->comsume() commands have completed. Basically the server side processing of the end() method needs to wait on all previously dispatched consume() methods.
I guess I could limit the server thread pool to 1, but I'm hoping for a more general solution.
0
Comments
-
Ice of course guarantees ordering for twoway messages. But for oneway messages, it's not possible to guarantee ordering, because of thread context switching in the server. I.e., even though oneway methods arrive sequentially, they are dispatched in parallel, which makes it impossible to predict which one is processed last.
You can use batch oneways. However, this doesn't give you what you want: oneways from one single batch are guaranteed to be processed by the same thread, in the order they were sent. So there is no parallel processing for the requets in a batch.
The only way I can think of to do what you want to do is to somehow put the logic into your own server. That is, end() should know how many times you sent a consume(), and should wait until all consume() calls have been processed (using wait/notify on a monitor).0 -
Hi Marc, Thanks again! We're using oneway's in this case. We had been thinking along the lines of your suggestion too. Sounds like we are headed in the right direction. --Roland0
