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" <j...@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 > > j...@mindspring.com > > _______________________________________________ > > List: Catalyst@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 j...@mindspring.com
pgp7vxJAbvUbO.pgp
Description: PGP signature
_______________________________________________ List: Catalyst@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/
