[omniORB] RE: endless loop when cancelRequest received.

[Vinouse, Jean-Pierre (Jean-Pierre)]

Hello Duncan and All,

Our project uses omniOrb version 4.0.6 and we' ve just got the following
issue:

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.


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.

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

Thanks in advance for any help

Jean-Pierre Vinouse
Alcatel-Lucent
Nuremberg Germany






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070319/932638d6/attachment.htm

[Duncan Grisby]

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

[...]

Post by Vinouse, Jean-Pierre (Jean-Pierre)
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.

Post by Vinouse, Jean-Pierre (Jean-Pierre)
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.

Post by Vinouse, Jean-Pierre (Jean-Pierre)
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.