[omniORB] Bad performance with oneway invocation - UNDERSTOOD

[Jon Dyte]

Serguei,

If you look at the latest CVS you will GIOP_S::SendReply() see has already 
been changed. I think Duncan did this in response to yr issues with
performance of oneway calls.


GIOP_S::SendReply() {

  OMNIORB_ASSERT(pd_state == WaitingForReply);

  if (!response_expected()) {
    pd_state = ReplyCompleted;
    return;
  }

  pd_service_contexts.length(0);

  if (omniInterceptorP::serverSendReply) {
    omniInterceptors::serverSendReply_T::info_T info(*this);
    omniInterceptorP::visit(info);
  }
  pd_state = ReplyIsBeingComposed;
  impl()->outputMessageBegin(this,impl()->marshalReplyHeader);
  cdrStream& s = *this;
  calldescriptor()->marshalReturnedValues(s);
  impl()->outputMessageEnd(this);
  pd_state = ReplyCompleted;
}


Jon

On Tuesday 22 Jul 2003 6:15 pm, Serguei Kolos wrote:
> Hello all
>
> Serguei Kolos wrote:
> > But the bad thing is that the problem with oneway calls still exist
> > somewhere :-(    (I hope not only in my mind)
>
> U-u-u-u-u-u-u-u-u-u-u-u-ffff.
> I spent several days trying to solve the oneway call issue and ... I GOT
> IT. The problem is connected to the fact that the GIOP_S::SendReply
> function throws the terminateProcessing exception for the oneway calls. The
> execution
> of this exception takes enormous time. Don't ask me why, may be it is
> compiler
> bug (I'm using gcc 3.2), may be it must be so - I don't know.
> But the good news are that when I changed the line 626 in the
> GIOP_S::SendReply
> from
> if (!response_expected()) throw terminateProcessing();
> to
>   if (!response_expected()) return;
> everything starts working as I expected. The CPU consumption on server
> gets in order
> now. The time for the oneway call (measured on a client side) improved
> by a factor of 5.
>
> I'm not sure that simply replacing the exception with the return is a
> correct solution. If it isn't
> could some one figure out the best way of getting rid of this nasty
> exception.
>
> Cheers
> Sergei
>
> PS: I would recommend to everybody to use excellent Valgrind and
> Kcachegrind tools, which
> I used to locate a problem. Without them it would be completely
> impossible. (this is not an advertisement)
> Link:
> http://kcachegrind.sourceforge.net/
>
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list