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 354779 - PAN no longer attempts to reconnect
PAN no longer attempts to reconnect
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other All
: Normal normal
: 1.0
Assigned To: Charles Kerr
Pan QA Team
: 357474 374807 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-09-07 14:46 UTC by Jason Auvenshine
Modified: 2007-01-24 17:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jason Auvenshine 2006-09-07 14:46:07 UTC
Please describe the problem:
I upgraded from 0.109 to 0.111 and noticed that if PAN initially fails to connect to my news server it does not retry periodically.  Falling back to 0.109 confirms that reconnect in that version works.

Steps to reproduce:
1. Open PAN 0.111 pointing to a news server that is not currently accepting connections (too many connections)
2. Observe in lower-left corner "No Connections" does not periodically show "Connecting".
3. Open PAN 0.109 pointing to the same server and it will periodically show "Connecting" until a connection can be obtained.


Actual results:
In PAN 0.111, you can't get a connection on a busy server unless you luck out on the first try.

Expected results:
I would expect to have the connection retried until successful.

Does this happen every time?
Yes

Other information:
No
Comment 1 Charles Kerr 2006-09-07 15:46:30 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 353486 ***
Comment 2 Jason Auvenshine 2006-09-12 03:10:26 UTC
I think this may be something different.  I just downloaded PAN 0.112, in which bug 353486 is listed as fixed, and I still have the problem.  Of note also is that this problem happens immediately -- it does not take a while.  I open PAN and if it fails to connect on the first attempt, it stays at "no connections" forever, instead of periodically retrying the connection as in 0.109.
Comment 3 Charles Kerr 2006-09-12 05:04:27 UTC
Okay.  thanks for the correction.
Comment 4 Charles Kerr 2006-11-13 19:44:38 UTC
*** Bug 357474 has been marked as a duplicate of this bug. ***
Comment 5 Charles Kerr 2006-11-13 19:45:27 UTC
*** Bug 374807 has been marked as a duplicate of this bug. ***
Comment 6 John Aldrich 2006-11-13 20:44:32 UTC
Please note that this is still a problem in Pan-0.118
Comment 7 Charles Kerr 2007-01-24 16:57:10 UTC
This appears to be a side-effect of the fix to bug #352170, that stopped
the queue from eating too many cpu cycles when there were too many tasks...
Comment 8 Charles Kerr 2007-01-24 17:20:05 UTC
This appears to be a side-effect of the fix to bug #352170, that stopped
the queue from eating too many cpu cycles when there were too many tasks.

Fixed in svn revision 123.

Index: ChangeLog
===================================================================
--- ChangeLog   (revision 122)
+++ ChangeLog   (working copy)
@@ -7,6 +7,7 @@
  400026 spurious error messages when decoding articles w/o attachments (Pavel)
  361603 translatability problems for message strings (Flammie Pirinen)
  307028 editor error: cursor positioning on indented lines (Richard Rasker)
+ 354779 pan no longer attempts to reconnect (Jason Auvenshine)

 0.121 "Dortmunder"
  390784 crash when dragging over URL (Paul Williamson)
Index: pan/tasks/queue.cc
===================================================================
--- pan/tasks/queue.cc  (revision 118)
+++ pan/tasks/queue.cc  (working copy)
@@ -112,6 +112,19 @@
     _last_time_saved = now;
   }

+  // do upkeep on the first queued task.
+  // the CPU goes crazy if we run upkeep on _all_ queued tasks,
+  // but we need to run upkeep on at least one queued task
+  // to kickstart the queue if it's gotten stuck from a bad connection.
+  // ref #352170, #354779
+  foreach_const (tasks_t, tmp, it) {
+    Task * task (*it);
+    if (task->get_state()._work == Task::NEED_NNTP) {
+      process_task (task);
+      break;
+    }
+  }
+
   // remove completed tasks.
   foreach_const (tasks_t, tmp, it) {
     Task * task  (*it);