-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid using shared connection pool #15
Comments
Any idea how to ideal with multiple regions? I wonder since depending on the region, it's a different host, so, it should handle multiple connection pools depending on the aws client usage. |
Hi @gabfssilva, thanks for giving this a thought. Yes, we would need multiple pools, each for every aws service endpoint (also possible multiple regions per service). A first naive idea coming to my mind is getting the service url from |
That's what I thought too. A synchronized map should be enough. Well, I'll think of something. |
I had another idea how a design for this could look like. What if we extend the builder of the Akka async client with something like We can also decide if we want to fail (exception), if an endpoint is not in the map or fallback to the sharedPool. This approach makes it configurable for the user and avoid the potential synchronization performance penalty. WDYT? |
I think it can be done, the only problem here is that the user would need to know which domains he needs to set up. Each AWS service has a different domain, also, using "fake aws" also implies in using different endpoints. Instead of using a syncronized map we could use an actor to handle the pools: //if the pool does not exist, it's created here
val pool = (pools ? Gimme(domain)).mapTo[Pool]
for {
p <- pool
r <- p.offer(request, promise)
//check `r` if the request is queued
} yield promise.future I ran a POC over here and it worked quite well, but, hard to measure any performance pernalty over the |
With the current implementation a shared connection pool per
ActorSystem
is used for all requests.Its probably better to have a dedicated connection pool per Host.
See akka/alpakka#1958 and akka/alpakka#1983 for similar issue and PR.
The text was updated successfully, but these errors were encountered: