On Wed, Aug 01, 2012 at 08:54:38PM +0200, Marco Sehrer [ninjaconcept.com] wrote:
>
> What about a 'priority' feature?
>
> process do
> prepare_someting
> do_something_unimporarant
> cursor prio:1 do
> super_important_job
> end
> end
>
> The idea is this:
> There may be jobs which are not really important at the beginning, but part
> of an workflow, it does not matter how fast they get processed. Then later,
> as soon an workitem reaches a certain 'milestone', it should be processed as
> fast as possible.
>
> Would that be possible to implement?
Hello Marco,
yes, this would be possible somehow. The way I imagine it is:
concurrence do
alice :priority => 1
bob :priority => 2
charly :priority => 3 # default priority maybe
end
"dispatch" messages with priority 1 or 2 would be processed before any other
message ("launch", "apply", ...) Priority 1 would come before priority 2.
This would be a participant only attribute.
A variant on this, one that would be closer to your sketch, would be
concurrence do
sequence :priority => 1 do
# ...
end
sequence :priority => 2 do
# ...
end
end
where "apply" messages are prioritized so sections of workflow would get
priority.
...
Before that I'd prefer to try and implement a thread pool (as described in
https://groups.google.com/d/msg/openwferu-users/xSDFdqp4wws/eXS7OnyEIaUJ ).
I have the impression that the thread pool might speed up things, you seem to
have lots of IO bound participants.
Wdyt?
--
John Mettraux - http://lambda.io/jmettraux
--
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
