[jeffbee]

Unbounded thread pools are bad, bounded thread pool executors with unbounded work queues are bad, and bounded thread pools with bounded queues, FIFO policies, and silent drops are also bad. There are many bad ways to do this.

[dimitrov]

> and bounded thread pools with bounded queues, FIFO policies, and silent drops are also bad.

Care to elaborate please? Seems like the author is recommending unbounded thread pools with bounded queues for blocking IO. Isn't that pretty similar?

[jfoutz]

I can't speak for the parent, some things that stand out to me

1. k8s and bare metal, when you make a bunch of threads things get slower. with the FIFO case, you can have pending requests in the queue that don't get their connection canceled event, and the same user puts another request in the queue.

2. Silently dropping is bad, you want an alert - really you want an alert when you get close, so you can add more capacity

3. bounded queue with unbounded threads is really just an unbounded queue - a short line with a mob pushing to get in line

Then, you know, memory on k8s, pod gets OOM killed. that sucks cause you have to reschedule and restart. all the pending requests are dropped.

It's very easy to make something that works, but is actually quite detrimental when things are on fire. little extra gasoline helps get over the hills, but when things are on fire, gasoline makes a bigger fire.