On Mon, Aug 22, 2011 at 06:03:35AM -0700, Girardin Yoanne wrote: > > Well, I thought the engines have to share the same storage in order to > dispatch the workitem(s?) to each other.
Hello Yoanne, the workers that share the same storage form a common "engine". If you want engines to dispatch workitems to each other, they have to share their storages via the engine participant. When you declare a engine participant in an engine, you gave it the "coordinates" of the other engine's storage. > The next step is top split the file in 2 : one for the master, one for > the slave > https://gist.github.com/fde55543f8a018373fac > > I launch the slave engine with "ruby slave.rb", and then the master > with "ruby master.rb" > The master continue until its end, but the slave doesn't. > > 6 88 di * emit_results 20110822-hihijere 4353f 0_0 {:wi=>["0_0! > 4353f2522332b61b8ecd32c71d46dddc!20110822-hihijere", 8], > "participant"=>["ResultParticipant", {}], > "participant_name"=>"emit_results"} > 7 88 rc * emit_results 20110822-hihijere 4353f 0_0 {:wi=>["0_0! > 4353f2522332b61b8ecd32c71d46dddc!20110822-hihijere", 7], > "participant_name"=>"emit_results", "receiver"=>"ResultParticipant"} > 8 88 dd * 20110822-hihijere 4353f 0_0 > {"participant_name"=>"emit_results"} > 9 88 re * 20110822-hihijere 10089 0 {:wi=>["0! > 1008905d5e858bcf79e0088443dab087!20110822-hihijere", 7], > "updated_tree"=>nil} > 0 88 re * 20110822-hihijere 3f4eb 0_2 {:wi=>["0! > 1008905d5e858bcf79e0088443dab087!20110822-hihijere", 7], > "updated_tree"=>nil} It works great then. The work starts in the master, gets delegated for a while in the the slave and comes back and terminates in the master. Well done ! > I know the problem comes from the wait_for method; it's the only way > to launch a process as far as I'm aware. Well, "wait_for", as its name should hint at, doesn't launch any processes. It's a testing trick that blocks for a particular local worker event. When that event happens, the waiting Ruby thread is unblocked... In slave.rb, you have to replace "slave.wait_for('emit_results')" by "slave.join". The #join tells your current Ruby thread to join the worker's thread (and never come back). It's probably better if your slave and your master never exit. Especially the slave, it's supposed to serve its master obediently at any time. > Likewise, could you write an example with 1 engine and multiple > workers? https://gist.github.com/1162615 ---8<--- #!/usr/bin/env ruby # multi.rb #$:.unshift('~/w/ruote/lib') #$:.unshift('~/w/ruote-redis/lib') require 'rubygems' require 'yajl' rescue require 'json' require 'rufus-json/automatic' require 'ruote' require 'ruote-redis' class HelloParticipant include Ruote::LocalParticipant def consume(workitem) puts "hello on #{$$} #{Thread.current.object_id} (#{workitem.fields['msg']})" reply_to_engine(workitem) end end engine = Ruote::Engine.new( Ruote::Worker.new( Ruote::Redis::Storage.new( 'host' => '127.0.0.1', 'db' => 12, 'thread_safe' => true, 'engine_id' => 'master'))) #engine.storage.purge! engine.register 'hello', HelloParticipant engine.noisy = true pdef = Ruote.define do 7.times { wait '2s'; hello } end wfid = engine.launch(pdef, 'msg' => 'test0') engine.wait_for(wfid) --->8--- Run this file once in a terminal, until it stops (by itself, thanks to #wait_for). Then run it in multiple terminals, in parallel. Notice how some of the Ruby runtimes don't terminate, they're waiting for ruote processes that terminated in a worker in another Ruby runtime. #wait_for only sees "local" events. Best regards, -- John Mettraux - http://lambda.io/processi -- 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
