You win ;) We're just going to scrap the synchronization with the end-user, and do it later with AJAX push. In the meantime they'll have to rely on email notification and refreshing their browser. There's still an open question on how to best test Ruote while embracing its asynchronicity. Even your tests use wait_for to force synchronization, right?
On Tue, Jun 28, 2011 at 6:53 PM, John Mettraux <[email protected]> wrote: > > On Tue, Jun 28, 2011 at 06:35:56PM -0700, Ian Smith-Heisters wrote: >> >> I'm trying to fix some bugs we're encountering due to our (ab)use of >> notifiers. First, let me say what I understand the state of Ruote's >> message subscription model is, to see if I'm understanding it >> correctly: Ruote notifiers (ie. added with Engine#add_service('foo', >> 'notifiers'...)) are only notified of messages that are processed by >> the worker in their thread/process. In contrast, a pub/sub >> implementation would notify all listeners on the queue, regardless of >> the thread/process they're in. Ruote primarily uses the message queue >> for performing work, and it assumes that it doesn't matter which >> worker processes a message, nor which worker's subscribers are >> notified of the message. Is that correct? > > Hello, > > Yes. > >> This is a problem for us, because we have several worker processes/ >> threads: some are dedicated worker processes, and some are actually >> threads running inside a web service process (Unicorn). We incorrectly >> assume that a notifier listening in one of the web service processes >> will be notified of every Ruote message. But this is the case only if >> the web service's worker happens to be the one that takes the message >> off of the queue. If another worker pulls the message off of the >> queue, the originating process will have no way of being notified of >> the message. The reason we're doing this wackiness is so that we can >> interact with the end user based on the Ruote messages--basically give >> them confirmation of their work. > > Everybody is trying to fall back to a synchronous model. > >> I see a two basic ways to work around this: create a notifier that >> publishes all Ruote messages to something like AMQP so arbitrary >> processes can listen to what's going on "inside" Ruote, thereby >> implementing true pub/sub; or find a way to remove the dependency on >> pushing the messages to the process that is servicing the end user. Is >> there maybe a simpler way I'm overlooking that would use Ruote's built- >> in capabilities? > > You could use rabbitmq and a pub/sub queue for dealing with 'msgs' (and > 'schedules') (instead of the the things provided by your [custom] storage. > > Pushing to a side rabbitmq sounds like less work though. > > "find a way to remove the dependency on pushing the messages to the process > that is servicing the end user"... that process has to subscribe to the side > rabbitmq queue or poll the engine/system. > > I don't know anything about your processes but you could have participants > that emit the "the job is done" notifications for you. > > ---8<--- > sequence do > human :task => 'initiate work' > computer :task => 'do the real work' > notification :msg => 'the real work is done' > end > --->8--- > > Your "controller" would proceed the 'human' workitem, then wait for a > notification coming via 'notification' (or time out somehow). There would be > a shared identifier/token (wfid + something probably). > > Could be equivalent to the "side rabbitmq queue" but with less traffic. > > > Sorry for the fuzzy semi-answers. 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 > -- 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
