On 3/2/06, Michael Koziarski <[EMAIL PROTECTED]> wrote: > On 3/2/06, Jon Tirsen <[EMAIL PROTECTED]> wrote: > > I'm working on the plugin for RBatis and a new little thing I'm toying > > around with called ActiveMessaging (sorry, David I stole the name from > > you from the TW AwayDay ;-)). Anyway, in both these applications I > > want to be able to have reloadable classes that don't extend any of > > the standard built in ones. > > Please give more info on this 'Active Messaging', we're currently > evaluating some options for reliable async messaging for Joyent, > perhaps we can avoid duplicating effor.
I've just started playing with this but it works something like this: messaging.yml sets up connections to messaging infrastructure per environment (think database.yml). subscriptions.rb enlists what queues you're interested in and what processor should process messages from what queue (think routes.rb). You start one or more poller.rb which does a "receive" on the connection and blocks until a new message comes in, sends it off to the processor (through Dispatcher). Only one message is processed at a time in the poller.rb process, if you want more throughput start another poller.rb. (Threads suck!) There's a bit of an adapter framework to potentially support multiple messaging infrastructures. Currently supports STOMP (gem install stomp) which is a lightweight protocol supported by ActiveMQ (activemq.codehaus.org). It works *amazingly* well for being a Java product. ;-) Download the .zip, unzip, uncomment STOMP listener in conf/activemq.xml, start bin/activemq, done! An IBM MQ Series adapter should be relatively easy to implement on top of the XMS C api, this would make it dead easy to build Rails apps on top of sucky mainframes. Also for the purist it should be really easy to implement a lightweight messaging implementation on top of ActiveRecord. This would likely primarily be for intra-application messaging, but would enable async processing without taking up a FastCGI process such as credit card processing and so on. It's not rocket science but nice, easy and relatively Railsesque. > Which is why we ripped it out a few weeks ago :) Ha! Suits me for not being on edge! :-) > def reset_application! > Dependencies.clear > ActiveRecord::Base.reset_subclasses > Class.remove_class(*Reloadable.reloadable_classes) > end > > Plus, see reloadable.rb in ActiveSupprt. Does this give you the > flexibility you need, or is there still a need for a more generic hook > into the 'reset' code?. It is probably enough for ActiveMessaging as I'm not doing clever stuff like ActiveRecord there. For RBatis it might not be as I might need to do something to clean out old SQL statements before reloading. Not sure. I will investigate and get back to you. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
