3 This test evalutes ORB fault tolerance support, based on one of the
4 problems that was reported by the DOORS team at Lucent. The test is
5 aimed at testing the following scenario.
7 1. We will have three copies of the same server running. Let me call
8 them as ref1, ref2 & ref3.
10 2. We will have a manager application which does the following. Hosts
11 a POA with the policies set for a Servant_Locator. Then it creates
12 the reference on that and does the following
14 a. A merged IOR with ref1, ref2 & the reference of the manager
15 b. A merged IOR with ref2, ref3 & the reference of the manager.
17 It publishes/writes the merged IOR from 'a.' in to a file. It uses the IOR
18 created out of 'b' to throw a ForwardRequest exception.
20 3. The client starts by reading the IOR written to a file by the
21 Manager, that was created by 2a. The client basically makes a remote
22 call and a shutdown call on the remote objects in a loop ie. multiple times.
24 a. When the first call is made, the call is responded by the server who published
25 ref1. He is then shutdown.
26 b. On the second call, the call is answered by the server who published ref2. he
27 is also shutdown next.
28 c. On the third call, the call first comes to the preinvoke () method in the
29 Locator class who throws the ForwardRequest exception with the IOR created in
31 d. After the exception is thrown the calls get resolved on the server
32 who published ref3. He is also shutdown next.
34 The above sequence SHOULD be seen to consider the test as being
40 * Start three copies of the server like this
42 $ ./server -o file1.ior
43 $ ./server -o file2.ior
44 $ ./server -o file3.ior
46 * Then start the Manager like this
48 $ ./Manager -a file://file1.ior -b file://file2.ior -c \
49 file://file3.ior -d file4.ior
51 (The above should be on the same line in the command prompt. The
52 file4.ior is for publishing the first merged IOR (refer step 2.a).
54 * The start the client like this
56 $ ./client -o file://file4.ior