Hi John,
Thanks for your thorough explanation. This will definitely help.
On Saturday, July 28, 2012 5:30:42 PM UTC-5, John Mettraux wrote:
>
>
> Hello,
>
> On Sat, Jul 28, 2012 at 09:39:01AM -0700, emc_lab wrote:
> >
> > Hopefully this is something I am doing wrong. I am using ruote within
> rails
> > 3.1, once I create a new model entry (e.g blog), next I create a new
> > workitem for this blog,
>
> You launch a new process instance related to this blog instance I guess.
>
>
> > then at last (in the same thread), I do (@workitems
> > = RuoteKit.storage_participant.all) to get all outstanding workitems to
> > display them in a form. I notice the list of workitems is always missing
> > the latest new workitem I just added. I think I know that ruote worker
> will
> > spawn new thread to handle this new workitem creation. Is there a way I
> can
> > configure the worker to process this creation within the same thread?
>
> The ruote worker will not spawn a new thread to handle "the new workitem
> creation". The workitem is created in the same thread where you called
> RuoteKit.engine.launch(). The workitem execution is happening in the
> worker's
> own thread which was spawned when the worker was instantiated.
>
> The worker cannot be told to run in the same thread, because well, ruote
> is
> meant to support multiple process instances running in an interleaved way
> (seemingly concurrently), the worker thread executes all the workflows.
>
> If you extend your architecture with multiple workers, your workflow
> execution will even happen in other Ruby runtimes.
>
>
> > or is there a work around? Thanks much for any help.
>
> You could do (if you're using ruote 2.3.0 from github directly)
>
> RuoteKit.engine.wait_for('dispatched')
> @workitems = RuoteKit.storage_participant.all
>
> or something like (any ruote)
>
> sleep 0.350
> @workitems = RuoteKit.storage_participant.all
>
> But none of those two are guaranteed.
>
> The first one will wait for any "dispatched" event, it means that if
> someone,
> in another web requests is creating a blog entry too, the "dispatched"
> might
> be for his workflow, not yours (you won't see the workitem).
>
> The second one will wait for 0.350s, then, the workitem will be part of
> the
> "all", maybe not. If the system is busy, the process of the flow by the
> worker could take more than 0.350s and the workitem won't be seen...
>
> ...
>
> Variants of this question have popped up in this forum quite often. People
> who really needed to be notified immediately of a workitem coming up in a
> workbox usually resorted to things like websockets... server to client
> notifications.
>
> Ruote is meant to do work on its own and then come back to the user via a
> participant (storage participant usually). Forcing ruote in a synchronous
> beat is a bit counter-productive.
>
> Ah, anyway... There is a third way:
>
> 300.times do
> sleep 0.010 # 3 seconds max
> @workitems = RuoteKit.storage_participant.all
> break if @workitems.find { |wi| wi.fields['x'] == 'y' }
> end
>
> Not guaranteed either (if the flow takes more than ~3s to reach the
> storage
> participant) but a bit more precise (we verify via @workitems.find{} that
> the
> workitem is the right one).
>
>
> I hope this will help, best regards,
>
> --
> 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
