[Catalyst] working around request timeouts

James R. Leu jleu at mindspring.com
Tue Aug 21 15:54:38 GMT 2012


Chakkit et. al.

Catalyst::Plugin::RunAfterRequest ended up being the easiest first step.
Thank you Chakkit, for the suggestion.

Now that I have this implemented I'm seeing why a work queue system
is needed if this fix needs to be more then an interim solution.
I quickly use up all the child processes, and simply adding more children
process will not scale.

My thought is to implement a hybrid work queue Run after Request (RaR)
system.  Where the work queue contains the closures that would
normally be handed to RaR.  Each handler would submit jobs (RaR closures)
to the work queue.  Then I would implement a RaR in the Root controller
that would process the jobs.  As long I keep a running tally of
the number of children processing jobs I could make sure to keep
some number of children available to run handlers that submit more jobs
to the work queue or answer requests for job status.

Although that might be more complicated then it is worth.  I'd better get
back to:
a) fixing the database
b) implementing a NoSQL caching system

If I only knew which of those paths leads to the pot of gold ....

On Tue, Aug 21, 2012 at 02:20:23AM +0700, Chakkit Ngamsom wrote:
> Hi James,
> 
> Have you try RunAfterRequest Plugin?
> 
> http://search.cpan.org/~flora/Catalyst-Plugin-RunAfterRequest-0.04/lib/Catalyst/Plugin/RunAfterRequest.pm
> 
> Regards,
> Chakkit
> 
> On Aug 21, 2012, at 12:07 AM, "James R. Leu" <jleu at mindspring.com> wrote:
> 
> > Hello all,
> > 
> > Problem description
> > ===================
> > I have a catalyst application server that responds
> > to 'API' requests for web applications via XHTMLRequests.
> > Sometimes the requests are timing out due to the backend
> > database queries taking too long.  I'm looking for ways to
> > work around this and prevent the 'API' requests from
> > timing out.
> > 
> > I know some of the possible resolutions to this are
> > - fix the queries
> > - fix the database
> > - frontend the RDBMS with NoSQL
> > 
> > I'm working towards those fixes, but they are long
> > term projects, I'm looking for an interim solution.
> > That would notify the web application that it will
> > need to come back later for the response (ie decouple
> > request handling from the actual request/response).
> > 
> > My attempt
> > ==========
> > In my handler I fork a child process.
> > 
> > In the parent I send a response with a
> > 'job id' so the web application knows
> > to poll the 'API' for completion.
> > 
> > In the child I close the IO socket so it cannot send
> > a response and then let it finish processing the
> > request, but it looks like I've lost my database
> > connections so the request fails.
> > 
> > My wish
> > =======
> > What I would like to do is avoid the fork and instead
> > have the handler send an early response to the
> > web application and then finish processing the request
> > and not try to send a response when done.
> > 
> > Is there a common term for what I'm trying to do
> > like continuation or something like that?
> > Has anyone already done this?
> > 
> > Thank you for your time.
> > -- 
> > James R. Leu
> > jleu at mindspring.com
> > _______________________________________________
> > List: Catalyst at lists.scsys.co.uk
> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> > Dev site: http://dev.catalyst.perl.org/


-- 
James R. Leu
jleu at mindspring.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120821/5a2d27f2/attachment.pgp


More information about the Catalyst mailing list