GNOME Bugzilla – Bug 113405
Stopped tasks can't be requeued in task manager
Last modified: 2004-12-22 21:47:04 UTC
If I have tasks in task manager that are Stopped (stopped by Pan, not manually stopped - manually stopped tasks appear to accept the requeue command), I can select them and click the requeue button, but nothing happens. The only way to get them to requeue is to exit Pan and choose the 'Resume' option when Pan restarts and asks if it should resume tasks that were queued when the last session was ended. These are generally large mulitpart posts (>=10MB). These posts seem to end up at the Stopped state after running into a 'Article not found' for multipart posts. The article is really there, because it will eventually complete the download if I do the requeue enough times. I don't know the reason for the 'Article not found'. It may rear its ugly head itself several times during the course of downloading a large multipart post. But eventually the entire post download will complete. This appears on new posts (a day old or less) as well as posts that are on the 'ragged edge' of being aged-out by my news server (5-7 days old). After some pondering, I think this 'Article not found' thing is a problem with my news server. I guess it is so irritating now because Pan used to handle it more gracefully (seems like it would retry 4 times before giving up, and even then I could requeue it by clicking that requeue button). I may have seen this bug in the list on some previous bugzilla search, but could not find it after several searches today. Sorry if this is a duplicate, but I wanted to make sure it got reported, just in case I imagined the other bug report, or if it was fixed and has reappeared in 0.14.0.
Well, I've certainly coded myself into a corner here. The problem, as I see it, is that when an `article not found' message comes back, the task's state is set to TASK_FAIL_HOPELESS -- meaning it _can't_ be requeued. So, change this from TASK_FAIL_HOPELESS to TASK_NEED_SOCKET and let it try again, right? But then the task will cycle again and again and again until it succeeds, flooding the CPU with its loop. Worse, once the task is set to FAIL_HOPELESS, the NEED_SOCKET state is cleared out -- so we've lost the NEED_SOCKET (and the function pointers & data that go with it) that we need to reset. For the latter problem, maybe the TaskState's state needs to be broken into two separate fields -- what it needs (need_socket, need_work) when it runs, and error states (fail, fail_hopeless) to show whether it can run or not. For the former problem, the short-term fix is to leave it alone as FAIL_HOPELESS and let the user requeue manually via the task manager GUI. In the long run we might want to put in a timer to requeue FAIL (but not FAIL_HOPELESS) tasks after some period of time. But that's a different bug report... TODO: * split TaskState's state field into `work_state' and `error_state' so that we can set things to FAIL without clearing out the info we'd need for a requeue. * In queue's real_requeue_failed_tasks(), clear the task's stae's `error_state' field.
Fixed in CVS: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-state.h&rev1=1.1&rev2=1.2&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-state.c&rev1=1.1&rev2=1.2&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=sockets.h&rev1=1.48&rev2=1.49&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=sockets.c&rev1=1.118&rev2=1.119&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-save.c&rev1=1.40&rev2=1.41&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-post.c&rev1=1.22&rev2=1.23&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-headers.c&rev1=1.147&rev2=1.148&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-grouplist.c&rev1=1.90&rev2=1.91&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-group-count.c&rev1=1.18&rev2=1.19&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-bodies.c&rev1=1.45&rev2=1.46&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan&command=DIFF_FRAMESET&file=task-cancel.c&rev1=1.5&rev2=1.6&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan&command=DIFF_FRAMESET&file=ANNOUNCE.html&rev1=1.180&rev2=1.181&root=/cvs/gnome
*** Bug 118273 has been marked as a duplicate of this bug. ***