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
-~----------~----~----~----~------~----~------~--~---
