[omniORB] Location forward ignored by IBM's ORB

baileyk at schneider.com baileyk at schneider.com
Mon Jun 14 11:15:26 BST 2004 

I'm working on a simplified ImR-like service for load balancing, written in
Python using omniORBpy.  Some tests have shown a WebSphere client ignore
LOCATION_FORWARD replies and just retry on the original endpoint.  I'm
working on getting deeper traces of the WebSphere side, and support from
IBM, but I'll post some omniORB traces here in case someone can detect
anything unusual.

First is a LOCATE_REQUEST.  There's no way to hook into these in omniORB
and send back the correct endpoint, so I guess omniORB gives a default
response

omniORB: inputMessage: from giop:tcp:161.222.3.175:42420 77 bytes
omniORB:
4749 4f50 0100 0003 0000 0041 0000 0036 GIOP.......A...6
0000 0039 ff69 6d70 6c52 6570 6f00 673b ...9.implRepo.g;
3b44 4556 2e65 6e76 2f71 3033 3830 382e ;DEV.env/q03808.
7072 742f 4952 4354 2e73 7973 2f72 6174 prt/IRCT.sys/rat
696e 675f 6d67 722e 7372 763b 3b        ing_mgr.srv;;
omniORB: Handling a GIOP LOCATE_REQUEST.
omniORB: sendChunk: to giop:tcp:161.222.3.175:42420 20 bytes
omniORB:
4749 4f50 0100 0004 0000 0008 0000 0036 GIOP...........6
0000 0001                               ....

Then comes an is_a call

omniORB: inputMessage: from giop:tcp:161.222.3.175:42420 355 bytes
omniORB:
4749 4f50 0100 0000 0000 0157 0000 0002 GIOP.......W....
4942 4d12 0000 0008 0000 0000 1310 0004 IBM.............
0000 0006 0000 00c0 0000 0000 0000 0028 ...............(
4944 4c3a 6f6d 672e 6f72 672f 5365 6e64 IDL:omg.org/Send
696e 6743 6f6e 7465 7874 2f43 6f64 6542 ingContext/CodeB
6173 653a 312e 3000 0000 0001 0000 0000 ase:1.0.........
0000 0084 0001 0200 0000 001a 4342 4369 ............CBCi
626d 6465 7630 352e 7363 686e 6569 6465 bmdev05.schneide
722e 636f 6d00 a483 0000 002c 4a4d 4249 r.com......,JMBI
0000 0010 2304 638d 0000 0000 0000 0000 ....#.c.........
0000 0000 0000 0000 0000 0024 0000 0008 ...........$....
0000 0000 0000 0000 0000 0002 0000 0001 ................
0000 0014 0000 0000 0501 0001 0000 0000 ................
0001 0100 0000 0000 4942 4d0a 0000 0008 ........IBM.....
0000 0000 1310 0004 0000 0037 0100 0000 ...........7....
0000 0039 ff69 6d70 6c52 6570 6f00 673b ...9.implRepo.g;
3b44 4556 2e65 6e76 2f71 3033 3830 382e ;DEV.env/q03808.
7072 742f 4952 4354 2e73 7973 2f72 6174 prt/IRCT.sys/rat
696e 675f 6d67 722e 7372 763b 3b00 0000 ing_mgr.srv;;...
0000 0006 5f69 735f 6100 0000 0000 0000 ...._is_a.......
0000 001f 4944 4c3a 736c 692e 7061 782e ....IDL:sli.pax.
6474 6c62 2f44 5453 6572 7669 6365 3a31 dtlb/DTService:1
2e30 00                                 .0.

The ImR does it's thing and returns:

omniORB: Implementation of '_is_a' generated LOCATION_FORWARD.
omniORB: sendChunk: to giop:tcp:161.222.3.175:42420 167 bytes
omniORB:
4749 4f50 0100 0001 0000 009b 0000 0000 GIOP............
0000 0037 0000 0003 0000 0034 4944 4c3a ...7.......4IDL:
736e 692e 7072 742e 6972 6374 2f49 5243 sni.prt.irct/IRC
545f 4d41 4e41 4745 522f 5243 5452 6174 T_MANAGER/RCTRat
696e 674d 616e 6167 6572 493a 312e 3000 ingManagerI:1.0.
0000 0001 0000 0000 0000 004b 0001 0000 ...........K....
0000 000e 3136 312e 3232 322e 332e 3135 ....161.222.3.15
3600 e7f4 0000 002f ff70 726f 635f 6d67 6....../.proc_mg
725f 706f 61fe 40cd 9206 d40e 0003 002f r_poa. at ......../
6465 762f 7261 7465 5f74 6573 7441 2f72 dev/rate_testA/r
6174 655f 6d67 72                       ate_mgr

But the trace log for the omniORB based server at that endpoint shows no
sign of being contacted by the WebSphere process.  It's on the same host as
the ImR but is a separate process.

Next, WebSphere appears to try the is_a call a second time, with a more
derived interface name on the ImR.  The CORBA object being forwarded to
supports both interfaces that are specified in the is_a calls (DTService
and RCTRatingManagerI).

omniORB: inputMessage: from giop:tcp:161.222.3.175:42420 376 bytes
omniORB:
4749 4f50 0100 0000 0000 016c 0000 0002 GIOP.......l....
4942 4d12 0000 0008 0000 0000 1310 0004 IBM.............
0000 0006 0000 00c0 0000 0000 0000 0028 ...............(
4944 4c3a 6f6d 672e 6f72 672f 5365 6e64 IDL:omg.org/Send
696e 6743 6f6e 7465 7874 2f43 6f64 6542 ingContext/CodeB
6173 653a 312e 3000 0000 0001 0000 0000 ase:1.0.........
0000 0084 0001 0200 0000 001a 4342 4369 ............CBCi
626d 6465 7630 352e 7363 686e 6569 6465 bmdev05.schneide
722e 636f 6d00 a483 0000 002c 4a4d 4249 r.com......,JMBI
0000 0010 2304 638d 0000 0000 0000 0000 ....#.c.........
0000 0000 0000 0000 0000 0024 0000 0008 ...........$....
0000 0000 0000 0000 0000 0002 0000 0001 ................
0000 0014 0000 0000 0501 0001 0000 0000 ................
0001 0100 0000 0000 4942 4d0a 0000 0008 ........IBM.....
0000 0000 1310 0004 0000 0038 0100 0000 ...........8....
0000 0039 ff69 6d70 6c52 6570 6f00 673b ...9.implRepo.g;
3b44 4556 2e65 6e76 2f71 3033 3830 382e ;DEV.env/q03808.
7072 742f 4952 4354 2e73 7973 2f72 6174 prt/IRCT.sys/rat
696e 675f 6d67 722e 7372 763b 3b00 0000 ing_mgr.srv;;...
0000 0006 5f69 735f 6100 0000 0000 0000 ...._is_a.......
0000 0034 4944 4c3a 736e 692e 7072 742e ...4IDL:sni.prt.
6972 6374 2f49 5243 545f 4d41 4e41 4745 irct/IRCT_MANAGE
522f 5243 5452 6174 696e 674d 616e 6167 R/RCTRatingManag
6572 493a 312e 3000                     erI:1.0.

And gets the same response and that's it.

Thanks,
Kendall

More information about the omniORB-list mailing list