Java 8 in a JEE Environment (original) (raw)

Brian Goetz brian.goetz at oracle.com
Tue Apr 16 12:11:07 PDT 2013

, but even at numbers much lower than that, if any of them intend to use parallelism at all, having so many threads competing for the CPUs undermines everyone's parallelism. As I understand, these pools should be fine-tuned at deployment time so to keep the total number of threads reasonable.

... at the cost of poor data-parallelism. (If you have to spin up a thread during a computation more than infrequently, you just pushed the breakeven out from a few thousand to a few million. Which brings us back to "better to just turn it off.")

This is a great argument for "just turn it off"! This framework was designed and optimized for CPU-intensive data-parallel operations; you want to use it for something that is the exact opposite of that, and along the way are willing to impose crushing performance penalties on those that are using it as intended. Then we come to the most relevant part of our discussion. If we are talking about CPU-intensive data-parallel operations only, and if we don't have a SPI for controlling how they are executed so another implementation could focus on the kind of Java EE taks I have mentioned above, the right decision might be documenting that database centric operations are out of scope and turn it off.

Glad to have come around to this. It really does come down to "what is this API for", and, like the elephant, is very easy to see different use cases as primary.

Its not that we are hostile to providing a friendly API to doing IO concurrently instead of serially -- that's a perfectly valid goal and I totally support it if it doesn't come at the expense of all the other use cases. Its just that is not the design center of FJ, and a good framework for IO-parallel operations would look very different from a good framework for data-parallel operations. Trying to turn the good data-parallel framework we've got into something that it isn't, at the cost of crippling what it is good at, seems silly.

I have a question, though: do you understand I am talking about operations that wait a lot for the database server to respond instead of exchanging large chunks of data most of the time?

Yes, though I still claim that this only one of multiple use cases where EE users might want to use parallelism, and we should be wary to extrapolate too much from this example. And, even here, you may well want some throttling -- you don't want to hit your upstream server with thousands of concurrent requests and have them get rejected. And the heuristics for setting pool sizes (and therefore throttling requests) for data-parallel operations are not really compatible with those for IO operations. And thread-per-request may not be the right resource model for IO-parallelism anyway.

Then JSR-238 should define a mechanism for this -- which is a different problem (and likely requires a different solution). I guess you mean JSR-236?

Yeah, can never keep these straight.

More information about the lambda-dev mailing list