[omniORB] [Q] initializing naming service in a different thread

[V S P]

Hi,
a quick question

I first coded the app such that in 'main' it gets
the naming context

and then I spawn 'worker threads' and then when a thread
processes my requests, it uses the pointer to the naming context
(initialized in main) and try to obtain a reference to
the desired corba server. I am not using any 'locks' I just insure
that the worker threads start after the naming server context is
available.

That appears to throw 'BAD_INV_ORDER' (bad invocation order)
exception. It does not do it when I have everything in one thread


am I correct to assume that getting the naming context has to be in the
same thread as resolving the desired server's context?
(I was trying to save some time by not contacting naming service every
time I need I process the request, but perhaps the proper thing to do is
to
save the 'resolved server context' once per thread and store it in
thread local data)

thank you

[Duncan Grisby]

Post by V S P
I first coded the app such that in 'main' it gets
the naming context
and then I spawn 'worker threads' and then when a thread
processes my requests, it uses the pointer to the naming context
(initialized in main) and try to obtain a reference to
the desired corba server. I am not using any 'locks' I just insure
that the worker threads start after the naming server context is
available.
That appears to throw 'BAD_INV_ORDER' (bad invocation order)
exception. It does not do it when I have everything in one thread
am I correct to assume that getting the naming context has to be in the
same thread as resolving the desired server's context?

No, that is not correct. Any object reference can be used from any
thread. Whatever is going wrong, it's not that you're using the naming
context from a different thread to the main thread.

There are very few places that BAD_INV_ORDER is thrown. The main place
you get it is if you try to use things during or after ORB shutdown. Are
you shutting down the ORB in the main thread before your other threads
run?

Try running with -ORBtraceLevel 25 -ORBtraceThreadId 1. That will show
you where the exception comes from.

Cheers,

Duncan.

[V S P]

Hi,
you are right
your email helped me to look at it from a different prospective

what was happening, is that the 'main's thread function where
Initialized
the pointer to naming service -- completed sooner than the worker
threads
(so even though the start up sequence was 'correctly' ordered the
shutdown
was not -- because I 'joined' worker threads much later on)

so essentially the naming service pointer was gone (but not destroyed)
while the 'worker'
thread was trying to use it.


one thing I find remarkable about omniORB is that it does exactly what
it is supposed
to do by the spec, regardless what incorrect use case I throw at it :-)


thank you,
vlad

Post by Duncan Grisby

Post by V S P
I first coded the app such that in 'main' it gets
the naming context
and then I spawn 'worker threads' and then when a thread
processes my requests, it uses the pointer to the naming context
(initialized in main) and try to obtain a reference to
the desired corba server. I am not using any 'locks' I just insure
that the worker threads start after the naming server context is
available.
That appears to throw 'BAD_INV_ORDER' (bad invocation order)
exception. It does not do it when I have everything in one thread
am I correct to assume that getting the naming context has to be in the
same thread as resolving the desired server's context?

No, that is not correct. Any object reference can be used from any
thread. Whatever is going wrong, it's not that you're using the naming
context from a different thread to the main thread.
There are very few places that BAD_INV_ORDER is thrown. The main place
you get it is if you try to use things during or after ORB shutdown. Are
you shutting down the ORB in the main thread before your other threads
run?
Try running with -ORBtraceLevel 25 -ORBtraceThreadId 1. That will show
you where the exception comes from.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- http://www.grisby.org --