ruote tmp/log_2011-07-13.html

2011-07-13 03:41:50 utc kamalfariz I'm using ruote-kit in a Rails app with the default config (it hosts a worker). I have a pdef, and I've registered a participant. I launch the pdef but nothing .. moves
2011-07-13 03:42:01 utc kamalfariz Am I missing something?
2011-07-13 05:45:19 utc jmettraux kamalfariz: hello, nothing moves, not even an error ?
2011-07-13 05:45:54 utc kamalfariz jmettraux: no errors, it just hangs
2011-07-13 05:46:06 utc kamalfariz wait ... how did you see the logs?
2011-07-13 05:46:18 utc jmettraux the process is not started at all ? What does "it hangs" mean ?
2011-07-13 05:46:28 utc jmettraux yes, the channel is logged
2011-07-13 05:46:44 utc jmettraux http://ruote-irclogs.s3.amazonaws.com/logs.html
2011-07-13 05:50:26 utc kamalfariz The RuoteKit.engine.register { catchall } seems to be a problem for me
2011-07-13 05:50:38 utc kamalfariz if i don't have that, things run ok
2011-07-13 05:50:51 utc kamalfariz i register my participants using register_participant
2011-07-13 05:51:07 utc jmettraux ah
2011-07-13 05:51:30 utc jmettraux register { } will clean any previous registered participant
2011-07-13 05:51:37 utc jmettraux previously
2011-07-13 05:52:18 utc kamalfariz it's run earlier though, i only have the register_participant after
2011-07-13 05:52:20 utc kamalfariz let me gist it
2011-07-13 05:52:34 utc jmettraux ah ok
2011-07-13 05:53:31 utc kamalfariz jmettraux: https://gist.github.com/f8cdffb2aa6dccf2d72f
2011-07-13 05:55:14 utc jmettraux catchall being placed before anything else, it will catch everything
2011-07-13 05:55:27 utc jmettraux all your workitems go into the StorageParticipant
2011-07-13 05:55:54 utc jmettraux foo and freeagent are never considered
2011-07-13 05:56:22 utc jmettraux feel free to remove the register { catch_all }
2011-07-13 05:57:06 utc kamalfariz jmettraux: ah ok, i was under the impression that register_participant would prepend to the list
2011-07-13 05:57:09 utc jmettraux if you need it anyway, place a RuoteKit.engine.register_participant(/.+/, Ruote::StorageParticipant) after your participants
2011-07-13 05:57:52 utc jmettraux since your running ruote-kit, always look at /_ruote to see what's happening to your processes
2011-07-13 05:58:16 utc kamalfariz I can't really tell what really going on. It just stays at the first step
2011-07-13 05:58:29 utc kamalfariz where do I look?
2011-07-13 05:59:34 utc jmettraux look at /_ruote/processes
2011-07-13 05:59:38 utc kamalfariz for participants, is it a common pattern to do a switch case on the task params for the same participant?
2011-07-13 05:59:56 utc jmettraux locate your process, follow its link and read the detailed info
2011-07-13 06:00:04 utc jmettraux especially look at "workitems"
2011-07-13 06:00:38 utc jmettraux pattern : yes, I've seen this pattern used quite a lot, sometimes with "task", sometime with "activity"
2011-07-13 06:01:25 utc kamalfariz jmettraux: when should a participant reply with the workitem? is it like rack, where you modify the workitem and want the downstream participants to see the modified workitem?
2011-07-13 06:01:47 utc jmettraux yes, it's a bit like that
2011-07-13 06:01:55 utc jmettraux you reply as soon as you want the flow to resume
2011-07-13 06:02:10 utc jmettraux some participant implementations wait on external information to come
2011-07-13 06:02:31 utc jmettraux and reply when it's available
2011-07-13 06:02:33 utc kamalfariz how do you block on the wait?
2011-07-13 06:02:36 utc kamalfariz ah that makes sense
2011-07-13 06:02:47 utc jmettraux you simply do not reply
2011-07-13 06:03:18 utc kamalfariz but doesn't the default behavior just goes on to the next participant in the pdef?
2011-07-13 06:04:06 utc jmettraux when you participant is something like register_participant :kamal { |wi| wi.fields['msg'] = 'I have to tell this to @mskamal' }
2011-07-13 06:04:12 utc jmettraux the "reply" is implied
2011-07-13 06:04:51 utc jmettraux if you look at the "catchall" you've experienced before, it's wired to Ruote::StorageParticipant, which, upon receiving a workitem, stores it
2011-07-13 06:05:08 utc jmettraux and only replies when the "human/external participant" says it's OK
2011-07-13 06:05:43 utc kamalfariz ah is that what StorageParticipant was waiting for
2011-07-13 06:05:59 utc kamalfariz so BlockParticipant has an implied reply.
2011-07-13 06:06:32 utc jmettraux yes
2011-07-13 06:06:40 utc kamalfariz For participants that wait for external info, is there an interval at which they poll on something?
2011-07-13 06:07:05 utc jmettraux sorry, it's up to you to implement it
2011-07-13 06:07:44 utc jmettraux but you can leverage ruote and tell the engine to poll again for you
2011-07-13 06:08:10 utc jmettraux let me prepare a gist
2011-07-13 06:08:21 utc jmettraux ah wait, let me link you to the doc
2011-07-13 06:08:38 utc kamalfariz thanks!
2011-07-13 06:08:59 utc jmettraux http://ruote.rubyforge.org/implementing_participants.html#re_dispatch
2011-07-13 06:09:19 utc jmettraux in that example, the "re_dispatch" occurs in a rescue
2011-07-13 06:09:31 utc jmettraux but you could totally used it if your initial poll failed
2011-07-13 06:09:57 utc kamalfariz what's the behavior of ruote if let's say you recover from a server restart
2011-07-13 06:10:06 utc jmettraux you can then tell re_dispatch(workitem, :in => '1h')
2011-07-13 06:10:07 utc kamalfariz it scans all processes and attempts to run them again?
2011-07-13 06:10:29 utc jmettraux they should run as is when you restart
2011-07-13 06:11:00 utc jmettraux unless the operation got cut right in the middle
2011-07-13 06:11:26 utc kamalfariz in the re_dispatch case, it puts it on the scheduler, i'm guessing
2011-07-13 06:11:36 utc jmettraux you can "poke" such processes via ruote_kit to "re-awaken" them
2011-07-13 06:11:40 utc jmettraux yes, you're right
2011-07-13 06:12:02 utc jmettraux it writes the re_dispatch order in the scheduler's data
2011-07-13 06:12:30 utc jmettraux if the write was successful, you're safe, else you'll have to poke
2011-07-13 06:13:24 utc jmettraux I'm sorry, I have to go
2011-07-13 06:13:34 utc kamalfariz alright, thanks so much
2011-07-13 06:14:01 utc jmettraux if you have further questions, don't hesitate to abuse the mailing list, or maybe tosch_le will join later (Eurotime)
2011-07-13 06:14:08 utc jmettraux you're welcome !
2011-07-13 06:14:12 utc jmettraux Have fun !
2011-07-13 11:19:34 utc kamalfariz I like how I can inspect the workitem at every step with the StorageParticipant in ruote-kit. Is there a participant that would just silently log at each step, without needing a human to say it's ok?
2011-07-13 11:21:49 utc tosch_le afaik, there is no such participant. but it's really easy to write one.