HMM, the processes are very fast and never take long. maybe 5 seconds,
but most of the time 1 or 2 seconds. Do I really need create a queing
server for this? It's going to be a lot of database reading to make it
happen smoothly.
BR,
Jason Brower

On Tue, 2014-02-04 at 07:05 -0800, Niphlod wrote:
> that's the problem!!! 
> Running external programs within the webserver execution model causes
> the thread to be killed if the request takes too much.
> It's process handling 101: NEVER spawn processes from the web
> application!
> 
> On Monday, February 3, 2014 10:06:32 PM UTC+1, Encompass solutions
> wrote:
>         Thanks for the pointers! 
>         I run two programs... avconv (ffmpeg) and sox both handle
>         file 
>         conversions at the moment an upload happens. They bail pretty
>         easily if 
>         there was an error.  They are using files I have stored
>         according to my 
>         model. 
>         BR, 
>         Jason Brower 
>         
>         On Mon, 2014-02-03 at 19:08 +0000, Ricardo Pedroso wrote: 
>         > 
>         > On Sun, Feb 2, 2014 at 6:14 PM, Jason Brower
>         <enco...@gmail.com> 
>         > wrote: 
>         > 
>         >         It seems that I have an issue I can't resolve. 
>         >         Every once in a while at seemingly the worst and
>         most random 
>         >         times, the 
>         >         service will stall out.  It simply doesn't respond
>         to 
>         >         anything. 
>         >         Going into the computer and running htop shows that
>         the 
>         >         computer is 
>         >         doing nothing. 
>         >         I am not running the server with a compiled version
>         of my 
>         >         code. 
>         >         I am running: 
>         >         2.8.2-stable+timestamp.2013.11.28.13.54.07 
>         >         (Running on Apache/2.2.22 (Ubuntu), Python 2.7.3) 
>         >         The application does only basic uploading and
>         loading of a 
>         >         single item. 
>         >         Here is an example of the webplayer: 
>         >
>         
> melodigram.com/melodigram/default/gram/b662a1da-8c2b-11e3-b0dc-1231390a0101 
>         > 
>         >   
>         >         I can run F5 reloads on the site for 15 minutes
>         straight, not 
>         >         have 
>         >         anyone access the system then then try to load
>         something, be 
>         >         it the 
>         >         admin interface or the page I show you here and it
>         site for a 
>         >         very long 
>         >         time.  The time it is unresponsive seems random, but
>         that's 
>         >         because I 
>         >         haven't discovered how to replicate the problem. 
>         >         If I restart apache and try, it seems to work every
>         time. 
>         > 
>         > 
>         > This king of issues are hard to know exactly, where the
>         problem is, 
>         > without having a clear picture of the application and the 
>         > infrastructure. 
>         > 
>         > 
>         > For sure, something is holding apache worker threads for a
>         long time 
>         > or indefinitely. 
>         > 
>         > 
>         > when a request for 
>         >
>         
> melodigram.com/melodigram/default/gram/b662a1da-8c2b-11e3-b0dc-1231390a0101 
>         > 
>         > is running: 
>         > 
>         > 
>         > Are you using any third party C extension? 
>         > 
>         > 
>         > Are you calling any external program? 
>         > 
>         > 
>         > Where are the files, that are retrieved by the download
>         function, 
>         > stored? In the same 
>         > box, or been retrieved from a remote location? 
>         > 
>         > 
>         > the first thing I would try is using strace utility against
>         an apache 
>         > worker thread to see 
>         > 
>         > were it is sitting. 
>         > 
>         > 
>         > Ricardo 
>         > 
>         > -- 
>         > Resources: 
>         > - http://web2py.com 
>         > - http://web2py.com/book (Documentation) 
>         > - http://github.com/web2py/web2py (Source code) 
>         > - https://code.google.com/p/web2py/issues/list (Report
>         Issues) 
>         > --- 
>         > You received this message because you are subscribed to a
>         topic in the 
>         > Google Groups "web2py-users" group. 
>         > To unsubscribe from this topic, visit 
>         >
>         https://groups.google.com/d/topic/web2py/BZQF88jug54/unsubscribe. 
>         > To unsubscribe from this group and all its topics, send an
>         email to 
>         > web2py+un...@googlegroups.com. 
>         > For more options, visit
>         https://groups.google.com/groups/opt_out. 
>         
>         
> -- 
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> --- 
> You received this message because you are subscribed to a topic in the
> Google Groups "web2py-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/web2py/BZQF88jug54/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to