On Tue, 7 Jan 2003, Chandrasekhar R S wrote:

> Date: Tue, 7 Jan 2003 21:38:57 +0530
> From: Chandrasekhar R S <[EMAIL PROTECTED]>
> To: 'Ken Y. Clark' <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: RE: Query
>
> Hello Ken,
>       You gave me a glimmer of hope and enthusiasm.  I have scanned through the
> recent postings on Mod Perl list in vain.
>
>       I would like to know any such standalone servers that could process the
> perl requests offline (taking requests from a file or queue end).
>
>       I definitely would like to get fancier as my requirement is immediate.
> Upon finding a server that could process the requests away from mod_perl, I
> most probably would modify mod_perl to communicate with the standalone
> servers via sockets (and maybe maintain persistence).
>
> many thanks
> rsr.

RSR,

I really think you're making this harder than it is.  As was pointed
out by another poster, there's nothing about your problem as you've
described it that requires mod_perl.  A simple CGI script could take
your user input, write something to a file or database, and return a
job ID.  A separate Perl script could be launched every 60 seconds by
crond and inspect the file or database for new jobs, process them, and
write the results to another file or update the table.  The user could
then check back later with the original job ID for the results.
There's no need for you to look for "a server that could process the
requests away from mod_perl."  There's nothing wrong with the standard
toolset that Unix already provides.  And I really don't understand why
you want to use sockets.  First just solve your problem using the
simplest solutions.  If you then find things aren't performing to your
expectations, tweak.  Remember:  "Premature optimization is the root
of all evil" (Hoare).

That's just one of many ideas you could use given how little I
actually know about your problem.  As none of what we've talked about
involves mod_perl, I suggest we end this thread.

Best of luck,

ky

> -----Original Message-----
> From: Ken Y. Clark [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 07, 2003 9:02 PM
> To: Chandrasekhar R S
> Cc: [EMAIL PROTECTED]
> Subject: Re: Query
>
>
> On Tue, 7 Jan 2003, Chandrasekhar R S wrote:
>
> > Date: Tue, 7 Jan 2003 12:52:27 +0530
> > From: Chandrasekhar R S <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Query
> >
> > I am having a requirement as follows :
> >
> >     I need to execute/interpret the perl requests away from mod_perl.  Like,
> > could mod_perl delegate the execution/interpretation of perl scripts to
> some
> > other process.  In the end, mod_perl would be used just to accept requests
> > from the Web Server, but processing will be done elsewhere and response
> will
> > be routed back through mod_perl.
> >
> > - rsr.
> >
> > Namaste,
> > R S Chandrasekhar
> > [EMAIL PROTECTED]
> > ISD     : 091-080-2052427
> > Telnet : 847-2427
> > Phone : 2052427
>
> RSR,
>
> You can certainly do something like this, in many different ways.
> This *is* still Perl, you know.  :-)  You could use your mod_perl
> process to update a queue that's in a file or database table, then
> have another process (written in Perl or whatever) executed by a cron
> job to look at the queue and process the next job.  The user could be
> given a token to associate with the job, then then check back later to
> get the results of the job.  If you need it to be more immediate, then
> you'll have to get fancier.  If it's a really long-running process you
> need to kick off, you'll need to take into account the dangers of
> forking your mod_perl process or having it wait around for the end of
> the job.
>
> Have you tried searching the archives for similar questions?  Here's
> one place you can search:
>
>     http://mathforum.org/discussions/epi-search/modperl.html
>
> Namaste,
>
> ky
>

Reply via email to