On Apr 4, 4:44 pm, Marcus Weseloh <dja...@weseloh.cc> wrote:
> Hi Malcom,
>
> thanks for your response!
>
> On Sat, 04 Apr 2009 12:21:11 +1100
>
> Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> > You're not really trying to solve a valid problem here. The
> > development server isn't intended for streaming data or anything like
> > that. It's a very simplistic server for basic stuff. So if you're
> > trying to do streaming, you should be using a real web server more or
> > less immediately. During single-person testing/development with the
> > dev server, the periodic EPIPE error is harmless and not worth doing
> > anything about.
>
> It's not really the EPIPE error I'm worried about, I'm just trying to
> utilize that error to prevent my external command from wasting cpu
> cycles by finishing the task, even though the client has already gone
> away.
>
> > Then you'll discover that it's not really a problem you have to worry
> > about. Firstly, because there are a few things inside Django that
> > prevent streaming content from working smoothly and we don't guarantee
> > that sending an iterator to the HttpResponse's __init__ method won't
> > consume the iterator immediately, rather than streaming it.
>
> Ah, ok. Maybe I should explain my ultimate goal: I want to build a very
> simple web service that reacts to GET requests and translates them
> into command-line arguments for the external command. The external
> command does some very heavy lifting and returns a lot of data. I
> would like to stream the returned data to the client and have the
> external command terminate immediately, if the client connection dies.
>
> So do I understand you correctly that I would need to skip Django and
> write my own request handling code to interface with the command?
>
> Bear in mind that I don't need middleware or any of the other niceties
> of Django (like ORM, Admin Interface, templates etc) at this point,
> just the request-view-response code. I just wanted to use Django to
> kick-start the development a bit.
There have been discussions about detection of client connection
closing on the mod_wsgi list before. It is a far from simple problem.
This is because it can only be detected at certain points,
specifically when either reading data from client, or attempting to
write it. If your code is some sort of blocking state, such as waiting
for back end command to do something, this isn't a way you can get a
notification that client has closed connection. Thus the command would
have to do what it needs to first, and only when trying to write back
data would you know. I think the threads on mod_wsgi list about this
are:
http://groups.google.com/group/modwsgi/browse_frm/thread/c8fc824e939de1f9/83526a2c3a26f65d
http://groups.google.com/group/modwsgi/browse_frm/thread/8ebd9aca9d317ac9/4029bfc8c40dd242
Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
