TAO/orbsvcs/tests/ImplRepo/servers_interact_on_startup/README

   1 Servers Interacting on Startup Test
   2 ===================================
   3
   4 Description
   5 -----------
   6
   7 This is a test of the implementation repository with various servers
   8 registered with it that interact with each other and may be
   9 ill-behaved (a server reports it is running but there is a delay in
  10 activating the POA). Furthermore, in this test, a server may make an
  11 invocation on another server before the first server's POA is
  12 activated. This results in a stack of ImR server ping requests.
  13
  14 To achieve this there are three servers used:
  15
  16 S1: This server makes an invocation to S2 after its POA has been
  17 created (which includes a notification to the ImR that it is running)
  18 but before the POA has been activated.
  19
  20 S2: This server is similar to S1 but it makes an invocation to S3
  21 after its POA has been created.
  22
  23 S3: The CORBA object for this server waits for awhile before replying
  24 to its request. Because of this it will take awhile for S2's ORB to
  25 start running.
  26
  27 S1 and S2 are both launched by the Activator. S3 is directly spawned
  28 by the test.
  29
  30 Two clients are also used:
  31
  32 C1: Makes an invocation to S1 through the ImR so that S1 will start.
  33
  34 C2: After C1 is started, a wait of the verification interval is made
  35 and then C2 is started and also makes an invocation to S1. The waiting
  36 over the verification interval is done to ensure that the ImR will
  37 ping S1 to verify it is still alive.
  38
  39 In earlier versions of the ImR, the invocation from C2 to S1 would
  40 cause new ping requests to stack on top of the ping requests caused by
  41 C1's invocation to S2 and the original ping requests would be
  42 blocked. If S3's reply delay is long enough it can cause C2 to receive
  43 a TRANSIENT exception. For example, it was found on a Linux computer
  44 that if the request delay was set to 20 seconds ( the value for
  45 -server_reply_delay described below) the C2 would get this
  46 exception. If the delay was set to 30 seconds both C1 and C2 would get
  47 transient exceptions.
  48
  49 Usage
  50 -----
  51
  52 To run this test, run the run_test.pl perl script. It takes two
  53 optional arguments:
  54
  55 -server_reply_delay <seconds>
  56 This is the delay in seconds the CORBA object in S3 will make before replying
  57 to a request.
  58
  59 -v <milliseconds>
  60 The verification interval in milliseconds for the ImR to use.
  61
  62 -?
  63 The usage and default value of the options.
  64
  65 -debug
  66 get debug output from all the processes. The IMR Locator log output is
  67 captured in ./imr_loc.log
  68
  69 -debuglog
  70 All the processes write log output to individual log files
  71
  72 -hide_server
  73 Use this along with the -imr_start option to test an error condition of a
  74 registered server being removed from the filesystem. The tao_imr start
  75 command should recover without hanging.
  76
  77 -imr_start
  78 Use this option to run a simple test where the tao_imr start command is
  79 uesd to launch a server.
  80 This should not time out.
  81
  82 -list
  83 Use the tao_imr list command to test. May be used with or without restarting
  84 the locator.
  85
  86 -restart_loc
  87 Use to bounce the locator process by itself mid test. Only used by the list
  88 test for now.