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? 
Greg,

On 03/09/2022 00:18, Greg Wilkins wrote:
On Fri, 2 Sept 2022 at 19:30, Mark Thomas <markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>> wrote: 

    On 26/08/2022 03:52, Greg Wilkins wrote:
     >
     > On Wed, 24 Aug 2022 at 20:01, Mark Thomas <markt@xxxxxxxxxx
    <mailto:markt@xxxxxxxxxx>
     > <mailto:markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>>> wrote:
     >


<snip/>
The general problem is to use multiple CPU cores to run M kernel threads to execute N virtual threads.    The issue being that the OS does the scheduling between cores and kernel threads and the user-space code must do the scheduling between kernel threads and virtual threads.   That paper indicated that it was a struggle to come up with a one size fits all scheduler and ultimately the attempt was abandonned in favour of simple 1:1 kernel threads.  Operating systems have since not reversed that decision to back away from M:N, so it is safe to assume that nothing new has been invented in this space.
Loom will perhaps have better integration into the JVM libraries with more/better scheduling points, but I've yet to see anything that indicates that they have solved the general problem.     I think it is up to Loom to prove that these issues no longer apply rather than for us to assume they have been solved.
Agree 100% that we shouldn't assume anything. I think there is benefit to us looking at this as it allows us to look at the aspects particularly relevant to the use cases we care about. 

<snip/>


    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.
This kind of hinges of what we mean by "Servlet" web applications.   If we think of servlets as an application development environment, then I think very few applications have issues with the blocking API.
But if we think of servlets as a protocol API that might be used to implement other applications frameworks, then I think there are more cases where the blocking API is not sufficient.  For example, some RESTful frameworks just want super efficient HTTP services and could not care less about the servlet API for application purposes.   I think it is precisely these use-cases that would be interested in a low level servlet API....  it follows that a significant proportion of the target use-case for a low level HTTP API will be interesting in maximal efficiency and scalability. 

Agreed.

<snip/>


    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.
Really?  What are some examples of low level HTTP usage that can't be efficiently serviced by an async API?   Sure there are many that don't justify the complexity of an async API, but given that there is normally a trivial async to blocking conversertion possible, what can't be done?
It is a very narrow edge case but if latency is the concern and scalability isn't then my experience is that a blocking approach has a (very) slim advantage.
I don't think async is a general application API, but I think it is the best you can get for a one size fits all for a protocol API.
If we are going to implement such an API in Servlet (and I do see the benefit of doing so) then given the complexity that comes along with async I'd like to be sure that the simpler, Loom based, blocking approach isn't viable first. 

<snip/>
I did some very rough benchmarks in my blog(s) on an early version of Loom: https://webtide.com/do-looms-claims-stack-up-part-1/ <https://webtide.com/do-looms-claims-stack-up-part-1/>  But more current and more thorough evaluation is needed.
Thanks for the pointers. I think repeating some of those benchmarks with the latest version of Loom would be a good place to start.
In terms of a more thorough evaluation, what did you have in mind? What sort of use case do you think async would handle better than Loom? I'd like to examine those to see if we can put some objective numbers on the differences and get some feedback from the OpenJDK folks. 

Cheers,

Mark

Back to the top