[Xorp-hackers] rtrmgr and TaskManager

Ben Greear greearb at candelatech.com
Wed Oct 7 09:36:07 PDT 2009


On 10/07/2009 01:49 AM, Bruce Simpson wrote:

> There's a little bit of additional complexity in async RPC (both Thrift
> and XRL) to deal with out-of-order delivery. Not fully implemented, though.

I think as long as each process's events are (or can be) ordered, it isn't so
big of a deal if there is reordering in time among different processes.

A single process, say xorpsh, could then just wait for completion of
the previous request before making a new one to ensure serialization.

I *think* that the 'commit' is serialized like this already, but if not,
I'll need to make it so.

For other applications, it would be good to turn on serialization by
default (for instance, the router daemons often make xrl calls and appear
to expect the previous one to complete before the second one is attempted).

Based on my brief look at rtr-mgr, if the client process doesn't wait for
completion, then it's *possible* for requests from the same process to
be reordered.

>> Someday I'll add a XORP_WARNING return instead of just OK and ERROR so
>> that we can return warning messages w/out failing commands.
>
> More appropriate use of exceptions might be better. Orion has argued
> that removing exceptions keeps the footprint down, I wonder if it's
> worth the churn.

You couldn't throw an exception across an RPC, but you could return
proper error codes and text strings to describe the error/warning/info/etc.

Either way, I don't like C++ exceptions and prefer using return values
and/or passing an error-reporting construct by value to be filled out
by lower calls (like passing in a string& err_msg, and using the return
value to know if an error actually happened.)  We could use a more formal
construct, maybe consisting of something like:

class foo {
   int severity; // enum, how bad was it?  info,warning,error,fatal ??
   int error_code; // enum, like errno perhaps? no-such-route,no-such-vif,invalid-request, ...
   string message;
};

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Xorp-hackers mailing list