Comments (4)
I have a few comments about this indeed.
I found that in practice (in my work, I can be biased), Aleph's approach to having a separate queue for acquiring connections is unnecessary. Caching connections is vital because you can't keep creating and disposing them at a high rate (due to TIME_WAIT), but limiting the total number of them is not as important. I personally set the connection limit to 16k per host and pool queue size to 0, so that a fresh connection is immediately created for the acquirer each time there are no free connections in the pool, up until the limit is hit at which point it's an error.
There are some cases where you would use the pool with the queue as a parallelism controller. I think all those cases could be rewritten to something like Semaphores if Aleph connection pools offered no queueing.
So, this is my take. In my world, the breaking Aleph2 would have connection pools with no acquisition queues. Such pools are much much easier to implement, way more performant at high loads, and give the user one less option and timeout to think about. But I understand that people can have other usecases where this won't fly.
from aleph.
Sorry I haven't answered the original question. I think the current behavior is fine. I doubt anybody fine-tunes :pool-timeout
and handles it somehow specially, it is an awkward option to give to the user and work with.
from aleph.
Thanks for chiming in @alexander-yakushev, very good insights! I agree that the acquire queue and timeout are quite awkward and needlessly complicate matters. I also agree that limiting parallelism should rather be handled by the caller/application itself. For example, if I'm already using core.async
, I'd rather use that instead of having to also deal with RejectedExecutionException
and PoolTimeoutException
. I wonder whether this must necessarily be considered a breaking change: Most users probably won't notice much of a difference and, as pointed out by @KingMob, they will already have to deal with exceptions due connection exhaustion in some manner anyway. And we could just keep around the old pool implementation (maybe move to a namespace which isn't loaded by default) so users who do rely on that specific behavior can still swap it back in. I filed #716 to track this idea.
As for status quo: Given all of the above, I think it's indeed fine to keep the behavior as-is. Closing but @KingMob feel free to re-open if you'd still like to see a change!
from aleph.
Roping in @alexander-yakushev in case they have a comment.
It would be nice to cancel the pending acquire if it's taken too long, but it would also be fine w me to xform the rejected ex into a pool timeout ex.
If you exhaust all conns in reality, you're going to get exceptions of some sort.
from aleph.
Related Issues (20)
- Add support for `wrap-decompression` middleware HOT 9
- Please bump netty versions because of CVE-2023-34462 HOT 1
- Enable endpoint identification (aka hostname verification) for TLS clients by default? HOT 9
- Look into new Ring websocket support for Aleph HOT 2
- Add write backpressure by checking Channel writability
- Add support for aggregating all inbound data before calling server Ring handler HOT 2
- Default rejected-handler will leak buffers in raw stream HTTP servers HOT 1
- Overhaul docstring formatting for consistency HOT 2
- Hide application protocol config from users with `http-versions`
- Who uses Aleph? Add your name to this, we'd like to know HOT 4
- Reconsider `:aleph/`-namespaced keywords HOT 3
- io.netty.channel.AbstractChannelHandlerContext invokeExceptionCaught HOT 2
- 0.7.0-rc1 is crashing without brotli4j dependency #3530 HOT 2
- Treat de/compression asymmetrically in H2
- Track down potential idle-handler refcount testing leak HOT 11
- Question about single server process using both non-ssl and ssl HOT 3
- Support cancellation of HTTP requests HOT 2
- Drop HTTP client connection pool's acquire queue HOT 1
- CVE-2024-29025 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aleph.