[omniORB-dev] omni bug (patch attached)

Serguei Kolos Serguei.Kolos at cern.ch
Mon Nov 24 12:41:37 GMT 2003


Hi
Thank you for the answer.

David Riddoch wrote:

> Hi,
>
> Serguei Kolos wrote:
>
>> While doing object deactivation I have noticed that omni always 
>> delays deactivation
>> to another thread because the omniLocalIdentity::is_idle() method is 
>> implemented as
>> { return !pd_nInvocations;}.
>
>
> Do you have reason to believe that omniORB always delays deactivation? 
> (Other than your analysis of the code?).  If so, are you sure you 
> don't have any requests outstanding on that object? 

Yes I have such reasons. What I'm doing in my code is the following:

   POAManager_var poa_man = poa_ -> the_POAManager();
   poa_man->hold_requests( true );
   ObjectId_var oid = poa_->servant_to_id( servant );
   poa_->deactivate_object( oid.in() );
   poa_man->activate();

I believe that when the hold_requests( true ) returns there must be no 
active requests
for the poa_ POA and therefore must be no active requests for the 
servant object,
which was activated with this POA.
But what I noticed is - if the are applications, which are trying to 
communicate to the
servant object at the time in which I'm doing this deactivation, then 
the deactivate_object
always delays deactivation (pd_nInvocations always equal 2 ).
Am I doing something wrong?

Cheers,
Sergei

PS: I know that such code can not be used in the body of the IDL 
methods, so I'm not doing that.





More information about the omniORB-dev mailing list