Re: Sudden change in used GIOP version ?

Hi,

TAO has GIOP 1.2 as default, but try to specify an explicit endpoint for
your server with giop 1.0 as version.

Regards,

Johnny Willemsen


"Jesse" <jc@xxxxxxxxxx> wrote in message
news:f6i9bp$mm7$1@xxxxxxxxxxxxxxxxxxxxxxx
OK OK, I will give you concrete info.

client ORB = OIS ORBexpress ST Ada 2.4.7
server ORB = OCI TAO 1.4a p16

The server holds a single servant, activated once.

I won't go into the details of the TAO config; let's just say that I just
use IIOP, and I don't specify a particular endpoint: I let TAO open its
default one (using its default IIOP version, and asking the system for an
available port).

The threading policy on the server side is "thread-per-connection". I
don't have much details on the client side as I don't have much more info
on ORBexpress runtime behaviour than what debugging symbols are giving me.
I guess this is some kind of reactive mechanism where the caller thread
blocks waiting for the reply.

The IDL implemented is:

module AccountTypes {
exception InsufficientFunds {
string message;
};
};
module AccountServices {
interface AccountAccess {
float get_balance();
void withdraw_money (in float money)
raises (AccountTypes::InsufficientFunds);
};
};

The client connects to the single object inside the server, and the
scenario is as follows:
1- invoke get_balance()
2- invoke withdraw_money, which will raise an exception (too much money
;-)

I then get the following strace output on the client side:

write(8, "GIOP\1\0\1\0L\0\0\0\0\0\0\0\6\0\0\0\1\0\0\0#\0\0\0\24\1"..., 88)
= 88
| 00000 47 49 4f 50 01 00 01 00 4c 00 00 00 00 00 00 00 GIOP....
L....... |
| 00010 06 00 00 00 01 00 00 00 23 00 00 00 14 01 0f 00 ........
#....... |
| 00020 4e 53 54 7f ce 8b 46 6a 8a 09 00 01 00 00 00 01 NST...Fj
........ |
| 00030 00 00 00 11 00 00 00 01 00 00 00 12 00 00 00 2e ........
........ |
| 00040 0c 00 00 00 67 65 74 5f 62 61 6c 61 6e 63 65 00 ....get_
balance. |
| 00050 04 00 00 00 63 6f 74 00 ....cot. |
read(8, "GIOP\1\0\1\1\20\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0", 65536) =
28
| 00000 47 49 4f 50 01 00 01 01 10 00 00 00 00 00 00 00 GIOP....
........ |
| 00010 06 00 00 00 00 00 00 00 00 00 00 00 ........ .... |
write(7, "GIOP\1\0\1\0T\0\0\0\0\0\0\0\5\0\0\0\1\0\0\0#\0\0\0\24\1"..., 96)
= 96
| 00000 47 49 4f 50 01 00 01 00 54 00 00 00 00 00 00 00 GIOP....
T....... |
| 00010 05 00 00 00 01 00 00 00 23 00 00 00 14 01 0f 00 ........
#....... |
| 00020 4e 53 54 0e cb 8b 46 4c 03 0a 00 01 00 00 00 01 NST...FL
........ |
| 00030 00 00 00 11 00 00 00 01 00 00 00 12 00 00 00 2e ........
........ |
| 00040 0f 00 00 00 77 69 74 68 64 72 61 77 5f 6d 6f 6e ....with
draw_mon |
| 00050 65 79 00 00 04 00 00 00 63 6f 74 00 00 00 7a 44 ey......
cot...zD |
read(7, "GIOP\1\2\1\1Z\0\0\0\5\0\0\0\1\0\0\0\0\0\0\0\'\0\0\0IDL"...,
65536) = 102
| 00000 47 49 4f 50 01 02 01 01 5a 00 00 00 05 00 00 00 GIOP....
Z....... |
| 00010 01 00 00 00 00 00 00 00 27 00 00 00 49 44 4c 3a ........
'...IDL: |
| 00020 41 63 63 6f 75 6e 74 54 79 70 65 73 2f 49 6e 73 AccountT
ypes/Ins |
| 00030 75 66 66 69 63 69 65 6e 74 46 75 6e 64 73 3a 31 ufficien
tFunds:1 |
| 00040 2e 30 00 2a 1e 00 00 00 6d 61 78 20 61 6c 6c 6f .0.*.... max
allo |
| 00050 77 65 64 20 6f 76 65 72 64 72 61 66 74 20 72 65 wed over draft
re |
| 00060 61 63 68 65 64 00 ached. |

You can see that the client intiates the dialog with GIOP 1.0 and the
server replies with the same version for 'get_balance' return value.
However, for the reply to 'withdraw_money' the GIOP version suddenly
switches to 1.2.

The client reaction is apparently to simply ignore the message and wait on
recv again on descriptor 7... which freezes him and the whole system
afterwards :-(

I have tried with the server using TAO 1.3a p11 and I get :

write(7, "GIOP\1\0\1\0L\0\0\0\0\0\0\0\10\0\0\0\1\0\0\0#\0\0\0\24"..., 88)
= 88
| 00000 47 49 4f 50 01 00 01 00 4c 00 00 00 00 00 00 00 GIOP....
L....... |
| 00010 08 00 00 00 01 00 00 00 23 00 00 00 14 01 0f 00 ........
#....... |
| 00020 4e 53 54 c6 ff 8b 46 08 51 05 00 01 00 00 00 01 NST...F.
Q....... |
| 00030 00 00 00 10 00 00 00 01 00 00 00 11 00 00 00 31 ........
.......1 |
| 00040 0c 00 00 00 67 65 74 5f 62 61 6c 61 6e 63 65 00 ....get_
balance. |
| 00050 04 00 00 00 63 6f 74 00 ....cot. |
read(7, "GIOP\1\0\1\1\20\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0\310"...,
65536) = 28
| 00000 47 49 4f 50 01 00 01 01 10 00 00 00 00 00 00 00 GIOP....
........ |
| 00010 08 00 00 00 00 00 00 00 00 00 c8 c2 ........ .... |
write(7, "GIOP\1\0\1\0T\0\0\0\0\0\0\0\t\0\0\0\1\0\0\0#\0\0\0\24\1"..., 96)
= 96
| 00000 47 49 4f 50 01 00 01 00 54 00 00 00 00 00 00 00 GIOP....
T....... |
| 00010 09 00 00 00 01 00 00 00 23 00 00 00 14 01 0f 00 ........
#....... |
| 00020 4e 53 54 c6 ff 8b 46 08 51 05 00 01 00 00 00 01 NST...F.
Q....... |
| 00030 00 00 00 10 00 00 00 01 00 00 00 11 00 00 00 31 ........
.......1 |
| 00040 0f 00 00 00 77 69 74 68 64 72 61 77 5f 6d 6f 6e ....with
draw_mon |
| 00050 65 79 00 00 04 00 00 00 63 6f 74 00 00 00 7a 44 ey......
cot...zD |
read(7, "GIOP\1\0\1\1Z\0\0\0\0\0\0\0\t\0\0\0\1\0\0\0\'\0\0\0IDL"...,
65536) = 102
| 00000 47 49 4f 50 01 00 01 01 5a 00 00 00 00 00 00 00 GIOP....
Z....... |
| 00010 09 00 00 00 01 00 00 00 27 00 00 00 49 44 4c 3a ........
'...IDL: |
| 00020 41 63 63 6f 75 6e 74 54 79 70 65 73 2f 49 6e 73 AccountT
ypes/Ins |
| 00030 75 66 66 69 63 69 65 6e 74 46 75 6e 64 73 3a 31 ufficien
tFunds:1 |
| 00040 2e 30 00 00 1e 00 00 00 6d 61 78 20 61 6c 6c 6f .0...... max
allo |
| 00050 77 65 64 20 6f 76 65 72 64 72 61 66 74 20 72 65 wed over draft
re |
| 00060 61 63 68 65 64 00 ached. |

Much better isn't it ? At least the client is much happier with that.

Thanks for your input... before I contact directly the guys at OCI ;-)

Cheers,

JC.

"Yakov Gerlovin" <yakov.gerlovin@xxxxxxxxx> wrote in message
news:1183581368.538644.158980@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
It is really hard to guess what exactly causes the problem without
more detailed info.
You did not specified the ORBs your applications are using. Could be a
configuration problem if the server is using Orbix and if it does I
hope the client at least does not use Java 1.3 ORB.

If I remember correctly, the GIOP version is encoded in IOR, so the
short answer to your question is no (server does not suddenly change
the GIOP version). However, if as a result of some call you're getting
an object, this object can be accessed using another version of GIOP
or even another transport.

If you need further assistance please specify
1. the exact versions of ORBs
2. the sequence of operations
3. the *simplified* IDLs that describes the operations invoked




.

Relevant Pages

  • Re: CORBA ORB for C#.NET
    ... You might want to take a look at the mono project (its C#, supports CORBA, ... I`d like to create CORBA server with Borland Delphi ... and few client applications taht comunicate with serwer: ... use VisiBroker ORB, and Java client using ORB from JSDK. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Sudden change in used GIOP version ?
    ... client ORB = OIS ORBexpress ST Ada 2.4.7 ... The server holds a single servant, ... I won't go into the details of the TAO config; let's just say that I just use IIOP, and I don't specify a particular endpoint: I let TAO open its default one. ... I don't have much details on the client side as I don't have much more info on ORBexpress runtime behaviour than what debugging symbols are giving me. ...
    (comp.object.corba)
  • Re: CORBA with heterogenic system poject
    ... I`d like to create CORBA server with Borland Delphi (or ... C#.NET) and few client applications taht comunicate with serwer: ... VisiBroker ORB, and Java client using ORB from JSDK. ...
    (comp.object.corba)
  • Re: CORBA with heterogenic system poject
    ... Here is error message i`m receiving when try to run corba java corba client: ... I`d like to create CORBA server with Borland Delphi ... VisiBroker ORB, and Java client using ORB from JSDK. ...
    (comp.object.corba)
  • Sudden change in used GIOP version ?
    ... I have a client and a server communication via CORBA, each on its own ORB implementation. ... What I see is that the client sends requests to a unique object in the server, ... is this sudden change in the GIOP version from the server initiative really standard? ...
    (comp.object.corba)