modperl and comet?
am 16.04.2010 22:37:44 von E R
I'm interested in adding a Comet capability to a (rather large)
mod-perl application.
To get around XSS limitations, the Comet service will have the same
host and port as the web service. However, I don't want a large
mod-perl process tied up performing the Comet service.
Is there a way that a web request can be passed off to another process
without tying up the Apache process? For instance, can the Apache
process pass the file descriptors for the HTTP connection to another
process which would free itself up for handling the next Apache
request?
Is there another way to implement this?
Thanks,
ER
Re: modperl and comet?
am 16.04.2010 23:51:15 von Octavian Rasnita
From: "E R"
Subject: modperl and comet?
> I'm interested in adding a Comet capability to a (rather large)
> mod-perl application.
>=20
> To get around XSS limitations, the Comet service will have the same
> host and port as the web service. However, I don't want a large
> mod-perl process tied up performing the Comet service.
>=20
> Is there a way that a web request can be passed off to another process
> without tying up the Apache process? For instance, can the Apache
> process pass the file descriptors for the HTTP connection to another
> process which would free itself up for handling the next Apache
> request?
>=20
> Is there another way to implement this?
>=20
> Thanks,
> ER
You can use a very thin front-end Apache reverse proxy or load balancer =
that forwards the requests to one or more back-end Apache servers that =
use mod_perl.
You can set the front-end server to forward the requests to some paths =
to a comet server.
This solution is scalable if the trafic increases.
Read more about the Apache modules mod_proxy and mod_proxy_balancer.
Octavian
Re: modperl and comet?
am 16.04.2010 23:55:04 von wrowe
On 4/16/2010 3:37 PM, E R wrote:
> I'm interested in adding a Comet capability to a (rather large)
> mod-perl application.
>
> To get around XSS limitations, the Comet service will have the same
> host and port as the web service. However, I don't want a large
> mod-perl process tied up performing the Comet service.
>
> Is there a way that a web request can be passed off to another process
> without tying up the Apache process? For instance, can the Apache
> process pass the file descriptors for the HTTP connection to another
> process which would free itself up for handling the next Apache
> request?
That should become a goal of event mpm, but right now event's only purpose
is to unhook the worker between the requests on keepalive connections.
Re: modperl and comet?
am 17.04.2010 00:07:21 von Perrin Harkins
On Fri, Apr 16, 2010 at 4:37 PM, E R wrote:
> Is there a way that a web request can be passed off to another process
> without tying up the Apache process? For instance, can the Apache
> process pass the file descriptors for the HTTP connection to another
> process which would free itself up for handling the next Apache
> request?
It's possible to pass off file descriptors, but then how would you
send more data to the client?
My suggestion would be to write a module for whatever frontend server
you use that holds the connection open and polls mod_perl (or a file
or database or something that mod_perl writes to).
- Perrin
Re: modperl and comet?
am 17.04.2010 11:12:31 von Michael Ludwig
E R schrieb am 16.04.2010 um 15:37:44 (-0500):
[modperl and comet?]
> I'm interested in adding a Comet capability to a (rather large)
> mod-perl application.
>
> To get around XSS limitations, the Comet service will have the
> same host and port as the web service. However, I don't want a
> large mod-perl process tied up performing the Comet service.
>
> Is there a way that a web request can be passed off to another
> process without tying up the Apache process? For instance, can
> the Apache process pass the file descriptors for the HTTP
> connection to another process which would free itself up for
> handling the next Apache request?
I don't know how you could do that. Your mod_perl process could
certainly send the response to a reverse proxy, but then it would
be out of the business of servicing the request.
> Is there another way to implement this?
I'm rather clueless as to how to implement this myself, but it
appears to me (maybe only due to limited knowledge) that unless
you want to have one process tied up to servicing one client, you
need non-blocking IO, like Danga::Socket (basically undocumented),
or AnyEvent, and possibly other modules by Marc Lehmann.
If anyone has ever done any such programming, I'd be curious how
to get started, conceptually.
--
Michael Ludwig