On Sat, Aug 8, 2009 at 3:10 PM, Jason<[email protected]> wrote: > > I spent some time today working heavily > with the ruote 2.0 engine and we came up with a few questions: > > 1. Ruote::ParticipantExpression.cancel takes an argument "flavour" > but doesn't seem to use it. Is this correct?
Hi Jason, this correct. The possible flavour are nil (regular cancel), :kill (super cancel, no on-cancel allowed) and :timeout (a cancel resulting) from a timeout. The participant expression doesn't currently use this flavour information, but now that you tell me about it I will pass the information to the participant implementation. Done : http://github.com/jmettraux/ruote/commit/ec702048a1ac840dea8e1c1810ac0cfdfb75dcc9 > 2. Looking at the ruote-rest (using ruote 1.x) implementation, there > seems to be the ability to pause various parts of the engine > (participants and the engine itself). However, we couldn't find this > functionality in ruote 2.0. Was this left out on purpose or should we > expect it in the future? Still thinking about how to implement it right in ruote 2.0 (especially with respect to timeouts). Engine pause is easier to implement that process pause. Out in the wild, process pause is usually synonymous with "the human participant still hasn't replied". Maybe you have a strong use case for it, please tell us about it. > 3. Most importantly, I noticed the behavior of the > concurrent_iterator has changed (and is possibly broken). In ruote > 1.x concurrent iterator spawns x instances of its block. Each > instance must reply before the loop replies. However, in ruote 2.0 it > seems the loop exists when only one of many instances receives a > reply. Here's a simple process definition that should illustrate the > differences: > > process_definition do > sequence do > concurrent_iterator :on_value => (1..10).to_a, :to_field => "f" do > cursor :rewind_if => '${f:__timed_out__}' do > # Delete the timed out field in case it was set from a > previous loop > unset :field => "__timed_out__" > participant_0 > participant_1 :timeout => "1m" > end > end > participant_2 > end > end > > All the participants of this definition are FsParticipants. Do you have a simpler case with detailed explanation ? The concurrent_iterator behaves as specified : http://github.com/jmettraux/ruote/blob/d422e583c987ff4465e395d26bcf17bd67d27d1a/test/functional/eft_18_concurrent_iterator.rb The cursor behaves as specified : http://github.com/jmettraux/ruote/blob/d422e583c987ff4465e395d26bcf17bd67d27d1a/test/functional/eft_14_cursor.rb Maybe you could write a similar test case that exhibits the flaw you mention. Please trim it to the essential. > 4. You'll notice in the example above I unset the __timed_out_ field > as it's left over from the previous run and will cause available_task > to reply immediately. Should this be the default behavior or should > participants clear this value upon initialization? I'm on the fence > about this one as the field may be useful to a later participant. I'm sitting on the same fence as you. I was thinking of maybe storing the timeout information in an array instead of the current "timeout information overrides any previous timeout information". Also note that ruote 2.0 introduces an "on_timeout" (Thanks @hassox and @kennethkalmer) attribute which you can use to write jason :timeout => '2d', :on_timeout => 'asm' where after two days, the workitem is handed to asm. You can specify a participant name or a subprocess name, or the word 'error' to trigger an error. Hope this will help, best regards, -- John Mettraux - http://jmettraux.wordpress.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
