[omniORB-dev] omni bug (patch attached)

[David Riddoch]

Serguei Kolos wrote:
> David Riddoch wrote:
>> 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?

No, what you are doing is fine.  But sadly, the pd_nInvocations field 
will count each request that is being 'held' by the POA.  I'm afraid 
there is no easy way out of this.

Do you really need to put the poa into the holding state while you 
deactivate the object?  It is perfectly legal to deactivate objects 
while the poa is in the active state, and it would certainly be more 
efficient.

Cheers,
David