home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / isis / 298 < prev    next >
Encoding:
Text File  |  1992-11-11  |  2.3 KB  |  51 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!caen!batcomputer!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: Re: join never returns
  5. Message-ID: <1992Nov12.012210.29358@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. References: <Af05oZO00hNSI1DYZ2@cs.cmu.edu>
  8. Date: Thu, 12 Nov 1992 01:22:10 GMT
  9. Lines: 40
  10.  
  11. In article <Af05oZO00hNSI1DYZ2@cs.cmu.edu> Sean Levy <snl+@cs.cmu.edu> writes:
  12.   (description of a join problem)
  13.  
  14. I can see from your log that everything is piling up waiting for
  15. replies from one or two of your clients (e.g.: sent to xxxx, status W
  16. means "waiting for a reply from xxxx").  But, lacking logs from
  17. xxxx I don't know why.
  18.  
  19. Some random ideas:  if TCP channel breakage is not always working
  20. right on your systems (and this is a common thing we see on SUN
  21. systems, for example), then if isis_probe isn't set you might have
  22. Isis fail to notice that xxxx is dead and so hang.  But, I bet that
  23. this is not the problem.  V2.2.7 and V3.0.7, at least, would not have
  24. such a problem.
  25.  
  26. Some evidence that your TCP is having trouble is the failure to restart
  27. after shutting down: seems that UNIX is not deallocating the TCP
  28. data structure in the kernel and hence Isis can't reopen it.
  29.  
  30. SUN has problems in this part of TCP in one of their releases a while
  31. back.  If you are on ISIS V2.2.5 on a SUN 4.1.1c platform, for example,
  32. this could explain it.  But, later releases of SUN OS and also of ISIS
  33. (either of them) would probably not have this problem.
  34.  
  35. Another idea: if you try and join multiple groups, say that p joins
  36. A and then B and q joins B and then A.  If they don't call isis_start_done
  37. FIRST, then they can deadlock because p needs to help q on its join
  38. and vice versa.  Would only see this for "concurrent" join situations.
  39. This could explain why adding some extra groups caused the problem --maybe
  40. you did so in a way that introduced a cyclic join pattern?
  41.  
  42. Did you find client-created xxxx.log files after your snapshot?  When
  43. you see protos log files that show people waiting for certain programs
  44. to take an action, the next step is to have a close look at the state
  45. of those programs...
  46.  
  47. -- 
  48. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  49. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  50. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  51.