Re: [Catalyst] working around request timeouts

2012-08-21 Thread Sergey Dmitriev
Agree. I assumed that client code can be changed to use queue tickets
instead of long-time requests, which isn't good anyway.

2012/8/21 Bill Moseley mose...@hank.org



 On Mon, Aug 20, 2012 at 12:10 PM, Sergey Dmitriev 
 sergey.program...@gmail.com wrote:

 Looks like what you need is the job queue. Take a look at

 Queue::DBI (https://metacpan.org/module/Queue::DBI) - simpler
 TheSchwartz (https://metacpan.org/module/TheSchwartz)


 Yes, and what about long polling?  Would that solve the ajax request
 timing out?  That is, have your client code get sent a message when the
 backend is done instead of waiting.




 Sergey

 2012/8/20 James R. Leu j...@mindspring.com

  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/



 ___
 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/




 --
 Bill Moseley
 mose...@hank.org

 ___
 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/


___
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/


Re: [Catalyst] working around request timeouts

2012-08-21 Thread James R. Leu
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/


Re: [Catalyst] working around request timeouts

2012-08-21 Thread Tomas Doran

On 21 Aug 2012, at 17:54, James R. Leu wrote:

 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.

Why? I mean, you need very minimal info here - you need to persist a 'work to 
do' thing to the DB, just log that to a message queue (where something picks it 
up later).. The message is very minimal, like { type = Job::FooBar, id = 
 }

Much simpler and easier + lower coupling - the stuff that implements the job 
can change independently of the app.

Cheers
t0m


___
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/


Re: [Catalyst] working around request timeouts

2012-08-20 Thread Sergey Dmitriev
Looks like what you need is the job queue. Take a look at

Queue::DBI (https://metacpan.org/module/Queue::DBI) - simpler
TheSchwartz (https://metacpan.org/module/TheSchwartz)

Sergey

2012/8/20 James R. Leu j...@mindspring.com

 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/


___
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/


Re: [Catalyst] working around request timeouts

2012-08-20 Thread Chakkit Ngamsom
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/

___
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/


Re: [Catalyst] working around request timeouts

2012-08-20 Thread Bill Moseley
On Mon, Aug 20, 2012 at 12:10 PM, Sergey Dmitriev 
sergey.program...@gmail.com wrote:

 Looks like what you need is the job queue. Take a look at

 Queue::DBI (https://metacpan.org/module/Queue::DBI) - simpler
 TheSchwartz (https://metacpan.org/module/TheSchwartz)


Yes, and what about long polling?  Would that solve the ajax request timing
out?  That is, have your client code get sent a message when the backend is
done instead of waiting.




 Sergey

 2012/8/20 James R. Leu j...@mindspring.com

  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/



 ___
 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/




-- 
Bill Moseley
mose...@hank.org
___
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/