Re: omni bug (patch attached)

On Monday 24 November, Serguei Kolos wrote:

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

The wording in the spec is not especially clear, but omniORB's current
behaviour is definitely correct. The definition of hold_requests says
wait_for_completion waits until there are "no actively _executing_
requests... that is, all requests that were started prior to the state
change have completed".

The definition of deactivate_object, on the other hand, says "An
ObjectId that has been deactivated continues to process requests until
there are no active requests for that ObjectId. Active requests are
those requests that arrived before deactivate_object was called."
That clearly includes ones that arrived while the POA was in the
holding state. Furthermore, to avoid deadlocks or exceptions in
objects that call themselves, new incoming requests must be accepted
while an object is pending deactivation.

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

If you put the POA in the DISCARDING state, rather than HOLDING, you
will get exactly the behaviour you want, since that will prevent the
queue of new incoming calls. If your clients were calling two-way
operations, they would get TRANSIENT exceptions, but since the
operations are oneway, they will just be dropped.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --