1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
$Id$
This test involves a multithreaded client. The purpose of the test is
to verify that client-side and server-side RTCORBA processing works ok
when multiple threads are making invocations.
NOTE:
-----
Since output verification script relies on ORB debug messages, i.e.,
it checks for certain debug messages, it is BRITTLE. Whenever ORB
developers modify/remove certain debug messages in the ORB, the output
verification script may start reporting that there is an error, since
something it was looking for was not found. In such case,
process-output.pl must be updated to reflect debug output changes.
Description
-----------
Server creates a POA threadpool with lanes (until POA threadpools are
fully supported, this is emulated with global threadpools), creates an
object with RTCORBA::CLIENT_PROPAGATED priority model, and writes its
IOR to the file.
Client spawns two threads of different priorities. Each thread sets
RTCORBA::ClientProtocolPolicy override to a single protocol on the
PolicyCurrent level. After setting the override, each thread performs
a number of invocations on the server object in a loop. The number of
invocations, each thread's priority and protocol are all specified
through command-line arguments.
This test consists of two parts. In the first, we run client and
server, which follow the description above. We also turn on the
debugging output for the server, and collect the entire test output
(client and server) into a data file. The second part of the test is
verifying the output of the test using process-output.pl perl script.
(The perl script is used since a large number of iterations results in
a sizeable output, which is impractical to verify manually).
run_test.pl does both, i.e., it runs client and server and then runs
the verification script on the output. Below are instructions on how
to run both client/server and the verification script.
To run (on Unix):
-------
$./server [-o <ior_output_file>]
-ORBdebuglevel 1 -ORBSvcConf server.conf
-ORBendpoint iiop://targethost:0/priority=<priority1>
-ORBendpoint iiop://targethost:0/priority=<priority2>
-ORBendpoint shmiop://targethost:0/priority=<priority1>
-ORBendpoint shmiop://targethost:0/priority=<priority2>
[more endpoints if desired]
$./client [-o <ior> -n <iterations>]
-a <client_priority1> -b <client_priority2>
[-e <protocol_id1> -f <protocol_id2>]
To run output verification script:
$./process-output.pl <data-file-name>
<number-of-iterations>
<priority1>
<priority2>
where
<data_file_name> is the name of the file where output from running
server and client was collected
<number_of_iterations> number of iterations specified to the client
with -n command-line option
<priority1> priority for the first client thread (was specified to the
client with -a command-line option)
<priority2> priority for the second client thread (was specified to the
client with -a command-line option)
Note: Verification script is currently hardcoded to assume that
protocol used for one of the threads is iiop, and for the other
is shmiop.
Options:
--------
Server:
-o <ior_output_file> Default: test.ior
Filename for output of object's IOR.
-ORBdebuglevel 1 Default: none
This ORB option should be supplied to the
server in order to obtain ORB debug output,
which can then be verified with
process-output.pl for correctness.
The following are the required server ORB options for this test.
These options help set up server resources to emulate POA
threadpool with ORB pool. Once POA threadpools are implemented, these
options will go away.
-ORBSvcConf server.conf
-ORBendpoint xxx://targethost:0/priority=<priority1>
-ORBendpoint xxxx://targethost:0/priority=<priority2>
...
For an example, see run_test.pl
Client:
-o <ior> Default: file://test.ior
IOR for the server object.
-n <n_iterations> Default: 100
Number of invocations each client thread will
make on the server.
-a <client_priority1> Default: -1, must be overridden.
CORBA thread priority of the first client
thread.
-b <client_priority2> Default: -1, must be overridden.
CORBA thread priority of the second client
thread.
-e <profile_id1> Default: 1413566210 (SHMIOP)
Protocol for ClientProtocolPolicy override for
the first client thread.
-f <profile_id2> Default: 0 (IIOP)
Protocol for ClientProtocolPolicy override for
the second client thread.
Expected output:
----------------
If there are no problems, run_test.pl will output
********** MT Client Protocol & CLIENT_PROPAGATED combo Test
Test output is ok
|
