ruote tmp/log_2013-01-28.html

2013-01-28 01:29:16 utc ypz hi, jmettraux
2013-01-28 01:29:29 utc jmettraux ypz: hello
2013-01-28 01:29:38 utc ypz how do I find out if a process is running or stuck ?
2013-01-28 01:30:47 utc ypz i ran engine.processes, then check processes.each {|p| puts p.to_s}
2013-01-28 01:30:52 utc jmettraux well, that's hard
2013-01-28 01:31:24 utc ypz i got output like:
2013-01-28 01:31:27 utc ypz (process_status wfid '20130128-0117-bunozopo-dimumoga', expressions 4, stored_workitems 0, errors 0, schedules 0, trackers 0)
2013-01-28 01:31:33 utc jmettraux because a process waiting for some participant reply looks stuck
2013-01-28 01:32:04 utc jmettraux this process looks alive, it has no error
2013-01-28 01:33:06 utc jmettraux if you're not sure of your participant, you can use a timeout
2013-01-28 01:33:38 utc ypz but the engine eventually timed out due to failure to connect to remote machines, but the process status remains as above
2013-01-28 01:34:15 utc jmettraux do you mean that the ruote engine timed out?
2013-01-28 01:35:05 utc ypz yes, the engine which launched the process timed out with following output:
2013-01-28 01:35:06 utc ypz log/wait_logger.rb:150:in `block in wait_for': waited for ["20130128-0117-bunozopo-dimumoga"], timed out after 60s (Ruote::LoggerTimeout)
2013-01-28 01:35:21 utc jmettraux well
2013-01-28 01:35:28 utc jmettraux the wait_for timed out
2013-01-28 01:35:34 utc jmettraux not the engine
2013-01-28 01:35:59 utc ypz OK, :)
2013-01-28 01:35:59 utc jmettraux are you using that in a test?
2013-01-28 01:37:02 utc ypz no, in my test script, I am still learning the route
2013-01-28 01:37:11 utc jmettraux ok, so this is a test
2013-01-28 01:37:13 utc jmettraux ok
2013-01-28 01:37:16 utc jmettraux my suggestion is
2013-01-28 01:37:28 utc jmettraux wrap your participant code in its own timeout
2013-01-28 01:37:39 utc ypz test script => my prove of concept thingy
2013-01-28 01:37:41 utc jmettraux so that an error is raised when your participant work takes too long
2013-01-28 01:37:58 utc jmettraux that error will place the process [branch] in error
2013-01-28 01:38:49 utc jmettraux so that'll you know what happened
2013-01-28 01:39:18 utc jmettraux wait_for is a testing tool, by default it waits for 60 seconds
2013-01-28 01:39:50 utc jmettraux it doesn't care about workflow running or not, it justs wait for a particular event for 60 seconds
2013-01-28 01:40:04 utc ypz oh, I should not use wait_for in real code ?
2013-01-28 01:40:33 utc jmettraux no, you shouldn't. In fact, you don't need to
2013-01-28 01:42:02 utc ypz OK, if I set a timeout for the participant, and if that participant eventually timed out, it would put its branch in error, do I understand you correctly ?
2013-01-28 01:42:10 utc jmettraux yes
2013-01-28 01:42:43 utc jmettraux if by setting a timeout you mean "using the ruby timeout library", yes
2013-01-28 01:42:59 utc jmettraux a ruote timeout is a bit different
2013-01-28 01:43:15 utc jmettraux in your case, you should first use a ruby timeout
2013-01-28 01:44:04 utc jmettraux
2013-01-28 01:44:13 utc ypz hm, I am getting confused, not sure about the distinction between the two
2013-01-28 01:44:44 utc jmettraux the ruby timeout will raise an error, it is coded in the participant
2013-01-28 01:45:15 utc jmettraux the ruote timeout is set in the process definition (usually), it is soft, it skips the timedout branch by default
2013-01-28 01:47:08 utc ypz so your comment earlier (@5:22pm) refers to ruby timeout, I assume?
2013-01-28 01:49:24 utc jmettraux sorry, my machine's clock is twisted @5:22pm points to nothing for me, could you paste the beginning of the text?
2013-01-28 01:50:17 utc ypz I am referring to line: "jmettraux: if you're not sure of your participant, you can use a timeout"
2013-01-28 01:50:48 utc jmettraux sorry, this was referring to a ruote timeout
2013-01-28 01:52:36 utc ypz I am looking at that link, first example has a :timeout set for a sequence, while the other two examples have :timeout set for participant, are they all route timeout, for for entire sequence while the other two for individual participant?
2013-01-28 01:53:14 utc ypz … one for entire sequence and the other two …
2013-01-28 01:53:38 utc jmettraux they are all ruote timeouts, this :timeout attribute can be applied to any ruote expression
2013-01-28 01:53:58 utc jmettraux it should be thus easy to put timeout on tiny or big process "segments"
2013-01-28 01:54:16 utc ypz I see, thanks for clarifying it
2013-01-28 01:54:36 utc jmettraux concurrence :timeout => "2d" { bob; alice } # where bob and alice have 2 days to finish the job
2013-01-28 01:54:39 utc jmettraux you're welcome
2013-01-28 02:05:16 utc ypz here is another question: if I run engine process in an interactive script, and If I don't use wait_for(wfid), my script exits immediately. Then how should I get outputs from participants?
2013-01-28 02:05:51 utc jmettraux well, that's quite particular
2013-01-28 02:05:59 utc jmettraux I would use wait_for in that case
2013-01-28 02:06:33 utc ypz even when workers running in separate processes, how would get worker output ? always log to a file ?
2013-01-28 02:07:03 utc jmettraux a participant can set fields in the "passing" workitem
2013-01-28 02:07:12 utc jmettraux the next participant may have a look at them
2013-01-28 02:07:18 utc jmettraux the next participants
2013-01-28 02:07:53 utc jmettraux worker output could go in the workitem, it could go to a file and the path/uri/ref to that file goes in the workitem, ...
2013-01-28 02:07:56 utc jmettraux so many possibilities
2013-01-28 02:08:26 utc jmettraux the vanilla use case for those processes is running asynchronously
2013-01-28 02:08:31 utc jmettraux you don't want to wait for them
2013-01-28 02:09:04 utc jmettraux you could use a small interactive script (dashboard + storage, no worker) to launch jobs in your ruote system
2013-01-28 02:09:10 utc jmettraux that script would exit immediately
2013-01-28 02:09:20 utc jmettraux the work would get picked up by the workers
2013-01-28 02:09:58 utc jmettraux maybe this process is generating a pdf, maybe it's updating data in some db, ...
2013-01-28 02:10:13 utc jmettraux maybe it just changed the state of some systems
2013-01-28 02:10:18 utc jmettraux ...
2013-01-28 02:14:33 utc ypz ok, the key concept here is asynchronously, so participants should put its output in predefined locations in a persistent fashion, so that interested parties should check those locations for results
2013-01-28 02:16:13 utc jmettraux yes, or check ruote itself to see if the process (or a branch of the process) ended up in an error
2013-01-28 02:35:07 utc ypz I am still not be able to make a worker (in a separate process) to do a job, here is the worker.rb: , and here is the script to launch the job without a worker:
2013-01-28 02:43:09 utc jmettraux let's begin with something simpler
2013-01-28 02:43:45 utc jmettraux have you seen this thread on the mailing list!topic/openwferu-users/YJXOcA1HOXk ?
2013-01-28 02:44:01 utc jmettraux it contains a launcher / worker example using the file system storage
2013-01-28 02:45:11 utc jmettraux the whole example is at:
2013-01-28 02:45:43 utc jmettraux the camel.rb contains an error, which is fixed in:
2013-01-28 02:46:08 utc jmettraux you can run this example by running a worker, and then, in another terminal, running the launcher
2013-01-28 02:46:25 utc ypz let me look at those
2013-01-28 02:47:18 utc jmettraux your gists are too complicated, you should not play with forking until you can get your code running by simply invoking a worker and a launcher in their own terminals
2013-01-28 02:47:21 utc jmettraux small steps
2013-01-28 02:47:39 utc jmettraux ok
2013-01-28 02:47:52 utc ypz yea, I should start with small steps :)
2013-01-28 02:48:56 utc ypz ok, got to leave for dinner now, thanks a lot for the helps
2013-01-28 02:52:52 utc jmettraux you're welcome, have a good evening!