On Mon, Jul 12, 2010 at 06:35:53PM -0400, Rich Meyers wrote:
>
> I am trying to use ruote for managing backend processes (as opposed to human
> processes). I think I'm getting the hang of ruote itself but I'm having quite
> a bit of trouble integrating it with the rest of my code.
>
> Specifically, I have the following issues:
>
> 1. Ruote state is a black box. How do I know what workflows are running?
Hello Rich,
engine.processes
Warning, can be a costly operation depending on the storage implementation.
> What is the status of each running workflow?
engine.processes.each { |ps| p ps }
p engine.process(wfid)
> Where is the list of workflows that finished?
Out of the box, there is no such list. Terminated workflows are simply removed.
You can write a history service to log them.
> What is their status?
Terminated and gone.
> Is there an API that will remain stable throughout minor versions that I can
> rely on?
http://ruote.rubyforge.org/rdoc/Ruote/Engine.html
It's been the same for the whole 2.1.x branch.
> 2. Waiting for workflows is not reliable.
Waiting for workflows is used when testing ruote or when showing small
quickstarts.
> Ruote cannot wait for workflows that finish before the wait starts.
This could help (2.1.11) :
http://github.com/jmettraux/ruote/commit/0eb09d354992e27778f87fe64d418632b4281d9c
> This affects short/quick workflows, workflows which fail immediately due to
> user or programmer error, or situations when waiting happens a long time
> after workflow is started because something else is being done in parallel.
See previous comment.
If you launch a workflow and wait for it, why use Ruote ? A simple, classical,
syncrhonous script would be better.
> 3. Ruote does not limit concurrency. If some of my workflows use external
> resources such as downloading files from the internet I don't want an
> unbounded number of these workflows running at once.
Ruby is written in Ruby. When running on MRI (C) Ruby, there is only 1 thread
on at a time. Ruote brings no magic concurrency to the table. For 1 worker,
there is only 1 workflow instance performing something at a time.
You could introduce some limitation in your "downloading files from the
internet" participant by yourself. The engine will be quietly waiting for your
participant's answer.
> My solution so far has been to implement my own tracking of workflows,
> waiting and locking. Since our application is built on rails I have used
> activerecord for persistence.
Do you mean you are using activerecord as the base for a ruote storage
implementation ?
> It seems that activerecord still does not play nice with threads though as my
> ruby (1.8) runtime hangs itself every other time I try to run a workflow now.
> For all practical purposes the application I built is unusable. I have ideas
> how to hack my way out of this mess but I took a step back and asked myself
> why I'm doing all these things in the first place.
Connection pool issues ?
> I considered typical ruote use cases mentioned in the documentation and on
> the mailing list and I suppose when dealing with human processes that are
> persisted externally some or all of these issues do not appear. I'm starting
> to think that ruote works ok for state transitions for objects persisted
> elsewhere but I don't see how it can effectively manage processes that only
> exist in ruote.
Could you please expand on that ? Ruote isn't about state/transitions. I
understand the part "for objects persisted elsewhere", where ruote processes
alter the state of objects, but I don't get the "I don't see how it (ruote) can
effectively manage processes that only exist in ruote".
Thanks for the feedback, best regards,
--
John Mettraux - http://jmettraux.wordpress.com
--
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
