deprecating "stateful" participants

7 views
Skip to first unread message

John Mettraux

unread,
Jan 5, 2011, 12:08:44 AM1/5/11
to ruote

Hello list,

I'm thinking about deprecating "stateful" participants, ie participants that are registered as instances instead of as classes.

engine.register_participant 'alice', testParticipant

vs

engine.register_participant 'alice', TestParticipant

There is some explanation about state{ful|less} at

http://ruote.rubyforge.org/implementing_participants.html

but it's light.


Since ruote 2.1.x has potentially multiple workers in different Ruby runtimes, memory is not shared, especially participant and instance variables, and blocks of code (procs). Ruote currently has an exception built in for "stateful participants" registered, it ensures the local worker deals with those participants (well other workers simply can't).


The most common "stateful participant" is the BlockParticipant :

---8<---
engine.register_participant 'alice' do |workitem|
workitem.fields['x'] = y
end
--->8---

as the block only exists in the Ruby runtime where the register_participant is run, workers in other runtimes can't deal with workitems for the alice participant.

the generic "stateful participant" might look like :

---8<---
class MyParticipant
def initialize(opts)
@opts = opts
@seen = []
end
def consume(workitem)
workitem.fields['colour'] = @opts[:colour]
@seen << workitem.fei.to_s
reply_to_engine(workitem)
end
def cancel(fei, flavour)
# do nothing
end
end

red = MyParticipant.new(:colour => 'red')
green = MyParticipant.new(:colour => 'green')

engine.register_participant 'ray', red
engine.register_participant 'greg', green
--->8---

The participant is 'stateful', it keeps a @seen instance variable which is not sharable among Ruby runtimes.

I'd like to deprecate such stateful participants for ruote 2.1.12 and remove support for them completely for ruote 2.1.13.

The right way to implement the above MyParticipant is

---8<---
class MyParticipant
def initialize(opts)
@opts = opts
end
def consume(workitem)
workitem.fields['colour'] = @opts[:colour]
store(workitem.fei.to_s)
reply_to_engine(workitem)
end
def cancel(fei, flavour)
# do nothing
end
def store(info)
open_db(@opts[:db]).store(info)
# some pseudo db lib call
end
end

engine.register_participant 'ray', MyParticipant, :colour => 'red', :db => 'x'
engine.register_participant 'greg', MyParticipant, :colour => 'green', :db => 'x'
--->8---

The options passed at registration must be JSON-serializable so that any worker that has access to the MyParticipant class can instantiate such a participant and hand work to it.


You'll say : right, but how about the block participant ?

I will experiment with "sourcify" and serialize the participant's block

https://github.com/ngty/sourcify

So that the block may travel from one ruby runtime to the next.

I'll certainly put the same security checks I have for Ruby process definitions and ${ruby:execute that code} on the block :

https://github.com/jmettraux/ruote/blob/2669b1886a6419e307bea889842262610f090432/lib/ruote/svc/treechecker.rb#L42-84

There is a catch, closures will not be possible

---8<---
counter = 0

engine.register_participant 'increment' do |workitem|
counter = counter + 1
end
--->8---

Serialized block participants won't take the counter in the fridge (storage) with them.


Any questions/comments/critiques/suggestions/feedback ? Any green lights ?

--
John Mettraux - http://jmettraux.wordpress.com

P.S. I wrote a blog post about switch/case/given and ruote the other day, it's at :

http://jmettraux.wordpress.com/2011/01/03/ruote-and-switch/

Torsten Schönebaum

unread,
Jan 7, 2011, 3:19:13 AM1/7/11
to openwfe...@googlegroups.com
John Mettraux wrote:
> I'm thinking about deprecating "stateful" participants, ie participants
> that are registered as instances instead of as classes.
>
> Any questions/comments/critiques/suggestions/feedback ? Any green
> lights ?

+1 from me. The quickstart will get slightly more complex, but there
won't be the need to explain the difference between stateful and
stateless participants anymore.

Cheers,
Torsten

John Mettraux

unread,
Jan 30, 2011, 1:44:30 AM1/30/11
to openwfe...@googlegroups.com

Hello,

I totally removed support for "instantiated participants".

https://github.com/jmettraux/ruote/commit/80a45f64e77336c42c868e48c938828c50234ca2

BlockParticipants are still OK, but thanks to sourcify, they are turned into a string of Ruby code and placed as in the storage.

I added security checks upon registration and especially right before eval.

https://github.com/jmettraux/ruote/commit/71f6fd361f37575282d4d5842c55e5cf0c9791a7
https://github.com/jmettraux/ruote/commit/9f4b6c91abe716f31a29f60af0a62ca7ebbb3664

The checks are the standard ruote ones.

https://github.com/jmettraux/ruote/blob/18c757020d1b00a215f2d1a1a1e166cf51afd99d/lib/ruote/svc/treechecker.rb

Registering an "instantiated participant" will raise an ArgumentError from now on.

https://github.com/jmettraux/ruote/commit/18c757020d1b00a215f2d1a1a1e166cf51afd99d

I went for the direct removal, since the adaptations are minimal (and block participants are still accepted).

Inconsistencies can be fixed by re-registering the participants.

I'm thinking about releasing 2.1.12 as 2.2.0.

I will now work on the "filter" stuff discussed with Raphael in

http://groups.google.com/group/openwferu-users/t/94f873bd667932dc

If you need any help with this [small] upgrade, feel free to ask here or on IRC.


Cheers,

Reply all
Reply to author
Forward
0 new messages