Hi John, Just to follow up: the definition below produces the desired workflow in ruote 1.x.
Cheers, -Jason On Mon, Aug 10, 2009 at 10:38 AM, Jason<[email protected]> wrote: > Hi John, > > I agree with regards to pausing individual process instances. It > should be sufficient to just be able to pause the entire engine. > > Here is a much simpler Ruote 2.0 example that demonstrates the > concurrent_iterator problem I'm having: > > ::Ruote.process_definition :name => "concurrent_iterator" do > sequence do > concurrent_iterator :on_value => (1..10).to_a, :to_field => "f" do > sequence do > participant_1 > participant_2 > end > end > participant_3 > end > end > > This definition will exit the iterator loop (and reach participant_3) > as soon as only one of the concurrent sequences contained within > replies. It seems the only difference between this example and those > in the tests is I've nested a sequence inside of the loop instead of > just a bare participant. > > An array of timeout history is not a bad idea but could lead to memory > problems as tasks continue to loop. For the moment, I'm ok with > unsetting the field or using the syntax you mentioned below. > > Cheers, > -Jason > > On Sat, Aug 8, 2009 at 10:18 PM, John Mettraux<[email protected]> wrote: >> >> 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 -~----------~----~----~----~------~----~------~--~---
