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

[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



On Mon, 20 Apr 2009 11:26 +0100, "Duncan Grisby" <duncan at grisby.org>
wrote:
> On Saturday 18 April, "V S P" wrote:
> 
> > 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         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
-- 
  V S P
  toreason at fastmail.fm

-- 
http://www.fastmail.fm - A fast, anti-spam email service.