[omniORB-dev] omni bug (patch attached)

[Serguei Kolos]

Hi David

>>
>> 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. 

It would be really crucial for me to have this feature working correctly.

Yes I understand the efficiency reason, but for me it is not very 
important because the
object deactivation is done fairly rarely. This functionality is 
important for me because I have
found that as a good way of fast object deactivation.
I have an object, which receives permanently a lot of oneway messages 
from a number of other
applications.  Trying to deactivate this object via using the 
ServantActivator::etherealize results
in a long and unpredictable time delay between call to the 
object_deactivate and the actual object
etherealization.
The approach, which I'm using works sometime faster and what is more 
important it guarantees
that object deactivation will be finished in a fixed time. As far as I 
understood from the "Advanced C++
programming with CORBA" book the approach, which uses ServantActivator 
might never finish the
deactivation process.
Do you think it will be possible to have the problem fixed in the future?
Otherwise could you give me some hints for what I have to do in order to 
fix it myself and I'll try
to produce a patch for the omni.

Cheers,
Sergei