A lot of applications have a middleware layer. In some ways,
ActiveRecord or Mailer is thought of as a middleware.
But, for example with J2EE, you can run background servers and threads.
Can this be done with Ruby and how?
|
|
0
|
|
|
|
Reply
|
berlin.brown (230)
|
3/15/2006 7:48:57 PM |
|
Berlin Brown wrote:
> A lot of applications have a middleware layer. In some ways,
> ActiveRecord or Mailer is thought of as a middleware.
>
> But, for example with J2EE, you can run background servers and threads.
> Can this be done with Ruby and how?
>
I take the code I need to run separate from rails and set it up as a system daemon. I put all of these in my lib/standalone/
directory. Example:
/var/www/myapp/lib/standalone/report_generator
/etc/init.d/report_generator start|stop|restart
My rails app communications via Unix sockets to my report_generator.
Zach
|
|
0
|
|
|
|
Reply
|
zdennis (552)
|
3/15/2006 8:08:30 PM
|
|
That is interesting. I like that approach. How does the ruby client
code work. Basically, does it timeout or cause a lot of issues.
|
|
0
|
|
|
|
Reply
|
berlin.brown (230)
|
3/15/2006 9:49:48 PM
|
|
Berlin Brown wrote:
> That is interesting. I like that approach. How does the ruby client
> code work.
The client just opens a Socket connection to the server, and sends it instructions. The server takes the instructions, and the
server process creates a new thread and does whatever it needs to do based on instructions. We make the following assumption:
* the server knows how to parse basic instructions so it can load the correct library/worker and pass on worker-specific
instructions to it
* the client understands the format of instructions
> Basically, does it timeout or cause a lot of issues.
A handful of times it was reported that it didn't correctly generate the report for the end user, however, it was hit half a
million times in about 2 weeks and it's hard to prove a handful of times something not working. Although I am investigating. =)
The biggest issue we've seen is memory consumption. We use this tactic for generating CSV reports from a database. Some CSV
reports which include 45,000 or greater (upward of 275,000) records can really suck up the memory. We have avoided this as being a
huge problem by doing two things:
1. beefing up server memory
2. restarting our worker processes (and daemon processes) periodically if memory consumption gets way to high.
There are some changes I am making to my system to fix these initial issues, if interested contact me off list...
Zach
|
|
0
|
|
|
|
Reply
|
zdennis (552)
|
3/23/2006 11:36:01 PM
|
|