[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