Kill-resistant processes

40 views
Skip to first unread message

Claudio

unread,
Apr 20, 2012, 4:11:39 AM4/20/12
to ruote, amedeo....@gmail.com
Hello guys, hello John,

With my team, I am using the wonderful Ruote engine (recently upgraded
to 2.3.0) in a production environment, with an average of 20 new
processes created every day.

I recently fixed a bug in a workflow that caused some workitems to
move into an error condition.

I had the following information about the error:
message:
#<NoMethodError: undefined method `size' for nil:NilClass>
trace:
/home/rails/apps/arts/shared/bundle/ruby/1.8/gems/ruote-2.2.0/lib/
ruote/exp/fe_concurrence.rb:286:in `merge_all_workitems'
.../ruby/1.8/gems/ruote-2.2.0/lib/ruote/exp/fe_concurrence.rb:258:in
`reply_to_parent'
.../ruby/1.8/gems/ruote-2.2.0/lib/ruote/exp/flowexpression.rb:228:in
`do_apply'
.../ruby/1.8/gems/ruote-2.2.0/lib/ruote/worker.rb:326:in `launch'
.../ruby/1.8/gems/ruote-2.2.0/lib/ruote/worker.rb:243:in `process'
.../ruby/1.8/gems/ruote-2.2.0/lib/ruote/worker.rb:173:in `step'
.../ruby/1.8/gems/ruote-2.2.0/lib/ruote/worker.rb:75:in `run'
./script/ruote_worker:23
./script/service:107:in `instance_eval'
./script/service:107:in `boot!'
./script/service:38:in `initialize'
./script/ruote_worker:12:in `new'
./script/ruote_worker:12

The mistake was the use of a :unless clause in a :concurrence
expression, as highlighted by the following unit test:
https://gist.github.com/beaefdcc70a718c42ed5

Nesting the :concurrence expression into a :sequence expression and
moving the :unless clause up into the :sequence resolved the problem
(but there were other ways, such as an :if expression).
Probably the issue is documented, but I could not find it.

However, my current problem is with the errors that such situation
raised.
From my business point of view, I resolved with restarting a new
process for any process in error state.
Therefore the processes in error state had to be removed from the
engine.

I tried to kill those processes with
@engine.kill_process(error.wfid)
but that seems to have no effect.

Am i making any mistake?
Can someone suggest me a way to remove definitely the processes?

Thank you
Claudio

John Mettraux

unread,
Apr 20, 2012, 4:57:13 AM4/20/12
to openwfe...@googlegroups.com

On Fri, Apr 20, 2012 at 01:11:39AM -0700, Claudio wrote:
>
> With my team, I am using the wonderful Ruote engine (recently upgraded
> to 2.3.0) in a production environment, with an average of 20 new
> processes created every day.
>
> I recently fixed a bug in a workflow that caused some workitems to
> move into an error condition.
>
> I had the following information about the error:
> message:
> #<NoMethodError: undefined method `size' for nil:NilClass>
> trace:
> /home/rails/apps/arts/shared/bundle/ruby/1.8/gems/ruote-2.2.0/lib/
> ruote/exp/fe_concurrence.rb:286:in `merge_all_workitems'
> .../ruby/1.8/gems/ruote-2.2.0/lib/ruote/exp/fe_concurrence.rb:258:in
> `reply_to_parent'
> .../ruby/1.8/gems/ruote-2.2.0/lib/ruote/exp/flowexpression.rb:228:in
> `do_apply'
> .../ruby/1.8/gems/ruote-2.2.0/lib/ruote/worker.rb:326:in `launch'
>
> The mistake was the use of a :unless clause in a :concurrence
> expression, as highlighted by the following unit test:
> https://gist.github.com/beaefdcc70a718c42ed5
>
> Nesting the :concurrence expression into a :sequence expression and
> moving the :unless clause up into the :sequence resolved the problem
> (but there were other ways, such as an :if expression).
> Probably the issue is documented, but I could not find it.

Hello Claudio,

excellent! I will dig into this issue report. Thanks a lot!


> However, my current problem is with the errors that such situation
> raised.
> From my business point of view, I resolved with restarting a new
> process for any process in error state.
> Therefore the processes in error state had to be removed from the
> engine.
>
> I tried to kill those processes with
> @engine.kill_process(error.wfid)
> but that seems to have no effect.
>
> Am i making any mistake?

No you're doing it right. There is probably something going bad during
the kill operations.


> Can someone suggest me a way to remove definitely the processes?

You could remove all the expressions, schedules and trackers from the storage,
that would effectively vaporize the process instance.

I guess you're using ruote-couch. It would mean removing all the documents
that have a "wfid" => your_wfid or a "fei" => { "wfid" => your_wfid } at
their top level (proceed with caution).

Tell me if you need help with that.

I can probably write a "vaporize" method that works with any storage, tell me
if you're interested. I should write it anyway, it seems a very necessary
tool.


Cheers,

John

Claudio

unread,
Apr 20, 2012, 11:08:33 AM4/20/12
to ruote
Thank you, John

Claudio

unread,
Apr 20, 2012, 11:13:51 AM4/20/12
to ruote
I am interested because I currently need to 'vaporize' 35 processes.
Consider though that Ruote has proven to be really stable, in 2 years
of work I only needed that feature now.

Thank you
Claudio

John Mettraux

unread,
Apr 20, 2012, 9:20:02 PM4/20/12
to openwfe...@googlegroups.com
2012/4/20 John Mettraux <jmet...@gmail.com>:

>
> On Fri, Apr 20, 2012 at 01:11:39AM -0700, Claudio wrote:
>>
>> With my team, I am using the wonderful Ruote engine (recently upgraded
>> to 2.3.0) in a production environment, with an average of 20 new
>> processes created every day.
>>
>> I recently fixed a bug in a workflow that caused some workitems to
>> move into an error condition.
>>
>> I had the following information about the error:
>> message:
>>   #<NoMethodError: undefined method `size' for nil:NilClass>
>> trace:
>>   /home/rails/apps/arts/shared/bundle/ruby/1.8/gems/ruote-2.2.0/lib/
>> ruote/exp/fe_concurrence.rb:286:in `merge_all_workitems'
>>   .../ruby/1.8/gems/ruote-2.2.0/lib/ruote/exp/fe_concurrence.rb:258:in
>> `reply_to_parent'
>>   .../ruby/1.8/gems/ruote-2.2.0/lib/ruote/exp/flowexpression.rb:228:in
>> `do_apply'
>>   .../ruby/1.8/gems/ruote-2.2.0/lib/ruote/worker.rb:326:in `launch'
>>
>> The mistake was the use of a :unless clause in a :concurrence
>> expression, as highlighted by the following unit test:
>> https://gist.github.com/beaefdcc70a718c42ed5
>>
>> Nesting the :concurrence expression into a :sequence expression and
>> moving the :unless clause up into the :sequence resolved the problem
>> (but there were other ways, such as an :if expression).
>> Probably the issue is documented, but I could not find it.
>
> excellent! I will dig into this issue report. Thanks a lot!

Hello,

I think I fixed the issue yesterday while working on different symptoms:

https://github.com/jmettraux/ruote/commit/14e8a835a4ae39b9897641662bb2d1b701c6efad

I updated your gist and it seems to confirm it:

https://gist.github.com/e229de6db40823053797

Please tell me if it's not fixed.

Thanks a ton!

John

John Mettraux

unread,
Apr 22, 2012, 9:08:23 PM4/22/12
to openwfe...@googlegroups.com
2012/4/21 Claudio <cpeta...@gmail.com>:

> I am interested because I currently need to 'vaporize' 35 processes.
> Consider though that Ruote has proven to be really stable, in 2 years
> of work I only needed that feature now.

Ruote alone itself is not stable, your team is also supporting it ;-)

I pushed Ruote::Dashboard#remove_process(wfid):

https://github.com/jmettraux/ruote/commit/9be845973d9525256397e439c7f967c7800d42ce
https://github.com/jmettraux/ruote/commit/c8dfd3627fbaa69232fd21ed86a6f58d64e9b6de
https://github.com/jmettraux/ruote-couch/commit/c2d1192599d3eebc5205388337ee2e0d7c3688ee

Make sure to remove the design document in the "schedules" database of
your couch system before calling this remove_process, else the
schedules registered for your processes won't get removed.

Please tell me if it doesn't work. Thanks and best regards,

John

Reply all
Reply to author
Forward
0 new messages