Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#21525 closed Bug (invalid)

built in manage.py runserver waits for all content to download before html load attempt, bug?

Reported by: radzhome@… Owned by: nobody
Component: Uncategorized Version: 1.6
Severity: Normal Keywords: runserver
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hi,

I am not sure if this is a bug or not or if it is a feature that would need to be added. I basically have a view that loads its images from another view. The other view generates images and passes them as an HTTPResponse object. I am using a bootstrap "loading" bar while these images load and this works great on production using nginx web server. Now when I use runserver, which is great for debugging, the behaviour in this case is a bit different. Instead of loading what it can it waits for all the images to be generated before displaying the page. Can this be fixed so the page is loaded without waiting for the images to download / generate first?

{# js for loading bar #}
{% block page_js %} {# runserver doesn't handle page refresh same way, this will show for shorter period #}

{{ form.media }}

<script>
$(function() {$('#graphs').hide();})

$(window).load(function() {

show();

});

function show() {

$('#loading').hide();
$('#graphs').fadeIn();

};
</script>

{% endblock %}

{# no data here because extends the home.html template #}

{% block content %}

<div class="loading span3" id="loading"> <!-- this is what should be shown while images are loading, instead runserver will wait till image generation is done before displaying the page -->

<h3>Generating graphs...</h3>
<div class="progress progress-striped active">

<div class="bar"></div>

</div>

</div>
<div id="graphs">


<img src="{% url 'loc_key_png' location.id key %}" alt="{{ key }}"> {# graph generating function returns http response with content as png #}


<img src="{% url 'loc_key_png' location.id key %}?yesterdays" alt="{{ key }}"> {# same thing #}

</div>


{% endblock %}

Easy to replicate this one, just have the png generation function return anything , just add a delay on it to return after x seconds:
from time import sleep
sleep(3)

Change History (6)

comment:1 by anonymous, 10 years ago

comment:2 by anonymous, 10 years ago

#test function, use in any view, load up any image into HTTP response object, sleep for 5 seconds (graph generation delay)
def location_key_png(request, location_id=None, key=None):

import os
response = HttpResponse(mimetype='image/png')
with open(os.path.join(STATIC_ROOT, 'images', 'warning_yellow.png')) as img: #warning_black

response.write(img.read())

from time import sleep
sleep(5)

return response

comment:3 by Tim Graham, 10 years ago

The first thing that comes to mind is that the development server wasn't multi-threaded prior to 1.4 -- what version are you using?

Second, it would be helpful if you could do some more investigation yourself and try to figure out what's blocking the page from returning. If you can't do that, please put together a sample project we can download and take a look at.

comment:4 by Aymeric Augustin, 10 years ago

Resolution: needsinfo
Status: newclosed

I understand that you're seeing sligtly different behavior, but I don't understand exactly the nature of this difference. It could be something as low level as the way the server handles socket connection; since Django relies on Python's stdlib this is outside of our control.

I'm going to mark the ticket as needing more information. As noted by Tim, your best chance to have someone look at this problem is to provide a minimal example demonstrating it and a patch fixing it.

comment:5 by anonymous, 10 years ago

I will build a small project for this hopefully tomorrow. It feels like its not multi-threaded but I am using 1.6

comment:6 by anonymous, 10 years ago

Resolution: needsinfoinvalid

I reboot my mac and was unable to reproduce the issue, it seemed to be related to my system config.

Note: See TracTickets for help on using tickets.
Back to Top