On Aug 15, 3:12 am, John Mettraux <[email protected]> wrote:
> On Sat, Aug 15, 2009 at 2:51 PM, Rui Ma<[email protected]> wrote:
>
> > I finished a prototype to run ruote engine as a DRb server for multiprocess
> > deployments.
>
> Hello Rui Ma,
>
> you're fast ! Looks very neat.
>
>
>
>
>
> > Ruote-rest is the current way to use ruote engine in a multiprocess
> > environment. But developers need to write code to take care of the
> > underlying communication between models and ruote-rest server.
>
> > A DRb ruote server provides an alternative way to deploy ruote in a
> > multiprocess environment. The primary benefit of using it is that developers
> > can still use ruote as the way of ruote-web2 client code, without
> > adding/chaning client code for multiprocess depolyment.
>
> > Another concern is that using TCP/UNIX socket might be faster than
> > initiating internal HTTP requests in terms of the ruote server/client
> > communications.
>
> > I am not sure either ruote-rest or drb server is thread-safe. Maybe the
> > only way to provide ruote with a thread-safe multiprocess environment is to
> > implement workitem level lock.
>
> Since I'm working on ruote 2.0 and making sure multiprocess
> deployments do not interfere with ruote, I worked on locking access to
> scheduler queues (so that timeouts and such scheduled events get
> triggered on time and only once for the whole pack of engines) and to
> tracker queues (so that a listen expression (not very often used, I
> know) is triggered once for the whole pack of engines).
>
> For workitems themselves, thread-safe measures brought by
> active-record itself should suffice.
>
> > I put together DRb server/client code here:
> >http://github.com/ruima-nyc/ruote-web2
>
> > running it:
>
> > cd ruote-web2
> > ruby script/ruote_server.rb
> > ruby script/server
>
> > Rui Ma
> >http://rui.ma
>
> Well done,
>
> John
Hi,
I'm currently trying to integrate this with my application, which has
custom-written participants that make changes to models in the
application. The participants are defined and registered with the
engine when the Rails application starts up (not when the DRb ruote
instance does). I see the following error when one of these custom
participants is invoked:
undefined method `new' for #<DRb::DRbUnknown:0x114b7b0>
I know that this particular participant never instantiates any new
objects, so I think this might be happening when the participant
itself is being instantiated and passed the workitem by ruote.
Should participants be defined and registered when the engine starts
up instead of the app? How would those participants then access the
application models?
Thanks,
Enrico
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
