Hi John, (speaking of ruote 2.x) When you start 50 workflow processes together, the > first node of their expression tree is handled, 50 in a row. As soon as a > participant node is hit, a workitem is dispatched to the participant, when > the reply comes back to the engine, the reply is scheduled for execution. > The > workers pick the messages as they come, so when a participant takes some > time, its answer is delayed and work for other processes get executed > beforehand. > > Ruote workers are very dumb, they just pick up available work and perform. > > What you see is 50 messages getting processed one after the other. If you > look carefully at the output of the workers from my ruote_poc, you'll > notice > that even if it looks like a pack of 50 sheeps advancing on one front at > the > beginning, it then trickles and then some processes are processed faster. > The > participant in the ruote_poc are very simple, but they execute each in its > own Ruby thread (this default behaviour can be changed), so as the > executions > move on, the processes whose successive participants executed faster (the > whim of the thread scheduler) finish faster. It can be thought to simulate > somehow participants calling out to external services. > > Branches of workflows calling out to participants place themselves in wait > for the participant answer. That waiting time may vary. >
Ah, that indeed resembles more the behaviour we saw. When 50 participants finish right after each other, Ruote is doing housekeeping for all those processes first and only afterwards finds the first participants to be executed on the queue. In our first poc that explains the 10 seconds that passed before Ruote continued. This was reduced to 5 seconds when we switched to Yajl. > For ruote 3.0, as I did for some storages and was demanded/suggested by > some > people in this list, I'd like to try to keep a worker processing the same > workflow instance until it hits a participant. At that point it'd schedule > the participant work and yield, probably considering other workflow > instances. That would alter the "50 sheeps walking on single front" effect > you've been observing *right after the launch*. > In our case that would be more desirable. Thanks a lot for the thorough explanation! Best, Jarra -- -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en --- You received this message because you are subscribed to the Google Groups "ruote" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
