[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [servlet-dev] [jakartaee-platform-dev] What do we exactly dislike in Servlet?
|
On 26/08/2022 03:52, Greg Wilkins wrote:
On Wed, 24 Aug 2022 at 20:01, Mark Thomas <markt@xxxxxxxxxx
<mailto:markt@xxxxxxxxxx>> wrote:
If we start from the assumption that Loom is the future (the first step
may actually be to debate that assumption)....
So let's start with that debate.
+1
I do understand that async code is difficult and mostly full of bugs. I
do understand the desire to just write blocking code. I also think
that the vast majority of applications written really don't care one way
or the other. So I get why Loom is attractive.
+1
But what nobody has been able to tell me, is why it will be different
this time around? The approach has been tried before with Green
threads and Solaris multitasking and ultimately failed, as described in
this paper from 2002 on Multithreading in Solaris
<https://webtide.com/wp-content/uploads/2020/12/multithread.pdf>. I
cannot see in Loom any innovations that will generally solve the
problems of m:n scheduling outlined in that paper.
The question for me is to what extent the problems with the generic case
outlined in that paper apply in this specific case.
Thus I consider that Loom is at best a better implementation of Green
threads with really good integration into the JVM and its libraries.
This is not a bad thing and will probably be an excellent solution for
the vast majority of applications, for which the benefits of simple
blocking code will far outweigh any downsides with striving for the
ultimate scheduling efficiencies.
Exactly.
To re-phrase my question above: What is the scope of the minority of
cases for Servlet based web applications where this approach does not work.
So, if we were talking about designing a new general purpose application
API, then I think a blocking only approach that depends on Loom for
scale would be viable for the vast majority of use-cases.
+1
But we are not talking about an application API. The proposal being
discussed here is for a low level HTTP API: just the minimum to get HTTP
messages efficiently received and sent, that can be used as the basis
for various application frameworks and/or very specific direct usages.
To put all our eggs in the Loom basket for such an API would be to make
the bet that Loom will be sufficient and optimal for not just most, but
all HTTP usages in java. I don't think that Loom can claim to be that
general of a solution.
I don't think async can make that claim either. There are always going
to be edge cases where one approach is better than the other. And a huge
overlap in the middle where there is very little distinction to draw
between either approach.
Re-phrasing my question again: What are the relative sizes of scopes of
use cases for Servlet based web applications where one approach (async
or Loom) is clearly more optimal than the other.
Thus I advocate that any new low level HTTP API should be asynchronous
only with the aim being the simplest API to send/receive HTTP messages
in java using current best practices of the language. The design
should allow for both simple implementations and optimized
implementations (e.g supporting memory mapped files, gather writes,
etc.). Application APIs can be layered on top and they may be blocking
and dependent on Loom if they wish. Note that implementing a blocking
Loom application API on top of an async HTTP API is trivial, whilst the
opposite is impossible (mmm maybe pointless is a better word).
I agree it is pointless in the sense that it isn't going to improve
performance. The point may be to provide backwards compatibility and in
that case it is important that it is possible - and I agree that it is
possible.
There is a trade-off involved here. The benefits of the simplicity of
blocking code with Loom vs the performance benefits of async. I'd be a
lot more comfortable with some relevant, objective data to help compare
the the two approaches. Are you aware of any work that looks at this in
the context of web applications? If not, I have some time available to
work on putting something together - WDYT?
Mark