pool-ng#230
Conversation
4d6bdd7 to
47785bc
Compare
This comment was marked as outdated.
This comment was marked as outdated.
2 similar comments
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
47785bc to
79b11b8
Compare
This comment was marked as outdated.
This comment was marked as outdated.
79b11b8 to
ded06e9
Compare
|
/rustdoc-preview |
|
📝 Rustdoc preview for this PR: View docs |
778d49d to
7b668a6
Compare
|
/rustdoc-preview |
|
📝 Rustdoc preview for this PR: View docs |
sjcobb2022
left a comment
sjcobb2022
left a comment
There was a problem hiding this comment.
Looking great overall. Will test in some crates later on in the week
| //! The map isn't a typical `Service`, but rather stand-alone type that can map | ||
| //! requests to a key and service factory. This is because the service is more | ||
| //! of a router, and cannot determine which inner service to check for | ||
| //! backpressure since it's not know until the request is made. | ||
| //! | ||
| //! The map implementation allows customization of extracting a key, and how to | ||
| //! construct a MakeService for that key. |
There was a problem hiding this comment.
Potential rewrite:
This map is not a traditional Service; instead, it is a standalone type that allows users to associate incoming keys with service factories. For each request, a key is extracted and used to select or construct a corresponding service.
Because this service acts more like a router, it cannot determine which inner service to check for backpressure ahead of time; the appropriate service is only known once a request has been received.
| let mut pool = super::Map::builder().keys(|_| "a").values(|_| "b").build(); | ||
| pool.service(&"hello"); | ||
| } | ||
| } |
There was a problem hiding this comment.
#[test]
fn it_returns_same_service_for_same_key() {
let mut pool = Map::builder()
.keys(|s: &&str| *s)
.values(|_| {
String::from("service")
})
.build();
let service1 = pool.service(&"foo") as *const String;
let service2 = pool.service(&"foo") as *const String;
// Should be the same pointer.
assert_eq!(service1, service2);
}
#[test]
fn it_returns_different_service_for_different_keys() {
let mut pool = Map::builder()
.keys(|s: &&str| *s)
.values(|s| format!("service-for-{}", s))
.build();
let service1 = pool.service(&"foo") as *const String;
let service2 = pool.service(&"bar") as *const String;
// Should NOT be the same pointer (different key/service)
assert_ne!(service1, service2);
// Optionally, check the actual value
assert_eq!(pool.service(&"foo"), "service-for-foo");
assert_eq!(pool.service(&"bar"), "service-for-bar");
}| //! The singleton pool combines a MakeService that should only produce a single | ||
| //! active connection. It can bundle all concurrent calls to it, so that only | ||
| //! one connection is made. All calls to the singleton will return a clone of | ||
| //! the inner service once established. | ||
| //! | ||
| //! This fits the HTTP/2 case well. |
There was a problem hiding this comment.
Take it or leave it:
The singleton pool manages a MakeService that should only produce a single active connection.
| T::Key: Eq + std::hash::Hash, | ||
| { | ||
| /// Get a service after extracting the key from `req`. | ||
| pub fn service(&mut self, req: &Req) -> &mut T::Service { |
There was a problem hiding this comment.
Would it still be worth implementing Service for this, which just calls the underlying method? Means we have a "consistent" API for all the pool methods.
There was a problem hiding this comment.
So far I still think it's proper to not provide the impl. Wouldn't be a problem to eventually add one if so needed.
There was a problem hiding this comment.
Actually, if we want to store Map, it would be much nicer if we had Service for it, since that means we can name the type that we can name the type of the returned service.
e.g. we can store cache, singleton, and negotiate because they can be abstracted away into Services over children services, but since target is private we can't really name it.
20769ab to
63227af
Compare
8411023 to
09a85d0
Compare
|
/rustdoc-preview |
|
📝 Rustdoc preview for this PR: View docs |
16e4b8b to
e829e93
Compare
086fa20 to
93d3f4a
Compare
|
Alright, each piece worth keeping has been merged individually. This PR now longer has any use, so closing it down. |
|
@seanmonstar it did have the client example which we didn't have elsewhere |
2 participants
Just a combined pull request for generating docs previews and some CI testing, look at the separate PRs for the individual pieces.