| 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 http://ruote.rubyforge.org/common_attributes.html#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 | http://www.ruby-doc.org/stdlib-1.9.3/libdoc/timeout/rdoc/Timeout.html |
| 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 http://ruote.rubyforge.org/common_attributes.html#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: https://gist.github.com/4652387 , and here is the script to launch the job without a worker: https://gist.github.com/4652407 |
| 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 https://groups.google.com/forum/?fromgroups=#!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: https://gist.github.com/4630056 |
| 2013-01-28 02:45:43 utc | jmettraux | the camel.rb contains an error, which is fixed in: https://gist.github.com/4630107 |
| 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! |