home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / isis / 312 < prev    next >
Encoding:
Text File  |  1992-11-20  |  4.2 KB  |  90 lines
  1. Newsgroups: comp.sys.isis
  2. Path: sparky!uunet!caen!batcomputer!cornell!ken
  3. From: ken@cs.cornell.edu (Ken Birman)
  4. Subject: How do we test Isis applications
  5. Message-ID: <1992Nov20.151406.10383@cs.cornell.edu>
  6. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7. Date: Fri, 20 Nov 1992 15:14:06 GMT
  8. Lines: 80
  9.  
  10. I am sure people will find this interesting:
  11. > From es_teo@rcvie.co.at Fri Nov 20 05:50:51 1992
  12. > Date: Fri, 20 Nov 92 11:50:46 +0100
  13. > From: es_teo@rcvie.co.at (Dan Teodosiu)
  14. > To: ken@cs.cornell.edu
  15. > Subject: ISIS question
  16. > Cc: es_teo@rcvie.co.at
  17.  
  18. > Dear Dr. Birman,
  19.  
  20.  
  21. > I am currently investigating the possibilities for using ISIS as a basic
  22. > layer for a distributed expert systems environment. While reading your
  23. > papers on ISIS, I was wondering how you perform system testing - do you
  24. > have any environment which allows you to simulate the various conditions
  25. > which may occur (delays, crashes, etc.)? Or do you simply use a number of
  26. > "test applications"?
  27.  
  28. > Kind regards,
  29.  
  30. > Dan Teodosiu
  31.  
  32. > -------------------------------------------------------------------------------
  33. > Alcatel - ELIN Research Centre          RISC (Research Institute for
  34. > A-1210 Wien, Ruthnergasse 1-7                 Symbolic Computation)
  35. >                                         Schloss Hagenberg
  36. > Voice:  +43-1-391621-350                A-4232 Hagenberg i.M.
  37. > Fax:    +43-1-391452
  38. > E-mail: Dan.Teodosiu@rcvie.co.at        E-mail: danteo@risc.uni-linz.ac.at
  39. > -------------------------------------------------------------------
  40.  
  41. To answer your question, let me first assume that you work under Lisp.  We
  42. do have a common lisp version of Isis (Lucid or Allegro), which works
  43. much as you would expect from Lisp -- you can unwind stacks and so
  44. forth, and as much as possible Isis tries to undo whatever it did
  45. in getting to the place where a problem occured.
  46.  
  47. For non-lisp applications, we do a mixture of things.  First, because
  48. the Isis execution environment is so simple ("closely synchronous"),
  49. it is easy to merge logs printed by processes in the system.  So,
  50. debug printouts into log files are very useful -- much more than in
  51. other systems, where you couldn't easily match them up.
  52.  
  53. A second tool is the "cmd snap" feature, which makes an Isis state
  54. dump showing what was happening at that instant in all parts of your
  55. applications.  This lists all the active tasks, what multicasts they
  56. are doing, replies are needed, etc.
  57.  
  58. A third tool is the debugger itself.  However, we have one problem
  59. with the debugger: if you stop an Isis task for long, the system thinks
  60. the program has crashed!  We are adding a "being debugged" option now
  61. but for the next few months Isis will continue to have the feature that
  62. stopping a program for more than about 45 seconds causes it to be
  63. dropped from the system by Isis.  We have to do this to keep the rest of
  64. the system live -- the core problem is that the UNIX debugger doesn't
  65. leave any indication around that we can use to detect that dbx or gdb
  66. has stopped the process, so we have no way to distinguish a dead process
  67. from one in trace-wait.
  68.  
  69. Finally, for testing, we tend to do exhaustive runs (often for days at
  70. a time) with very demanding work loads, to test code coverage.  We are
  71. looking at path coverage tools and we use things like Purify all the time.
  72. By now, we have a large application set and these really put Isis through
  73. a wringer.  A shame we don't have a better way to do it...
  74.  
  75. We have started to add performance tests too, since we recently got burned
  76. by this change in TCP delay functionality which we hadn't noticed, as well
  77. as the Isis bug with "x" mode multicast in overlapping groups.  Of course,
  78. there are an unlimited number of things one might test and we can't cover
  79. everything.  But, we have steadily increased the coverage of our tests for
  80. 18 months now.
  81.  
  82. To simulate crashes, we just kill things.  Some of our test scripts kill
  83. something every second (actually, every <random number of seconds>)  for 2
  84. or 3 days.  We cross our fingers and hope that if we can survive this, we
  85. can survive most realworld situations.  So far, this is usually true.
  86. -- 
  87. Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
  88. 4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
  89. Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
  90.