[omniORB] OmniNames

[Olivier Thiboutot]

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 742 bytes
Desc: image001.gif
Url : Loading Image...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1521 bytes
Desc: image002.gif
Url : Loading Image...

[Olivier Thiboutot]

Hi, I know that we are a little bit late... But I just found something
surprising!


Here we go...

On Windows Xp Pro SP2 - Application are using compiler VC++ 6.0 but
OmniNames is used as is.

In OmniNames 2.8, if we add -BOAiiop_name_port 127.0.0.1 and -start
option, no problem at creation. (Self laptop contain application)

If after we restart with -BOAiiop_name_port 127.0.0.1 still no
problem...

If we register a CONTEXT and an Object, we have no problem...

If we stop OmniNames.exe and restart it with -BOAiiop_name_port
127.0.0.1, we crash with internal error closing TCP/IP port number -1!!!
(No start parameter to reload history)

If we are not too late, I would appreciate a possible explication and if
it can affect other process then OmniNames?


Best regards.

Olivier Thiboutot

[Serguei Kolos]

Hello

Can one answer please the following question:

I have an impression that after I have deactivated my object with its
POA I may still have
some omniORB threads where the one-way calls to that object are being
processed. Is
that the case with the omniORB 4.0.7 or I'm wrong?

I'm using omniORB 4.0.7 on SLC4 Linux with gcc 34.

Cheers,
Sergei

[Duncan Grisby]

Post by Serguei Kolos
I have an impression that after I have deactivated my object with its
POA I may still have some omniORB threads where the one-way calls to
that object are being processed. Is that the case with the omniORB
4.0.7 or I'm wrong?

Yes, there can still be requests in progress after an object has been
deactivated. That's true regardless of whether the requests are oneways
or not. If you need to know for certain when an object has been
completely deactivated, you can use a servant activator, which will
receive an etherealize call when the object is actually removed.

Cheers,

Duncan.

[Duncan Grisby]

Post by Olivier Thiboutot
In OmniNames 2.8, if we add -BOAiiop_name_port 127.0.0.1 and -start
option, no problem at creation. (Self laptop contain application)
If after we restart with -BOAiiop_name_port 127.0.0.1 still no
problem...
If we register a CONTEXT and an Object, we have no problem...
If we stop OmniNames.exe and restart it with -BOAiiop_name_port
127.0.0.1, we crash with internal error closing TCP/IP port number -1!!!
(No start parameter to reload history)
If we are not too late, I would appreciate a possible explication and if
it can affect other process then OmniNames?

Sorry, omniORB 2.8 is such ancient history that I don't think anyone
will be able to help you. I expect it's something to do with the
endpoint settings in the IORs stored in the omniNames log, but I don't
know for certain.

Duncan.