2022-07-17 15:43:29 -07:00
|
|
|
//! Tower service layer for batch processing.
|
|
|
|
|
2020-06-12 10:22:08 -07:00
|
|
|
use std::{fmt, marker::PhantomData};
|
2022-07-17 15:43:29 -07:00
|
|
|
|
2020-06-12 11:42:28 -07:00
|
|
|
use tower::layer::Layer;
|
|
|
|
use tower::Service;
|
2020-06-12 10:22:08 -07:00
|
|
|
|
2022-07-17 15:43:29 -07:00
|
|
|
use super::{service::Batch, BatchControl};
|
|
|
|
|
2020-06-12 11:42:28 -07:00
|
|
|
/// Adds a layer performing batch processing of requests.
|
2020-06-12 10:22:08 -07:00
|
|
|
///
|
|
|
|
/// The default Tokio executor is used to run the given service,
|
|
|
|
/// which means that this layer can only be used on the Tokio runtime.
|
|
|
|
///
|
|
|
|
/// See the module documentation for more details.
|
Revert #500 (generic errors in tower-batch).
Unfortunately, since the Batch wrapper was changed to have a generic error
type, when wrapping it in another Service, nothing constrains the error type,
so we have to specify it explicitly to avoid an inference hole. This is pretty
unergonomic -- from the compiler error message it's very unintuitive that the
right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`.
The options are:
1. roll back the changes that make the error type generic, so that the error
type is a concrete type;
2. keep the error type generic but hardcode the error in the default
constructor and add an additional code path that allows overriding the
error.
However, there's a further issue with generic errors: the error type must be
Clone. This problem comes from the fact that there can be multiple Batch
handles that have to share access to errors generated by the inner Batch
worker, so there's not a way to work around this. However, almost all error
types aren't Clone, so there are fairly few error types that we would be
swapping in.
This suggests that in case (2) we would be maintaining extra code to allow
generic errors, but with restrictive enough generic bounds to make it
impractical to use generic error types. For this reason I think that (1) is a
better option.
2020-07-15 21:42:57 -07:00
|
|
|
pub struct BatchLayer<Request> {
|
2022-07-17 15:43:29 -07:00
|
|
|
max_items_in_batch: usize,
|
|
|
|
max_batches: Option<usize>,
|
2020-06-12 11:42:28 -07:00
|
|
|
max_latency: std::time::Duration,
|
2022-07-17 15:43:29 -07:00
|
|
|
|
|
|
|
// TODO: is the variance correct here?
|
|
|
|
// https://doc.rust-lang.org/1.33.0/nomicon/subtyping.html#variance
|
|
|
|
// https://doc.rust-lang.org/nomicon/phantom-data.html#table-of-phantomdata-patterns
|
|
|
|
_handles_requests: PhantomData<fn(Request)>,
|
2020-06-12 10:22:08 -07:00
|
|
|
}
|
|
|
|
|
Revert #500 (generic errors in tower-batch).
Unfortunately, since the Batch wrapper was changed to have a generic error
type, when wrapping it in another Service, nothing constrains the error type,
so we have to specify it explicitly to avoid an inference hole. This is pretty
unergonomic -- from the compiler error message it's very unintuitive that the
right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`.
The options are:
1. roll back the changes that make the error type generic, so that the error
type is a concrete type;
2. keep the error type generic but hardcode the error in the default
constructor and add an additional code path that allows overriding the
error.
However, there's a further issue with generic errors: the error type must be
Clone. This problem comes from the fact that there can be multiple Batch
handles that have to share access to errors generated by the inner Batch
worker, so there's not a way to work around this. However, almost all error
types aren't Clone, so there are fairly few error types that we would be
swapping in.
This suggests that in case (2) we would be maintaining extra code to allow
generic errors, but with restrictive enough generic bounds to make it
impractical to use generic error types. For this reason I think that (1) is a
better option.
2020-07-15 21:42:57 -07:00
|
|
|
impl<Request> BatchLayer<Request> {
|
2020-06-12 11:42:28 -07:00
|
|
|
/// Creates a new `BatchLayer`.
|
2020-06-12 10:22:08 -07:00
|
|
|
///
|
2020-06-12 11:42:28 -07:00
|
|
|
/// The wrapper is responsible for telling the inner service when to flush a
|
2022-07-17 15:43:29 -07:00
|
|
|
/// batch of requests. See [`Batch::new()`] for details.
|
|
|
|
pub fn new(
|
|
|
|
max_items_in_batch: usize,
|
|
|
|
max_batches: impl Into<Option<usize>>,
|
|
|
|
max_latency: std::time::Duration,
|
|
|
|
) -> Self {
|
2020-06-12 11:42:28 -07:00
|
|
|
BatchLayer {
|
2022-07-17 15:43:29 -07:00
|
|
|
max_items_in_batch,
|
|
|
|
max_batches: max_batches.into(),
|
2020-06-12 11:42:28 -07:00
|
|
|
max_latency,
|
2022-07-17 15:43:29 -07:00
|
|
|
_handles_requests: PhantomData,
|
2020-06-12 10:22:08 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Revert #500 (generic errors in tower-batch).
Unfortunately, since the Batch wrapper was changed to have a generic error
type, when wrapping it in another Service, nothing constrains the error type,
so we have to specify it explicitly to avoid an inference hole. This is pretty
unergonomic -- from the compiler error message it's very unintuitive that the
right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`.
The options are:
1. roll back the changes that make the error type generic, so that the error
type is a concrete type;
2. keep the error type generic but hardcode the error in the default
constructor and add an additional code path that allows overriding the
error.
However, there's a further issue with generic errors: the error type must be
Clone. This problem comes from the fact that there can be multiple Batch
handles that have to share access to errors generated by the inner Batch
worker, so there's not a way to work around this. However, almost all error
types aren't Clone, so there are fairly few error types that we would be
swapping in.
This suggests that in case (2) we would be maintaining extra code to allow
generic errors, but with restrictive enough generic bounds to make it
impractical to use generic error types. For this reason I think that (1) is a
better option.
2020-07-15 21:42:57 -07:00
|
|
|
impl<S, Request> Layer<S> for BatchLayer<Request>
|
2020-06-12 10:22:08 -07:00
|
|
|
where
|
2020-06-12 11:42:28 -07:00
|
|
|
S: Service<BatchControl<Request>> + Send + 'static,
|
2020-06-12 10:22:08 -07:00
|
|
|
S::Future: Send,
|
2022-07-17 15:43:29 -07:00
|
|
|
S::Response: Send,
|
Revert #500 (generic errors in tower-batch).
Unfortunately, since the Batch wrapper was changed to have a generic error
type, when wrapping it in another Service, nothing constrains the error type,
so we have to specify it explicitly to avoid an inference hole. This is pretty
unergonomic -- from the compiler error message it's very unintuitive that the
right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`.
The options are:
1. roll back the changes that make the error type generic, so that the error
type is a concrete type;
2. keep the error type generic but hardcode the error in the default
constructor and add an additional code path that allows overriding the
error.
However, there's a further issue with generic errors: the error type must be
Clone. This problem comes from the fact that there can be multiple Batch
handles that have to share access to errors generated by the inner Batch
worker, so there's not a way to work around this. However, almost all error
types aren't Clone, so there are fairly few error types that we would be
swapping in.
This suggests that in case (2) we would be maintaining extra code to allow
generic errors, but with restrictive enough generic bounds to make it
impractical to use generic error types. For this reason I think that (1) is a
better option.
2020-07-15 21:42:57 -07:00
|
|
|
S::Error: Into<crate::BoxError> + Send + Sync,
|
2020-06-12 10:22:08 -07:00
|
|
|
Request: Send + 'static,
|
|
|
|
{
|
Revert #500 (generic errors in tower-batch).
Unfortunately, since the Batch wrapper was changed to have a generic error
type, when wrapping it in another Service, nothing constrains the error type,
so we have to specify it explicitly to avoid an inference hole. This is pretty
unergonomic -- from the compiler error message it's very unintuitive that the
right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`.
The options are:
1. roll back the changes that make the error type generic, so that the error
type is a concrete type;
2. keep the error type generic but hardcode the error in the default
constructor and add an additional code path that allows overriding the
error.
However, there's a further issue with generic errors: the error type must be
Clone. This problem comes from the fact that there can be multiple Batch
handles that have to share access to errors generated by the inner Batch
worker, so there's not a way to work around this. However, almost all error
types aren't Clone, so there are fairly few error types that we would be
swapping in.
This suggests that in case (2) we would be maintaining extra code to allow
generic errors, but with restrictive enough generic bounds to make it
impractical to use generic error types. For this reason I think that (1) is a
better option.
2020-07-15 21:42:57 -07:00
|
|
|
type Service = Batch<S, Request>;
|
2020-06-12 10:22:08 -07:00
|
|
|
|
|
|
|
fn layer(&self, service: S) -> Self::Service {
|
2022-07-17 15:43:29 -07:00
|
|
|
Batch::new(
|
|
|
|
service,
|
|
|
|
self.max_items_in_batch,
|
|
|
|
self.max_batches,
|
|
|
|
self.max_latency,
|
|
|
|
)
|
2020-06-12 10:22:08 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Revert #500 (generic errors in tower-batch).
Unfortunately, since the Batch wrapper was changed to have a generic error
type, when wrapping it in another Service, nothing constrains the error type,
so we have to specify it explicitly to avoid an inference hole. This is pretty
unergonomic -- from the compiler error message it's very unintuitive that the
right fix is to change `Batch::new` to `Batch::<_, _, SomeError>::new`.
The options are:
1. roll back the changes that make the error type generic, so that the error
type is a concrete type;
2. keep the error type generic but hardcode the error in the default
constructor and add an additional code path that allows overriding the
error.
However, there's a further issue with generic errors: the error type must be
Clone. This problem comes from the fact that there can be multiple Batch
handles that have to share access to errors generated by the inner Batch
worker, so there's not a way to work around this. However, almost all error
types aren't Clone, so there are fairly few error types that we would be
swapping in.
This suggests that in case (2) we would be maintaining extra code to allow
generic errors, but with restrictive enough generic bounds to make it
impractical to use generic error types. For this reason I think that (1) is a
better option.
2020-07-15 21:42:57 -07:00
|
|
|
impl<Request> fmt::Debug for BatchLayer<Request> {
|
2020-06-12 10:22:08 -07:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
|
|
|
|
f.debug_struct("BufferLayer")
|
2022-07-17 15:43:29 -07:00
|
|
|
.field("max_items_in_batch", &self.max_items_in_batch)
|
|
|
|
.field("max_batches", &self.max_batches)
|
2020-06-12 11:42:28 -07:00
|
|
|
.field("max_latency", &self.max_latency)
|
2020-06-12 10:22:08 -07:00
|
|
|
.finish()
|
|
|
|
}
|
|
|
|
}
|