On 10/20/22 05:28, Mark Thomas wrote:
On 20/10/2022 09:32, Rémy Maucherat wrote:


This is interesting since now is the best time to discuss long term plans.

We'll see if there are some scheduling gains with Loom ... But I don't
think thread scheduling was the problem in Tomcat. Maybe lock
concurrency but it seems these had been eliminated (or improved at
least). I still don't understand how it could possibly really work
though, right now it feels like asking if Windows 3 cooperative
multitasking could work (= it works as long as all apps and libraries
are perfectly coded and there's no bug whatsoever). Also having to
avoid native code is annoying (just when there's finally something
good like Panama ...).

I went through the Jakarta Servlet mailing list and there are some
discussions about Loom and a possible lower level API. It seems
there's a discussion between blocking and non blocking APIs. Well, IMO
we need both ...
- Blocking: For Loom. And mostly it could simply be
ServletRequest/Response/Cookie/IS/OS without any of the other items.
So it looks like everything is in there already.
- Async: Great if Loom isn't that appropriate for real work. However,
the listeners used for the Servlet API are not a very nice async API
(of course they are very appropriate as an extension for a blocking
API). So maybe that's where the new work is: come up with an async API

What do you think ?

There are a lot of dimensions to this problem space.

I have an initial implementation of the Loom module that supports the blocking parts of the Servlet API. I am currently working on the necessary refactoring to optimise that for Loom. I hope to get that committed later this week or early next.

My working assumption is that any benefits Loom can provide will be in the blocking API. I don't see any way Loom could support the async and non-blocking APIs without adding some overhead - even if that overhead is negligible.

Therefore, rather than moving on to try and implement support for the async and non-blocking parts of the Servlet API with the Loom connector, I'd like to spend some time exploring the performance of Loom with the blocking API. Hopefully, others here will also be able to undertake their own performance tests.

I have only tested a couple of scenarios that aren't particularly suited to Loom (requests to a simple servlet) and the results are increased CPU usage and reduced throughput with Loom compared to NIO. I want to look at some tests that are more tailored to demonstrate the benefits of Loom.

My expectation is that we will identify some scenarios where switching to the Loom module provides immediate benefits with no application changes. What will be interesting is how that compares to refactoring the application to use async and/or non-blocking.

The other question is the extent to which the refactoring I have completed so far is necessary. I am not seeing much benefit from the optimisations I am implementing. It may be that a much simpler approach of integrating Loom (essentially a custom executor) is good enough. Note that this may mean undoing some of the refactoring I am currently implementing in Tomcat 11.

Once we have that data, then I think we'll be in a position to decide the extent to which it makes sense to support Loom and whether or not to proceed and implement support for async and non-blocking in the Loom module.

There is clearly a demand for a lower-level HTTP API. The question for me at this point is whether that should be async based or blocking (Loom) based. Based on what I have seen so far, I think Greg Wilkins has called it correctly and that async will have the edge. However, that is more judgement/instinct than based on hard data. I want to see more data before making forming a final view.

Comet FTW?


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to