TAO/orbsvcs/tests/FT_App/README

   1
   2
   3 This is a simple application intended to test Fault Tolerant Corba.
   4
   5 The server implements GenericFactory as a factory that creates TestReplicas.
   6 TestReplicas are defined in the IDL in FT_TestReplica.idl.
   7
   8 FT_TEST::TestReplica inherits from PullMonitorable and Checkpointable
   9 to provide access needed by FT Corba's FaultDetector and Orb.
  10
  11 An FT_TEST::TestReplica contains a long counter.  Methods are defined
  12 to set, increment, and get the value of the counter.  The counter
  13 is also exposed as an attribute named counter.  (i.e. set(x) is
  14 exactly equivalent to counter(x), and get() is exactly equivalent
  15 to counter())
  16
  17 In addition there is a method named die that lets the client request
  18 a server "failure" at a variety of interesting times.  See the "die"
  19 command to find out when death can be scheduled.
  20
  21 The client provides a command interface to operate on the server.
  22 Tests may be run manually by typing commands, or may be automated by
  23 reading the commands from a file.
  24
  25 Commands consist of a single character followed by an optional number
  26 (with no space between).  For example: =10 sets the value of the counter
  27 to 10.  +5 increments the counter by 5 (thereby setting the value to 15).
  28
  29 The '?' commmand lists the possible commands and their options.
  30
  31 Additional programs:
  32  ft_notifier is a stub implementation of a fault notifier for testing fault detectors.
  33  ft_analyzer is a stub implementation of a fault analyzer for testing the fault notifier
  34  ft_registry is an implementation of FactoryRegistry for testing GenericFactories.
  35
  36 To run:
  37 Start one or more FT_Replicas.  Use a -o <filename> to tell the replica
  38 where to write its ior..
  39
  40 Start the FT_Client with -f file1<,filen>...  (i.e. a comma separated list
  41 of replica IOR files.  To read commands from a file, use -c <command file>
  42
  43 The counter is persistent and will survive server failures.  It's
  44 stored in a file named persistent.dat.
  45
  46 Replicas of the server may be run in separate directories to simulate
  47 replicated stateful objects (each replica has its own distinct state), or
  48 multiple replicas can be run in the same directory to simulate a server
  49 with a shared state or one that executes real-world unsafe-to-repeat
  50 action  (i.e. "fire the retro rockets" or "expose the patient to
  51 theraputic radiation.")
  52
  53 Unit Tests based on this application:
  54
  55  run_test_basic.pl
  56     tests ft_client and ft_replica, thereby answering the question,
  57     "who will test the tester?".
  58
  59  run_test_detector.pl
  60     uses ft_client, ft_replica, and ft_notifier (a "stub" fault notifier)
  61     to test the Fault_Detector (from orbsvcs)
  62
  63  run_test_notifier.pl
  64      uses ft_client, ft_replica, Fault_Detector and ft_analyzer (a "stub" fault analyzer)
  65      to test the Fault_Notifier (from orbsvcs)
  66
  67  run_test_fault_consumer.pl
  68      uses ft_client, ft_replica, Fault_Detector, Fault_Notifier to test
  69      ft_fault_consumer (the implementation of a fault consumer)
  70
  71  run_test_registry.pl
  72     uses ft_client, ft_replica, and ft_creator to test ft_registry
  73     (i.e. to test the implementation of PortableServer::FactoryRegistry)
  74
  75  run_test_rmregistry.pl
  76     uses ft_client, ft_replica, and ft_creator to test the FactoryRegistery
  77     implementation in the ReplicationManager.
  78
  79
  80   run_test_rmnotifier.pl
  81     uses ft_client, ft_replica, Fault_Detector to test the connection between
  82     the Fault_Notifier and the ReplicationManager
  83
  84   demo.pl
  85      tests the entire FT system.
  86
  87
  88 See the internal documentation of the .pl files for more details.