home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / isis / 364 < prev    next >
Encoding:
Text File  |  1993-01-07  |  3.2 KB  |  69 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!destroyer!cs.ubc.ca!uw-beaver!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: The "27 day" problem (actually, 21.7 day problem)
  5. Message-ID: <1993Jan7.151550.6171@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. Date: Thu, 7 Jan 1993 15:15:50 GMT
  8. Lines: 59
  9.  
  10. This relates to a previously described bug in V3.0.7:
  11.  
  12.   In V3.0.7 and all previous releases of Isis, there is a bug that
  13.   causes remote connections to get dropped if they are active or
  14.   established any time starting 21.7 days after protos was booted
  15.   on a given node.
  16.  
  17.   For example, say that protos has been up on a host "server2" for
  18.   3 weeks.  You will find that programs running directly on server2
  19.   are fine, as are programs that use the slower UDP connection scheme
  20.   to become remote clients of server2.   But, programs that connect
  21.   to server2 via TCP will disconnect from protos after about 45 seconds,
  22.   thinking that protos has crashed.
  23.  
  24.   In addition to this, it turns out that if protos is very active at
  25.   the instant when this timer wraps, Isis can develop other problems too.
  26.   They would show up by Isis becoming congested and getting stuck in
  27.   a congested state -- basically, an internal garbage collection mechanism
  28.   might freeze up when this timer wraps.
  29.  
  30.   Protos always prints ISIS TIMER RESET in the protos log when it
  31.   tries to wrap this timer.  The problems occur after that.
  32.  
  33. I've tracked down the precise bug and I know how to fix it.  The
  34. fix involves changes to protos/pr_main.c and protos/pr_inter.c,
  35. which then need to be recompiled.  They take effect when protos is
  36. next restarted.
  37.  
  38. Users with an urgent need for this fix can have it via email or FAX.
  39. Contact me if your situation requires this.
  40.  
  41. However, I would prefer, if possible, to have people get this fix as
  42. part of V3.0.8, which is still on target for a release later this month.
  43. My reasoning is based on (bitter) experience: even the most minor fix
  44. can destabilize the system in unexpected ways.  A known problem, however
  45. annoying, is probably better than a patch that hasn't been tested for
  46. several weeks and burned in.
  47.  
  48. Previously, I suggested a second way (other than just rebooting protos
  49. once every few weeks) of disabling the disconnect sensing code.  That
  50. works, too, and if you are using that scheme you can go on doing so
  51. until we release V3.0.8
  52.  
  53. Now that I understand the problem, a third way of fixing it has surfaced.
  54. If your system is such that you can shut down all the remote connections
  55. to a protos server right before it wraps its timer, then restart them
  56. after the message is found in the log, this would also work.  But, having
  57. even one "rtcp" connection to protos at the time of the "wrap" is
  58. enough to trigger the bug.
  59.  
  60. Sorry about this!  I know that it won't look good to have to restart
  61. protos this way, but perhaps it can be worked in with normal T/M
  62. activities to minimize disruption to your users.  After all, you are
  63. safe for 3 weeks at a time.
  64.  
  65. -- 
  66. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  67. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  68. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  69.