[omniORB] RE: endless loop when cancelRequest received.

[Duncan Grisby]

On Monday 19 March, "Vinouse, Jean-Pierre \(Jean-Pierre\)" wrote:

[...]
> When the client (non omniORb) sends a request to the servant (omniOrb)
> and the servant is not able to reply to the client (e.g. because the IP
> connectivity is disturbed) we observe that the client sends a
> CancelRequest to the servant. The servant then enters an endless loop in
> giopWorker::real_execute() and occupies the full cpu. This leads later
> to a reboot of our application.
> 
>   do {
>     {
>       GIOP_S_Holder iops_holder(pd_strand,this);
> 
>       GIOP_S* iop_s = iops_holder.operator->();
>       if (iop_s) {
> 	exit_on_error = !iop_s->dispatcher();
>       }
>       else {
> 	exit_on_error = 1;
>       }
>     }
>     go = pd_server->notifyWkDone(this,exit_on_error);
> 
>   } while(go && !exit_on_error);
> 
> Variable "go" keeps true and "exit_on_error" keeps false so that the
> loop is executed for ever. 

Each call into dispatcher() is meant to handle a new incoming message
from the client. Receiving a CancelRequest message should not prevent
subsequent messages from being handled.

> Looking at the code of CORBA::Boolean GIOP_S::handleCancelRequest() 
> {
>   // We do not have the means to asynchronously abort the execution of
>   // an upcall by another thread. Therefore it is not possible to
>   // cancel a request that has already been in progress. The best we
>   // can do is prevent the reply from happening.
>   omniORB::logs(5, "Received a CancelRequest message.");
>   pd_state = WaitingForReply;
>   response_expected(0);
>   return 1;
> }
> 
> Would it be an acceptable solution to return 0 to avoid the endless loop
> without side effects. 

No -- that would cause the connection to be dropped as broken, when
actually the connection is fine.

> Is there any plan to improve the handling of cancelRequest in a future
> release ?

It's fundamentally impossible to interrupt processing of application
code when a CancelRequest arrives, so there's no intention of trying to
change that.

As far as I am aware, CancelRequest processing works fine, with the
limitation that it can't interrupt the call processing, merely prevent
the response being sent. The problem you are seeing is not that
CancelRequest processing does not work at all. It must be something more
subtle.

Please get a trace of the problem occurring with omniORB options
-ORBtraceLevel 30 -ORBtraceInvocations 1 -ORBtraceThreadId 1. That
should show better what is going on.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --