tirsen / activemessaging

ActiveMessaging is an attempt to bring the simplicity and elegance of Rails development to the world of messaging. Messaging, (or event-driven architecture) is widely used for enterprise integration, with frameworks such as Java's JMS, and products such as ActiveMQ, Tibco, IBM MQSeries etc
0 stars 0 forks source link

[FEAUTRE] poller needs option to run in the background #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The poller needs an option to be able to run in the background, and I think 
that it should also move 
to scripts/activemq.  If no one takes on this task by the weekend, I'll create 
a patch and attach it to 
this issue.

Original issue reported on code.google.com by bryanli...@gmail.com on 4 Jan 2007 at 12:16

GoogleCodeExporter commented 9 years ago
couldn't wait till the weekend..

This is what I am using in production today.  

Original comment by bryanli...@gmail.com on 5 Jan 2007 at 2:36

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for contributing this solution.

It's really a good idea - and I also agree that using a rake task to run the 
poller
is less than ideal, easier to have a script to invoke.  On my project, we use
daemontools and handle this through our service run script wrapping the 
poller.rb,
but this is a ice standalone solution.

One thing to think about is that this solution is only good for a single 
instance of
the poller, as it uses a single pid file. So for some (most) cases, it'll be 
great,
but not ideal - so I am wary of adding directly to the code base.

I have a version of the poller (I am also not happy with yet, thus why we are 
using
daemontools) that uses the ruby daemons gem to get some better daemon like 
features,
including start|stop|status|restart semantics, running multiple processes of 
the same
daemon, and having a 'watcher' process that will restart a process if it dies.  
My
only problem at the moment with it is the handling of stdout is banging up some
ActiveRecord logging code - as soon as I figure that out, I'll add it to the 
code, or
if that doesn't work, I'll use something like what you did here.

Original comment by kooks...@gmail.com on 8 Jan 2007 at 5:50

GoogleCodeExporter commented 9 years ago
I agree with the need to run multiple instances of the poller. If I recall 
correctly these processes are in effect 
single-threaded so the only way to process multiple messages at the same time 
and get higher throughput is to 
run multiple copies of the poller.

Original comment by jon.tir...@gmail.com on 9 Jan 2007 at 4:13

GoogleCodeExporter commented 9 years ago
If we need to run multiple versions, maybe someone could come up with a mongrel 
cluster type configuration 
file that allows for specifying how many instances we want to launch.

Original comment by bryanli...@gmail.com on 10 Jan 2007 at 12:52

GoogleCodeExporter commented 9 years ago
hey guys - I just checked in a change to the processor generator, it now 
creates a
'script/poller' script which uses the ruby daemons project, and supports running
mutiple instances simultaneously.  I'll add docs to the wiki on using this - 
proably
not a bad solution, if not as inherently cool as using mogrel :)  let me know 
what
you think, if it is cool, I'll call this fixed.

Original comment by kooks...@gmail.com on 18 Jan 2007 at 7:01

GoogleCodeExporter commented 9 years ago
OK - haven't heard from anyone, but I have been running this successfully on 
mac osx,
and now with the fix to issue 5 on linux, so I am gonna consider this done - the
poller script should do the trick.

Original comment by kooks...@gmail.com on 20 Jan 2007 at 5:10