blob: bd19ac387b862cc827e9d412049be3f233d4434b (
plain)
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
|
/**
@page Two_Objects Test README File
This is used as an extended test for bug fix #575.
There are two objects managed by the same POA. Before the
bug fix, the calls to the objects on the same connection
were serialized even when the first call was a one way call.
The connection handle in the reactor was not 'resumed' until
the upcall after was completed. The fix resumes the handle
before the upcall is made, so that another thread could listen
for subsequent requests on the same connection handle.
Description:
The server creates two servants ( each implementing different
interfaces ). Two threads are created on the server and each
one of them listens for requests (has a orb->run() call). The
client first makes a one way call to Servant 1. It then makes
a two way call to Servant 2. Servant 1 handles the oneway
request and waits for a signal from Servant 2. Servant 2 gets
the two way request, handles it and then wakes up Servant 1.
We do an assertion that there is only one connection in the
transport cache manager. If the bug fix was not working,
Servant 2 would have never received the request and Servant 1
will wait for ever.
To run the test use the run_test.pl script:
$ ./run_test.pl
the script returns 0 if the test was successful.
Expected output:
ior file = test.ior #threads = 2 msglen = 100000 ORB timeout = 30 sec
Client : one way call done
Oneway servant : (<pid>|<tid>) one way method called. About to wait for
two way call completion
Twoway servant : (<pid>|<tid>) two way method called.
Twoway servant : (<pid>|<tid>) about to signal one way thread.
Oneway servant : (<pid>|<tid>) woke up after wait
Client : length of returned data is 100000
(<pid>|<tid>) event loop finished
<pid>, <tid> will have actual values for process id and thread id.
*/
|
