hang when webhost can be reached but does not respond

[GoogleCodeExporter]

This can happen if the website's domain DNS changed and your DNS servers
are not up to date, pointing to a wrong IP address. To reproduce, I think
you could simply point specto to a machine that does not have a web server..?

Proposed solution:
* add a timer when a web watch starts updating itself
* after 10 seconds, if the operation is not completed, cancel it
* log it
* display an "error" icon in the notifier

The big question is, should we schedule a check automatically? We could say
check again in 10 minutes, or we could say that the user has to click the
refresh button? Which would be best?

Original issue reported on code.google.com by nekoh...@gmail.com on 12 Nov 2006 at 9:40

[GoogleCodeExporter]

Original comment by nekoh...@gmail.com on 12 Nov 2006 at 9:44

• Added labels: WatchType-Web

[GoogleCodeExporter]

Original comment by nekoh...@gmail.com on 15 Nov 2006 at 12:07

[GoogleCodeExporter]

Wout, do you think it would possible to "timeout" the operation now that we have
threading? I *think* threads allow us to do that kind of stuff.

Original comment by nekoh...@gmail.com on 17 Dec 2006 at 4:23

[GoogleCodeExporter]

I'd like to see a notification type specifically for this case. Monitoring my 
web
servers with specto would be convenient. Showing a generic error icon isn't
necessarily appropriate here.

Original comment by beer...@gmail.com on 14 Mar 2008 at 5:30

[GoogleCodeExporter]

just curious, why isn't showing an error on a web watch sufficient?

Original comment by nekoh...@gmail.com on 15 Mar 2008 at 12:47

[GoogleCodeExporter]

Specto should notify me of events. An event could be "this web page has been
modified". An event could also be "this web server has stopped responding to 
requests".

In either case I'd like to see a message describing the event.

The fact that specto cannot access a web page, for my needs, is not an 
application
error. It's an event that I want to be notified about.

If network connectivity is required for a specific monitor and dbus is used to
determine that network connectivity has been lost then this _might_ be a case 
where
an application error would be appropriate. That is debateable.

Original comment by beer...@gmail.com on 15 Mar 2008 at 3:27

[GoogleCodeExporter]

you do know that specto does show notifications in case of errors?
however, of course, not in this specific case (timeout) because the logic for
catching it has not been implemented. But would that suffice?

Try pointing it to a 404 for example. 

It should show more information on that regard, however, so I filed issue #117 
about
this.

So, in that perspective, if we catch the timeout problems and such, would web 
watches
be sufficient?

Original comment by nekoh...@gmail.com on 16 Mar 2008 at 12:09

[GoogleCodeExporter]

Actually, I have fixed the issue (needing a timeout mechanism), but due to the
strange corruption of the specto-jeff and specto-woutc dev branches, I can't 
commit
it yet until it is sorted out... regarding that, I am waiting in hope for the 
bzr
guys to figure out what is wrong with our setup
(https://lists.ubuntu.com/archives/bazaar/2008q1/038989.html)

Still awaiting on the feedback from beerfan too.

Original comment by nekoh...@gmail.com on 16 Mar 2008 at 1:24

• Changed state: Started

[GoogleCodeExporter]

Original comment by nekoh...@gmail.com on 18 Mar 2008 at 1:26

• Added labels: Milestone-Release0.3

[GoogleCodeExporter]

Could you apply the patch you have so we can close this issue?

Original comment by woutclym...@gmail.com on 25 Aug 2008 at 7:51

[GoogleCodeExporter]

fix committed to the main branch just now. Do you have any methods for testing 
that
it does indeed work?

Original comment by nekoh...@gmail.com on 26 Aug 2008 at 2:40

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by nekoh...@gmail.com on 10 Mar 2009 at 2:13

• Changed state: Verified