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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
|
$Id$
This application tests different features of TAO's Naming Service.
To run all tests automatically -
execute Perl script run_test.pl
To run tests manually -
start the Naming Service (see
TAO/orbsvcs/Naming_Service/README for valid options),
then run ./client with one of the options below.
NOTE: if running tests manually, Naming Service has to be restarted
before each test (this is due to some tests not 'cleaning up' bindings
after themselves).
The following options exist:
---------------------------
-s Run the Simple test of the Naming Service.
-t Run the Tree test of the Naming Service.
-e Run the Exceptions test of the Naming Service
-i Run the Iterator test of the Naming Service.
-y Run the Destroy test of the Naming Service.
-m <n> Run the Multi-Threaded test of the Naming Service (multiple
client threads). Requires integer argument specifying number
of thread to spawn. (If running this test manually, its
output should be redirected to some file, say, "foo". Then,
"process-m-output.pl" script can be used to analyze the test
output and print out a diagnostic message. Invoke the output
processing script like so:
"process-m-output.pl foo number_of_threads",
where <foo> is the name of the file containing test output,
and <number_of_threads> is the argument that was supplied with
"-m" option to the client.)
Example (on a Unix system):
$ ../../Naming_Service &
$ ./client -m 10 >& foo
$ ./process-m-output.pl foo 10
where the steps correspond to 1)starting the Naming Service,
2) running the client and redirecting the output to a file,
and 3) running the diagnostic script.
Don't forget to kill the Naming Service after you are done.
Persistent test consists of two parts (below).
-p <file_name>
Run the Persistent Naming Service test, part 1. Requires an
argument specifying the name of the file in which to store an ior for
use by Persistent Naming Service test, part 2. Note, in order
to test out persistent capabilities of the Naming Service, the
Naming Service must be started with -f and -ORBendpoint options.
The values for these options must be the same for both runs of
the Naming Service (i.e., for part 1 and part 2 of persistent test).
-c <ior>
Run the Persistent Naming Service test, part 2. Requires an
argument specifying the ior, which was produced in part 1 of
the test. Note, in order to test out persistent capabilities
of the Naming Service, the Naming Service must be started with
-f and -ORBendpoint options. The values for these options
must remain the same for both runs of the Naming Service (i.e.,
for part 1 and part 2 of persistent test).
Example of testing persistence on a Unix system:
$ ../../Naming_Service -f log -ORBendpoint iiop://localhost:20000
$ ./client -p ior_file
kill the Naming_Service process
$ ../../Naming_Service -f log -ORBendpoint iiop://localhost:20000
$ ./client -c file://ior_file
where the steps correspond to 1)starting the Naming Service on
port 20000 in persistent mode, with persistent state being
stored in file called "log", 2) running the first part of the
client persistent naming test, and sending its data to file
called "ior_file", 3) killing the Naming Service process, 4)
restarting the Naming Service on the same port with the same
persistent state storage file, and 5) running the second part
of the client persistence test by specifying the ior from part
1 in the file format.
We kill the Naming Service process between 2 client runs to
make sure it can recreate its state from persistent storage.
It is necessary to restart the Naming Service on the same
host/port in order for the persistent IORs from the first
run to be valid for the second run.
If no option is specified, Simple test is run. If more than one
option is specified, only one test runs.
DESCRIPTION AND EXPECTED OUTPUT FOR EACH TEST
*******************************************
Simple Test.
Performs bind (), resolve (), and unbind () of an object reference in
the root context.
Expected Output:
Bound name OK
Resolved name OK
Unbound name OK
********************************************
MT Test.
Spawns a specified number of threads. Threads concurrently attempt to
bind (), resolve (), and unbind () the object reference.
Expected Output (produced by the output processing script):
Multithreaded output is ok
The output of the actual test varies from run to run, due to the
variation in the thread scheduling. Correct output must have the
following properties (these are the properties that the processing
script checks for):
1) number of bind () calls = number of resolve () calls = number of
unbind () calls = number of threads specified for the test
2) number of successful bind () calls = number of successful unbind () calls.
*******************************************
Tree Test.
Checks all Naming Service functions with a tree of Naming Contexts.
root->bind_new_context (level1)
new = root->new_context (), new->bind (foo, obj), and
root->bind_context (level1/level2, new)
We now have root->level1->level2->foo
root->resolve (level1/level2/foo).
root->unbind (level1/level2/foo).
root->bind (level1/level2/foo, obj).
new = root->new_context()
root->rebind_context(level1/level2, new)
root->bind (level1/level2/foo obj)
root->resolve (level1/level2/foo)
root->rebind (level1/level2/foo, obj2) to have a different object under the name bar.
root->resolve (level1/level2/foo) to make sure correct reference is returned.
Expected Output:
All funtions work properly
********************************************
Exceptions Test.
Makes sure that Naming Service throws exceptions as expected, and data
inside exceptions is set correctly.
Create a tree of Naming Contexts: root context -> level1 -> level2.
Bind an object with the name foo into each of the Naming Contexts.
root->resolve () (with a Name of length 0) - should get InvalidName exception.
root->bind (foo, obj) - should get AlreadyBound exception.
root->bind (level1/foo, obj) - should get AlreadyBound exception.
root->unbind (level1/level2/bar) - should get NotFound exception
with why = missing_node, rest_of_name = bar.
root->unbind (level1/level3/foo) - should get NotFound exception
with why = missing_node, rest_of_name = level3/foo.
root->unbind (level1/foo/foo) -should get NotFound exception
with why = not_context, rest_of_name = foo/foo.
Expected Output:
AlreadyBound exception (case 1) works properly
AlreadyBound exception (case 2) works properly
NotFound exception (case 1) works properly
NotFound exception (case 2) works properly
NotFound exception (case 3) works properly
*********************************************
Iterator Test.
Checks iterator functions.
Bind () objects with the following names foo1, foo2, foo3, and foo4
into the root Naming Context.
root->lists (1, bl, iter)
iter->next_one ()
iter->next_n (2, bl)
iter->next_one () - should return false
iter->destroy ()
Expected Output:
First binding: foo1
Second binding: foo2
Third binding: foo3
Fourth binding: foo4
*********************************************
Destroy Test.
Makes sure destroy method is working properly.
Create a context and bind an object under it.
Attempt to destroy the context - NotEmpty exception should be raised.
Unbind the object and call destroy on the context.
Attempt to call destroy on the object again - OBJECT_NOT_EXIST
exception should be raised.
Expected Output:
NotEmpty exception works properly
Destroy works properly
********************************************
Persistent Test (part 1).
Makes sure persistence mode of the Naming Service functions properly:
this test sets things up for part 2
Creates the Naming Context hierarchy:
root -> level1_context -> level2_context,
and prints out the ior of the <level1_context> to the specified file.
Expected Output:
Persistent Naming test (part 1) OK.
********************************************
Persistent Test (part 2).
Makes sure persistence mode of the Naming Service functions properly.
Attempts to resolve <level2_context> both through the ior obtained
from part 1 of the test, and through the Naming Context obtained from
<resolve_initial_references>. Compares the results of both resolve ()
calls.
Expected Output:
Persistent Naming test (part 2) OK.
********************************************
|
