On Sat, Feb 28, 2009 at 6:32 PM, J B <[email protected]> wrote: > > > On Sat, Feb 28, 2009 at 10:21 AM, John Mettraux <[email protected]>wrote: > >> >> On Sat, Feb 28, 2009 at 11:54 PM, bokmann <[email protected]> wrote: >> > >> > My railsconf talk on Workflow has been accepted: >> > >> > http://en.oreilly.com/rails2009/public/schedule/detail/7535 >> > >> > Hope to see you guys there! >> >> This is great. I especially like the "whole span" approach you're >> taking. Looking forward to see the slides and the video. >> >> If you need any help, please ask. >> >> One major drawback of ruote "on Rails" is that, since it requires >> threads for its workqueue, it can't work on passenger for instance. >> Multi process mongrel packs require tweaking. It's not a big problem >> for small company deployments, but the tendency in the Rails world (as >> you know) is to "scale somehow", so :( > > > Have these drawbacks been detailed in another thread? If not, would you > care to expound on them here? >
Not outside #ruote, and I lost my chat logs recently... What I discussed with John was my concerns over the ruote engine running inside mongrel. We have three scenarios to cope with here: 1) Small app, single mongrel 2) Non-small app, multiple mongrels (single or multiple hosts, doesn't matter) 3) New-kid-on-the-block Passenger deployments The problem will make itself clear when one grasps that only one instance of the engine can be running at any given time. The threading issues might have been resolved (or severely masked) by Rails 2.2.2. The remaining issue is that of a single rufus-scheduler thread that needs to run. In the first scenario, no problem whatsoever. Single mongrel, single scheduler. The second one I'm not too sure on. With some initializer magic you can overcome the multiple scheduler/engine instances problem, but how would you interact with the engine in a mongrel where the engine isn't running? Passenger is out, just because of how it will shutdown your app if it doesn't need to serve requests. OK, problems aside, lets investigate one solution: ruote-rest. As John mentioned, we use ruote-rest to run our processes. Our processes involve a lot of participants (mostly custom made) and some very long running steps in between as well. The processes are mostly used to provision services on our infrastructure (DNS, hosting, mail, internet connectivity, etc). I manipulate the engine completely through httparty-based classes that provide some additional convenience to my apps. I also have my process definitions as ERb files, and they get parsed before sending them to the engine, thus making dynamic participants a breeze. I saw the problems mentioned above immediately, and went for ruote-rest from the word go. I thought it was clear to everyone and didn't want to mention it in fear of looking like a n00b. Seems I was wrong... What we've been discussing in #ruote is that I tackle some cleaning up of ruote-rest to make it more daemon-kit like. You'll have a pre-defined directory structure where you can save your custom configurations and participants and ruote-rest will be loaded from gems or vendor/. This simplifies customizing your own "engine", and simplifies upgrading the components to a simple "rake ruote:freeze" (think Rails) call. I'll also provide a simple ruote-rest-client (name pending) gem that can be used by Rails, or any other Ruby app, to access and manipulate the engine. As for ruote talking back to Rails, no problem, just use the ActiveResourceParticipant ( http://openwferu.rubyforge.org/participants.html#ActiveResourceParticipant) by Torsten. This gives us the following advantages: * Easy deployment outside of your Rails code * Process definitions live inside Rails, not ruote * Easy customization of ruote & ruote-rest environment * Easy upgrade of ruote & rufus libs ... and many more... HTH -- Kenneth Kalmer [email protected] http://opensourcery.co.za --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
