We need to be able to define call rate meters for time spans not limited
to TimeUnit intervals of 1 SECOND, 1 HOUR, or 1 DAY. This change allows
more flexibility, e.g., 10 per 5 seconds, 10 per 5 hrs, 100 per 7 days.
Points to a call rate metering interceptor configuration file.
Test cases can build a config file, and the test harness will
install it into a daemon's appDataDir before startup.
The installed config file will be used to configure gRPC
service rate metering interceptors.
This change demonstrates how a method call rate metering interceptor
is configured for a gRPC service. GrpcVersionService uses a custom
rate metering interceptor, or none. A commented out, 'default'
interceptor is defined as a usage example.
This adds a GrpcServiceRateMeteringConfig class that can read and
write rate metering interceptor config files, and configure
a gRPC rate metering service interceptor at startup.
This seems excessive, but we need to be able to test and tune
method rate metering without having to change hard coded, default
interceptor rate meters.
This change provides a gRPC CallRateMeteringInterceptor to help protect
the server and network against being overloaded by CLI scripting mistakes.
An interceptor instance can be configured on a gRPC service to set
individual method call rate limits on one or more of the the service's
methods. For example, the GrpcOffersService could be configured with
this interceptor to set the createoffer rate limit to 5/hour, and
the takeoffer call rate limit could be set to 20/day. Whenever a
call rate limit is exceeded, the gRPC call is aborted and the client
recieves a "rate limit exceeded" error.
Below is a simple example showing how to set rate limits for one method
in GrpcVersionService.
final ServerInterceptor[] interceptors() {
return new ServerInterceptor[]{
new CallRateMeteringInterceptor(new HashMap<>() {{
put("getVersion", new GrpcCallRateMeter(2, SECONDS));
}})
};
}
It specifies a CLI can execute getversion 2 times / second.
This is not a throttling mechansim, there is no blocking nor locking
to slow call rates. When call rates are exceeded, calls are
simply aborted.
This change reduces gRPC service error handling duplication by moving
it into a @Singleton encapsulating everything needed to wrap
an expected or unexpected core api exception into a gRPC
StatusRuntimeException before sending it to the client. It also
fixes some boilerpate classes were gRPC error handling was missing.
