Skip to main content

[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


Back to the top