After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 113405 - Stopped tasks can't be requeued in task manager
Stopped tasks can't be requeued in task manager
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
0.13.4
Other Linux
: Normal normal
: 0.14.1
Assigned To: Charles Kerr
Pan QA Team
: 118273 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-05-20 23:44 UTC by Don Horsman
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Don Horsman 2003-05-20 23:44:54 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.
Comment 1 Charles Kerr 2003-07-24 04:43:53 UTC
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.
Comment 2 Charles Kerr 2003-07-24 23:24:20 UTC
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
Comment 3 Charles Kerr 2003-07-25 15:52:24 UTC
*** Bug 118273 has been marked as a duplicate of this bug. ***