#9857: URLfield with verify_exists hangs if given an unresponsive URL
-------------------------------+--------------------------------------------
Reporter: aptiko | Owner: nobody
Status: new | Milestone: 1.1
Component: Forms | Version: 1.0
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------+--------------------------------------------
Comment (by trbs):
Couple of comments:
Setting socket.setdefaulttimeout can very easily break or create problems
with other running code depending on socket operations. Since the new
timeout values applies to all newly created socket objects. If we must do
it this way we should consider:
{{{
default_timeout = socket.getdefaulttimeout()
socket.setdefaulttimeout(settings.SOCKET_DEFAULT_TIMEOUT)
... urllib2 code ...
socket.setdefaulttimeout(default_timeout)
}}}
So not to disturb with other socket code. Still when another thread would
use socket code and is executed between the first and second
setdefaulttimeout() the problem still persists. This could be a potential
problem specially for situations where Django runs in a threaded fcgi/wsgi
enviroment ? I would imaging anybody running into a problem where suddenly
his sockets would timeout to quickly would be rather dumbstruck and having
a hard time figuring out why this happens. Specially since before the
first verify_exists everything worked fine, while afterwards stuff started
breaking. Something which could potentially happen in a development vs
production kind of case, where development works fine but production
magically breaks after a while because of the verify_exists check in a
URLField which sets socket defaulttimeout to low. (or too high)
Another point would be that IMO this kind of setting should be
controllable from settings.py although most users would never ever see the
attribute. Having this kind of hard coded (unchangeable) value seems
wrong.
Lastly.. when urlopen() times-out it raises URLError: <urlopen error timed
out> exception. So we should be able to catch that and provide a
meaningful error message, which differs (slightly) from a normal broken-
url and lets the user know the url timed out.
Patch provided but still is not perfect (see threading comment).
--
Ticket URL: <http://code.djangoproject.com/ticket/9857#comment:3>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
