Thanks Karen. Sorry, I got it.
I read the conversation you've sent. Pretty interesting and the approach
suggested by Russell definitely can work but it will impose others
limitations to me. I need to track the PID of the submitted process. I have
to think more about how to do it with cron.
So, answering, the best I can, what you and Malcolm asked.
The exact line that seems to hang the http response from view "run_aria" is
the line that uses "return os.spawnvp(os.P_NOWAIT,program, (program,) +
args)" in runAria. No matter what the submitted program is (e.g. "sleep
120"), I don't get redirected to status page automatically. However, if "
return #os.spawnvp...", no hangings, but no job.
But runAria is executing and finishing well in less than a second! If I do
this for example:
def run_aria(request):
if not request.user.is_authenticated():
return HttpResponseRedirect('/accounts/login/')
if request.POST:
out = runAria(request)
print out
return HttpResponseRedirect('/status')
else:
return HttpResponseRedirect('/jobs')
>From the terminal:
[19/Dec/2008 09:04:35] "GET /jobs/ HTTP/1.1" 200 2214
start generating output : memops.Implementation.MemopsRoot
project saved
[19/Dec/2008 09:04:47] "POST /jobs/ HTTP/1.1" 200 3316
OK runAria executed 2008-12-19 09:04:50.784417
[19/Dec/2008 09:04:50] "POST /run_aria/ HTTP/1.1" 302 0
[19/Dec/2008 09:06:50] "GET /status HTTP/1.1" 301 0
[19/Dec/2008 09:06:50] "GET /status/ HTTP/1.1" 200 2186
where "OK runAria executed" is the returned from runAria().
Explaining "From the terminal above":
1- [19/Dec/2008 09:04:35] "GET /jobs/ HTTP/1.1" 200 2214
- page with form to upload file.
2- start generating output : memops.Implementation.MemopsRoot
project saved
- file parsed and returned a dict.
3- [19/Dec/2008 09:04:47] "POST /jobs/ HTTP/1.1" 200 3316
- page with a form build with data from dict.
- user select parameters in the form and then "Submit"
4- OK runAria executed 2008-12-19 09:04:50.784417
- printed returned line from runAria almost immediately I click "Submit"
(job was submitted - sleep 120 - in background by os.spawnvp
5,6 - [19/Dec/2008 09:06:50] "GET /status HTTP/1.1" 301 0
[19/Dec/2008 09:06:50] "GET /status/ HTTP/1.1" 200 2186
- page finally redirected (after 120s)
And again, I don't need to wait this 2 min, I can go and click in "Status"
link and get the Status page showing the submitted status job. So, my server
is still ready for response.
I was wondering if it would not be just a limitation of the Django
development web server.
I understand that all this information may be not helpful, but I really
appreciate if any idea of how to improve this debugging. I am out of ideas
now.
Many thanks for your attention.
Cheers,
Alan
On Thu, Dec 18, 2008 at 15:17, Karen Tracey <kmtra...@gmail.com> wrote:
> On Thu, Dec 18, 2008 at 3:36 AM, Alan <alanwil...@gmail.com> wrote:
>
>> Thanks Malcom,
>> I think I was not clear enough. I will try again.
>>
>> So I am at the "Submission Page" (submit.html), with a form where I set
>> some parameters and then I click "submit". This form is linked to action
>> "run_aria" (run_aria.html) defined in views.py as:
>>
>> def run_aria(request):
>>
>> if not request.user.is_authenticated():
>>
>> return HttpResponseRedirect('/accounts/login/')
>>
>> if request.POST:
>>
>> runAria(request)
>>
>> return HttpResponseRedirect('/status')
>>
>> else:
>>
>> return HttpResponseRedirect('/jobs')
>>
>> Once I click "submit", I would expect "run_aria" view to call my external
>> method "runAria"(I have this in views.py: from ccpngrid.src.mainCCPNGrid
>> import handleUploadedCcpnProject, runAria) and then redirect to "Status
>> page" (status.html).
>>
>> What is happening is it does run "runAria" (external application is called
>> and starts working) but then it doesn't redirect to status.html. Instead the
>> submit.html page remains still showing in my browser status bar "Waiting for
>> localhost..." until "runAria" method finishes, which can take hours.
>>
>> However, since my all pages has a common "base.html" with a header with
>> links to "Home" and "Status", if I click in "Status", "Status" page is shown
>> perfectly.
>>
>> So in the end "things" seem to be working but it just doesn't redirect. To
>> add more, if I go in my external method "runAria" and comment out the line
>> invoking "os.spawnvp", redirection works perfectly, but then no job is
>> submitted.
>>
>> I hope it help you to help me. I will test something else meanwhile.
>>
>>
> That doesn't really help...the question Malcolm asked was where, exactly,
> in your runAria function is program execution being held up? That is, which
> line of code in runAria does not complete until the started external program
> finishes? You've already got a commented-out print statement right above
> the os.spawnvp call so presumably you've confirmed that P_NOWAIT is in fact
> being used on the call? Have you confirmed via a print statement that as a
> result the os.spawnvp call then does in fact return immediately vs. blocking
> until the spawned program has finished? If yes, then move on through the
> processing in runAria adding print statements until you find the line of
> code that is causing the delay, and then the question becomes why is that
> particular line of code not returning vs. why is this function about which
> we on the mailing list know only bits and pieces not returning? We're much
> more likely to be able to help with the specific line of code question.
>
> You might also want to review this recent list conversation:
>
>
> http://groups.google.com/group/django-users/browse_thread/thread/f3d8e863929f626b#
>
> about doing long-running processing in a view. I have a feeling the "in
> the view, simply add something to a job queue that is processed by a
> completely external process" approach is really better for what you are
> doing, but I have not had to do this sort of thing myself so I can't be 100%
> sure of that. If, though, your "where exactly is the clode blocking"
> determination comes up with the answer that it is not in fact blocking
> anywhere in runAria but rather somewhere after your return from your view,
> I'd be guessing you need to be using the job queue approach instead of
> spawning the external process from the view itself.
>
> Karen
>
> >
>
--
Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate
Department of Biochemistry, University of Cambridge.
80 Tennis Court Road, Cambridge CB2 1GA, UK.
>>http://www.bio.cam.ac.uk/~awd28<<
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
