Yeah that's one area Java has always been a little weak with - I know of
none Java systems where you can monitor requests and if one is taking much
too long or two many resources, you can just hard kill it. I'm not sure
there is much you can do java that's less ugly or more effective than just
have
I also think we should gate at the entry point (decide to process a
request, delay its processing or reject it) then do it as fast as possible
(and potentially decide to reject and abandon during processing if the
realization that it should have been rejected happens too late).
Slowing down process
I think the problem is that it’s just extremely difficult to reason about.
I think that’s really the root of the concern, and he’s generally working
with code that’s likely close to hardware ideal - a thread count not much
more than the number of cores at the high end. Here you have to reason
about
Thanks. I could see thread priority customization being used well in
combination with rate limiting so as to mitigate a starvation risk.
Yeah, I met Brian Goetz and have his excellent book.
~ David
On Sat, Jul 22, 2023 at 3:20 AM Mark Miller wrote:
> It’s a hint for the OS, so results can va
It’s a hint for the OS, so results can vary by platform. Not the end of the
world but not ideal.
A scarier fact is that Brian Goetz, pretty big name in Java concurrency,
recommends against in general, noting that it can lead to liveness /
starvation issues.
