In a prior life I wrote a control process for the FAA that managed a distributed suite. The suite was spread over three sites, 45+ pieces of hardware, 25 communicating apps, 165+ command line arguments and provided near realtime advice to air traffic controllers. Features included near real time sensing of failed hardware and software with automated failover to redundant components. The system needed to be site configurable to support (initially) four regions.
I started by developing a language specific to the problem at hand and implemented this using lex and yacc. For infrastructure I used the Parallel Virtual Machine (PVM) from Oak Ridge National Laboratory, all coding was done in C with user application libraries available in C and C++. Ruby and Rails are fine applications but I would not consider them suitable for any time sensitive application. You could build useful support and analysis tools and you might even be able to build a simulator, but... My guess is that in a distributed monitor and control situation you'ld be looking at sense and respond times in the multi tens of seconds. On Sep 2, 5:52 pm, Frederick Cheung <[email protected]> wrote: > On Sep 2, 7:13 pm, jhaagmans <[email protected]> wrote: > > > > > And how can I make this an ongoing process? I don't want a cronjob- > > powered script, for example. Later on, when there's a lot to query, we > > might move from sending a query once every five seconds to a hundred > > times per second. How to do this? It could also be also time-specific. > > Some database entries only need to be monitored from 8AM to 5PM for > > example. But not all. > > > I hope you can help me with this, as I'm not sure where to start. If > > you tell me to go and learn another programming language that's > > faster, I will. Just be honest. > > To be honest, if you're sending emails, querying remote servers etc. > then you shouldn't be worrying about milliseconds - either of those > two actions could take far longer than that. The smtp server you talk > too could easily sit on your message for seconds or even minutes - > email isn't an instant delivery protocol. Your server-monitory thing > is going to be some sort of background process, you may find a single > instance of that gets more done if you're using something like jruby > that has better threading than normal ruby. Stuff like eventmachine is > pretty cool for having a single process multiplex a lot of IO. > > Fred > > > Thank you very much. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
