Quarkus & Project Loom

[Paul Carter-Brown]

Hi Quarkus team,

A lot of work in and around Quarkus (and a lot of libraries/frameworks) in recent years has been focussed on solving the C10k+ problem by using non-blocking edges and a reactive programming model. IMO, although reactive programming feels like the right solution for even streaming and event processing, it's hard to argue that it's as readable and simple to write as basic imperative code when it comes to things like ReST services and database access.

Having said that though, Quarkus has the tooling to write almost anything in a reactive style (Resteasy reactive, Hibernate Reactive etc etc). In our projects, it's tempting to jump right in and adopt this style as it would solve the C10k+ problem but it has it's negatives in terms of complexity, debugging and developer adoption. What are your thoughts on this? Is it not worth waiting for Loom and in the meantime write as little reactive code as possible (e.g. only at bottlenecks). I'm wondering if in 5 years time, the focus on reactive programming will die away in favour of imperative and letting Loom handle the underlying threading. Will we look back and think that the effort in migrating simple working imperative code to reactive was the wrong solution to the problem?

What are your thoughts and what is Quarkus's strategy around this? I know Jetty have been quite involved in using the Loom beta implementations to see the changes and impact in moving to the more lightweight threading model. What role will Netty/Vertx play and what changes would be necessary in a Loom-future?

Just some pondering I've been doing and wondering if the Quarkus community has any thoughts on this?

Paul

[Georgios Andrianakis]

Hi Paul,

My personal opinion is that in most cases, as developers we should focus on what the best way to serve our users is now and as you say, by far the best way to scale today is using non-blocking IO and reactive style programming.

Loom seems to promise a lot, but there are two issues I see:

1) We just don't know which Java LTS release will include it (I am only considering LTS releases here as the data shows that most applications will not be deployed to production with a non-LTS release JVM). It could potentially be a long time...

2) Although the promise of millions of virtual threads is great, we have yet to see how that will perform in practice with libraries and frameworks that have a large stack. It could turn out to be the case that the memory consumed for such use cases ends up preventing the use of millions of virtual threads.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAO8YPTTAhq%2BiSgLy0BtV3bNATtGu2064fcCsddVAofgfycw-rA%40mail.gmail.com.

[clement escoffier]

Hello,

I totally agree with Georgios. Let me add a few more things.

We are looking at Loom very closely, and I even have done tests. 

Having a synchronous development model "magically" using non-blocking I/O is awesome... until a certain point. 

Loom introduces virtual threads, but these threads are run by carrier threads (which are regular process threads). Unfortunately, most of my "not hello word" tests have shown that you can easily block these carrier threads if you are not very careful. Typically, last time I checked I was unable to get any JDBC drivers working properly because of this. Blocking the carrier threads can have important consequences. I'm sure Loom will improve and that situation won't be so likely - but for now, it seems to be the case. Also, we have been able to use most of our existing reactive ecosystem using Loom (our Mutiny API proposes ways to block and in the loom context, only block the virtual thread). These constructs do not block the carrier threads, but, it introduces multiple thread switch between the event loop and the carrier threads. 

Also, reactive is not limited to CK10. Reactive is a lot more than this, and it becomes quite powerful to implement event-driven or message-driven applications too. 

Clement

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-neJ5vo%2BhYUmz_w4YiTOONbpzwo73ySkD9iU2ta-M%2B7QA%40mail.gmail.com.

[Emmanuel Bernard]

There are some good thoughts by Greg from Jetty as well on the subject

https://webtide.com/do-looms-claims-stack-up-part-1/

https://webtide.com/do-looms-claims-stack-up-part-2/

Long but worth reading. Some short inputs from these articles:

- loom can do 1000000 threads yes but with a relatively small stack, otherwise it will blow up with the stak taking too much memory.

- related to that it puts pressure on the GC due to lots of objects being created

- loom does not replace object pool usages for contended resources (besides treads) DB, memory, CPU limits all msut be kept in control somehow.

- virtual threads not optimized for threadlocals yet

- virtual threads not necessarily the right unit of scaling

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKW6fidQq3CpQpHi83n%2BczUt_ePrX5uOVEyeCLumMk2zbfAZjQ%40mail.gmail.com.

[Jason Greene]

Just to add to what the others have said. While we continue to examine loom’s progress, we do not see it as mutually exclusive the reactive. As mentioned, big gain we would get from loom would be the ability to provide a continuation model as an isolated block that would give you a simplified API when bridging async and sync. The memory and stack issues mentioned  would preclude using it end-to-end on the full stack. But, more importantly, a number of use cases are still better suited to reactive APIs. Some examples including data streaming and messaging where you tend to work with well defined “chunked” payloads in memory. 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CANYWk7Nkg6Fsd4kYRPJO45OO6w9U7QQVr%2BG19dSeb7xU_Q5HpQ%40mail.gmail.com.

[Max Rydahl Andersen]

And to just chime in with my angle on this:

Loom looks very interesting; but it is not available anytime soon
and even when it arrives some reactive/async code would probably still pop up.
Thus at the moment I see it as when it arrives we would have for a while at least
three approaches traditional imperative, imperative+loom and reactive.

If you want to hold back and stay on traditional imperative then that
is a perfectly valid choice. It works fine for many usecases and done so for years in the past
and will do so for years in the future. It will just not give you the same concurrency
as what is possible with the reactive approach in Quarkus.

For some usecases either is perfectly fine and its one of things I underline
when talking about Quarkus - you can choose the programming model that fits your
team AND your usecase.

/max

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAO8YPTTAhq%2BiSgLy0BtV3bNATtGu2064fcCsddVAofgfycw-rA%40mail.gmail.com.

/max
https://xam.dk/about

[Ken Yee]

Related but curious what you think about kotlin coroutines? Same almost imperative code as Loom and fairly battle tested at this point... But not Java 🙂

[clement escoffier]

Le mer. 20 janv. 2021 à 02:32, Ken Yee <ken...@gmail.com> a écrit :

Related but curious what you think about kotlin coroutines? Same almost imperative code as Loom and fairly battle tested at this point... But not Java 🙂

Kotlin Co-Routines do not use the same mechanism as Loom (well, there are not in the JVM). They use advanced code-rewriting (basically rewrite the code using a continuation style). I like them a lot, and from a Quarkus POV, we are improving our support.

In the last Mutiny release, we have the first kotlin support and we will soon extend that.

Clement

 

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CANhb1xbnme1%2BHzirsDKP6gsw4Rn%3DNNtcH1wysgB-v9roc3RvPQ%40mail.gmail.com.

[Andy Damevin]

Loving it! This conversation should be turned into a blog post :)

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKW6fieoSV8PonqZ%2B1GdOnNXZfLv3NCOyj6H_%3Dzcbeg4h1V%2BHQ%40mail.gmail.com.

--

Andy Damevin

[Max Rydahl Andersen]

I like kotlin co-routines, I just don't like it is in a language supported by one company and one tool vendor.

Still, I'm happy to see Quarkus support in/around Kotlin is growing.

/max

/max
https://xam.dk/about

[Ladislav Thon]

st 20. 1. 2021 v 11:16 odesílatel Max Rydahl Andersen <mand...@redhat.com> napsal:

I like kotlin co-routines, I just don't like it is in a language supported by one company and one tool vendor.

Still, I'm happy to see Quarkus support in/around Kotlin is growing.

Technically, it isn't: https://kotlinlang.org/foundation/kotlin-foundation.html

It's easy to see why one would think that, though.

LT

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/E7862CAE-1762-4B4F-847E-007EB3106FEF%40redhat.com.

[Max Rydahl Andersen]

On 20 Jan 2021, at 11:26, Ladislav Thon wrote:

> st 20. 1. 2021 v 11:16 odesílatel Max Rydahl Andersen
> <mand...@redhat.com>
> napsal:
>
>> I like kotlin co-routines, I just don't like it is in a language
>> supported
>> by one company and one tool vendor.
>>
>> Still, I'm happy to see Quarkus support in/around Kotlin is growing.
>>
>
> Technically, it isn't:
> https://kotlinlang.org/foundation/kotlin-foundation.html
>
> It's easy to see why one would think that, though.

Practically it is.

I haven't seen other tools nor companies successfully push/support
kotlin than for jetbrains/google ecosystem.

/max

>>>> <https://groups.google.com/d/msgid/quarkus-dev/CANhb1xbnme1%2BHzirsDKP6gsw4Rn%3DNNtcH1wysgB-v9roc3RvPQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .

>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "Quarkus Development mailing list" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> email to quarkus-dev...@googlegroups.com.
>>> To view this discussion on the web visit

>>> https://groups.google.com/d/msgid/quarkus-dev/CAKW6fieoSV8PonqZ%2B1GdOnNXZfLv3NCOyj6H_%3Dzcbeg4h1V%2BHQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/quarkus-dev/CAKW6fieoSV8PonqZ%2B1GdOnNXZfLv3NCOyj6H_%3Dzcbeg4h1V%2BHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>>
>>
>> --
>> Andy Damevin
>>
>> /max
>> https://xam.dk/about
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Quarkus Development mailing list" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> email to quarkus-dev...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/quarkus-dev/E7862CAE-1762-4B4F-847E-007EB3106FEF%40redhat.com

>> <https://groups.google.com/d/msgid/quarkus-dev/E7862CAE-1762-4B4F-847E-007EB3106FEF%40redhat.com?utm_medium=email&utm_source=footer>
>> .
>>


/max
https://xam.dk/about

[William Burke]

On Tue, Jan 19, 2021 at 5:11 PM Max Rydahl Andersen <mand...@redhat.com> wrote:

And to just chime in with my angle on this:

Loom looks very interesting; but it is not available anytime soon
and even when it arrives some reactive/async code would probably still pop up.
Thus at the moment I see it as when it arrives we would have for a while at least
three approaches traditional imperative, imperative+loom and reactive.

If you want to hold back and stay on traditional imperative then that
is a perfectly valid choice. It works fine for many usecases and done so for years in the past
and will do so for years in the future. It will just not give you the same concurrency
as what is possible with the reactive approach in Quarkus.

IMO, imperative is not only perfectly valid for many cases, but for most/all cases that aren't purely event driven.  I would go as far to say that reactive mainly became popular because of the browser's lack of threads (2).  This required a specific programming model in Javascript which the server side inherited when Node became popular.  A classic case of marketing where a weakness in the platform was redefined, remarketed, and touted as a strength.  That's my Quarkus-Anon conspiracy theory of the week and I'm sticking to it and will not listen to any other opinion because "people are saying" that this is true ;-)

[Paul Carter-Brown]

That's about the best explanation I've ever read for the quagmire that is reactive coding :-)

I never thought I would find yet another reason for disliking javascript as much as I do. It's ideas polluted Java.

(Running for cover)

[Alboz]

That blog has been debunked by Ron Pressler on Reddit and in the JDK mailing lists. Effectively the post just proves pretty much all the claims about Loom, other than finding a couple of defects that are being addressed. 

Ron Pressler reply: https://www.reddit.com/r/java/comments/kmn6m3/do_looms_claims_stack_up_part_1_millions_of/ghfyhq8/?utm_source=share&utm_medium=ios_app&utm_name=iossmf&context=3

OpenJDK discussion: https://mail.openjdk.java.net/pipermail/loom-dev/2021-January/thread.html

Guys you're spending the bucks fighting the wrong war. You're 10 years late to the "reactive party" which has been shown to be an anti-pattern for 99% of the use cases.

Project Loom is the future of the JVM, Oracle stopped producing the "Reactive JDBC" because understood this well. Go and Erlang are the right inspiration to follow. 

Even C# "async/await" (which is 10 times cleaner than a reactive framework) still feels wrong.

[Alboz]

Can you please let us know how can you block "Carrier Threads"?. If you managed to do so, you've just uncovered a bug, which is understandable at this stage. Did you report it?

JDBC drivers are being "loomified", otherwise the effort would be pointless. See https://www.postgresql-archive.org/Project-Loom-Fibers-Oracle-stopping-work-on-ADBA-td6104816.html

[Georgios Andrianakis]

On Wed, Jan 20, 2021 at 11:14 PM Alboz <albi...@gmail.com> wrote:

That blog has been debunked by Ron Pressler on Reddit and in the JDK mailing lists. Effectively the post just proves pretty much all the claims about Loom, other than finding a couple of defects that are being addressed. 

Ron Pressler reply: https://www.reddit.com/r/java/comments/kmn6m3/do_looms_claims_stack_up_part_1_millions_of/ghfyhq8/?utm_source=share&utm_medium=ios_app&utm_name=iossmf&context=3

OpenJDK discussion: https://mail.openjdk.java.net/pipermail/loom-dev/2021-January/thread.html

Guys you're spending the bucks fighting the wrong war. You're 10 years late to the "reactive party" which has been shown to be an anti-pattern for 99% of the use cases.

10 years late to what party?

Also, where is the data claiming that reactive is an anti-pattern in 99% of the use cases?

Project Loom is the future of the JVM, Oracle stopped producing the "Reactive JDBC" because understood this well. Go and Erlang are the right inspiration to follow. 

Even C# "async/await" (which is 10 times cleaner than a reactive framework) still feels wrong.

Even if one were to have absolute faith that Loom will miraculously cure all the scaling and programming model problems (and I have yet to meet any such people), you are saying that folks should not do anything to improve the current state of the art today?  

What are people that actually do need to get the best throughput possible supposed to do until Loom lands?

And when it does, who says people are going to start using it immediately? If current data is anything to go by, widespread adoption of any new JDK will take a long time...

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/3a24cb76-37db-4205-8246-4ed2c3878588n%40googlegroups.com.

[Sergey Beryozkin]

Hey Georgios

Sometimes the arguments just don't work if some users think they can join this forum and with a few dismissive claims disregard all the arguments from the reactive/performance industry experts in this team.

My 2c

Thanks, Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-miyC-TwzB9%3DDKs40Dwvs%3DKmHVdKBrE_iGnONiG5Vxjpw%40mail.gmail.com.

[Jason Greene]

On Jan 20, 2021, at 3:14 PM, Alboz <albi...@gmail.com> wrote:

Guys you're spending the bucks fighting the wrong war. You're 10 years late to the "reactive party" which has been shown to be an anti-pattern for 99% of the use cases.

Ah, but thats thing. We aren’t in a war, and see no point in a purity test on this front. Quarkus enables both reactive and imperative programming models (including mixing). Both are important, and both have preferred use cases. Loom is no different on this front.  

Developers should be able to pick the best i/o approach for the job without us forcing it on them (or if its a wash, their favorite l! :) ) 

-Jason

[Alboz]

We had a long discussion in the chat, and we agreed to disagree :).  Just here for the record and readers:

On Wednesday, January 20, 2021 at 9:27:08 PM UTC gand...@redhat.com wrote:

On Wed, Jan 20, 2021 at 11:14 PM Alboz <albi...@gmail.com> wrote:

That blog has been debunked by Ron Pressler on Reddit and in the JDK mailing lists. Effectively the post just proves pretty much all the claims about Loom, other than finding a couple of defects that are being addressed. 

Ron Pressler reply: https://www.reddit.com/r/java/comments/kmn6m3/do_looms_claims_stack_up_part_1_millions_of/ghfyhq8/?utm_source=share&utm_medium=ios_app&utm_name=iossmf&context=3

OpenJDK discussion: https://mail.openjdk.java.net/pipermail/loom-dev/2021-January/thread.html

Guys you're spending the bucks fighting the wrong war. You're 10 years late to the "reactive party" which has been shown to be an anti-pattern for 99% of the use cases.

10 years late to what party? 

To the party of building "Reactive" Libraries and "Reactive" Frameworks. It's been done, we all know the benefits and pains :). Why spend more effort on it instead of focusing on the future which for the JVM is Loom?

 

Also, where is the data claiming that reactive is an anti-pattern in 99% of the use cases?

Project Loom is the future of the JVM, Oracle stopped producing the "Reactive JDBC" because understood this well. Go and Erlang are the right inspiration to follow. 

Even C# "async/await" (which is 10 times cleaner than a reactive framework) still feels wrong.

Nurkiewicz:  https://www.youtube.com/watch?v=g_JyHJ20Iog 

Author of RxJava together with "Erik Meijer" and "Ben Christiansen": https://www.amazon.co.uk/Reactive-Programming-RxJava-Tomasz-Nurkiewicz/dp/1491931655 

Sure, 99% was just to emphasize the idea that after Loom, building Java Web applications that might really need reactive frameworks is going to be a niche area. 

 

Even if one were to have absolute faith that Loom will miraculously cure all the scaling and programming model problems (and I have yet to meet any such people), you are saying that folks should not do anything to improve the current state of the art today?  

What are people that actually do need to get the best throughput possible supposed to do until Loom lands?

And when it does, who says people are going to start using it immediately? If current data is anything to go by, widespread adoption of any new JDK will take a long time...

My point is: "Today" there are already solutions in place, no need for Quarkus to spend effort on it. Quarkus is built on VertX, we have the reactive-routes (same as Helidon or Micronaut).

Isn't that enough effort spent on Reactive?

The time spent on "Mutiny" and "Reactive RestEasy" could be spent in optimizing(or making more robust) the current frameworks (RestEasy) and other extensions. Preparing to Project Loom, making sure that QUarkus users would get the maximum benefit from it (Helidon has started the journey).

Who uses "Microprofile" does so because of the beauty of the API, the simplicity of reading and debugging simple blocking code. 

The speed of adoption of new JDKs depends on how "appealable" it is to consumers/end users. A JDK with Loom would be even more than JDK8 (my opinion).

 

[Stuart Douglas]

On Thu, 21 Jan 2021 at 11:22, Alboz <albi...@gmail.com> wrote:

We had a long discussion in the chat, and we agreed to disagree :).  Just here for the record and readers:

On Wednesday, January 20, 2021 at 9:27:08 PM UTC gand...@redhat.com wrote:

On Wed, Jan 20, 2021 at 11:14 PM Alboz <albi...@gmail.com> wrote:

That blog has been debunked by Ron Pressler on Reddit and in the JDK mailing lists. Effectively the post just proves pretty much all the claims about Loom, other than finding a couple of defects that are being addressed. 

Ron Pressler reply: https://www.reddit.com/r/java/comments/kmn6m3/do_looms_claims_stack_up_part_1_millions_of/ghfyhq8/?utm_source=share&utm_medium=ios_app&utm_name=iossmf&context=3

OpenJDK discussion: https://mail.openjdk.java.net/pipermail/loom-dev/2021-January/thread.html

Guys you're spending the bucks fighting the wrong war. You're 10 years late to the "reactive party" which has been shown to be an anti-pattern for 99% of the use cases.

10 years late to what party? 

To the party of building "Reactive" Libraries and "Reactive" Frameworks. It's been done, we all know the benefits and pains :). Why spend more effort on it instead of focusing on the future which for the JVM is Loom?

RESTEasy Reactive is designed to work in a blocking manner as well, and was designed with loom in mind. It's handler loop based architecture means that you have very short stack traces, so suspend and resume of virtual threads should be much cheaper than with more traditional designs.

Stuart

 

 

Also, where is the data claiming that reactive is an anti-pattern in 99% of the use cases?

Project Loom is the future of the JVM, Oracle stopped producing the "Reactive JDBC" because understood this well. Go and Erlang are the right inspiration to follow. 

Even C# "async/await" (which is 10 times cleaner than a reactive framework) still feels wrong.

Nurkiewicz:  https://www.youtube.com/watch?v=g_JyHJ20Iog 

Author of RxJava together with "Erik Meijer" and "Ben Christiansen": https://www.amazon.co.uk/Reactive-Programming-RxJava-Tomasz-Nurkiewicz/dp/1491931655 

Sure, 99% was just to emphasize the idea that after Loom, building Java Web applications that might really need reactive frameworks is going to be a niche area. 

 

Even if one were to have absolute faith that Loom will miraculously cure all the scaling and programming model problems (and I have yet to meet any such people), you are saying that folks should not do anything to improve the current state of the art today?  

What are people that actually do need to get the best throughput possible supposed to do until Loom lands?

And when it does, who says people are going to start using it immediately? If current data is anything to go by, widespread adoption of any new JDK will take a long time...

My point is: "Today" there are already solutions in place, no need for Quarkus to spend effort on it. Quarkus is built on VertX, we have the reactive-routes (same as Helidon or Micronaut).

Isn't that enough effort spent on Reactive?

The time spent on "Mutiny" and "Reactive RestEasy" could be spent in optimizing(or making more robust) the current frameworks (RestEasy) and other extensions. Preparing to Project Loom, making sure that QUarkus users would get the maximum benefit from it (Helidon has started the journey).

Who uses "Microprofile" does so because of the beauty of the API, the simplicity of reading and debugging simple blocking code. 

The speed of adoption of new JDKs depends on how "appealable" it is to consumers/end users. A JDK with Loom would be even more than JDK8 (my opinion).

 

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/48c6e6d1-28a0-4110-83a3-89bc06854d93n%40googlegroups.com.

[Paul Carter-Brown]

Agree with Stuart. I have used Resteasy reactive not cause I necessarily want to code reactively but because the re-architecting of how it fits onto vertx has made it much faster than the previous resteasy module and it has some neat new features.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cz2Wk5H2S4XD98TX4hw7tsRCWzoOPFujoUv63st8%2BWM%3DQ%40mail.gmail.com.

[Stuart Douglas]

On Thu, 21 Jan 2021 at 11:24, Stuart Douglas <sdou...@redhat.com> wrote:

On Thu, 21 Jan 2021 at 11:22, Alboz <albi...@gmail.com> wrote:

We had a long discussion in the chat, and we agreed to disagree :).  Just here for the record and readers:

On Wednesday, January 20, 2021 at 9:27:08 PM UTC gand...@redhat.com wrote:

On Wed, Jan 20, 2021 at 11:14 PM Alboz <albi...@gmail.com> wrote:

That blog has been debunked by Ron Pressler on Reddit and in the JDK mailing lists. Effectively the post just proves pretty much all the claims about Loom, other than finding a couple of defects that are being addressed. 

Ron Pressler reply: https://www.reddit.com/r/java/comments/kmn6m3/do_looms_claims_stack_up_part_1_millions_of/ghfyhq8/?utm_source=share&utm_medium=ios_app&utm_name=iossmf&context=3

OpenJDK discussion: https://mail.openjdk.java.net/pipermail/loom-dev/2021-January/thread.html

Guys you're spending the bucks fighting the wrong war. You're 10 years late to the "reactive party" which has been shown to be an anti-pattern for 99% of the use cases.

10 years late to what party? 

To the party of building "Reactive" Libraries and "Reactive" Frameworks. It's been done, we all know the benefits and pains :). Why spend more effort on it instead of focusing on the future which for the JVM is Loom?

RESTEasy Reactive is designed to work in a blocking manner as well, and was designed with loom in mind. It's handler loop based architecture means that you have very short stack traces, so suspend and resume of virtual threads should be much cheaper than with more traditional designs.

To give you an idea the stack in RR invoking a blocking method is 4 lines deep (excluding the executor, which would not be present under loom):

        at org.acme.GreetingResource.hello(GreetingResource.java:30)
        at org.acme.GreetingResource$quarkusrestinvoker$hello_e747664148511e1e5212d3e0f4b40d45c56ab8a1.invoke(GreetingResource$quarkusrestinvoker$hello_e747664148511e1e5212d3e0f4b40d45c56ab8a1.zig:33)
        at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
        at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:7)
        at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:108)

This will work really well with loom, as there is no real stack state to save/restore each time.

[William Burke]

I'm very skeptical that there are many users out there that need this ultimate scalability (for react or loom), especially in the world of cheap virtual cloud computing.  The biggest challenge that Java has is not concurrency or io, its memory.  Unless Loom is going to be available via a native compiler like Graal, Java will continue to be squeezed by less performant languages/VMs that run in a much smaller footprint.  We're having a massive explosion of deployments with functions/lambdas.  We need massive work in the JVM to reduce memory usage, metaspace, etc.   That should be the real focus and challenge.  I mean, I hope Loom kills reactive Java, but I still think it was the wrong focus.

[Ken Yee]

"biggest challenge that Java has is not concurrency or io, its memory"

+1 this and compile time.

I recently wrote some simpler APIs in Golang for the first time ever and the compile/iteration times were ridiculously fast even if it's a much cruder language: I'd say that is the #2.  The runtime optimization snapshots should help the runtime speeds of graalvm/aot which is #3.

I think they had to do Loom to compete with kotlin coroutines though...imperative light threads...

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjQQkdJNgmyvDFZfNjiMAVXfqi--TMzrM8ZK1wN4F7CQhQ%40mail.gmail.com.

[Alboz]

I'm very skeptical that there are many users out there that need this ultimate scalability (for react or loom), especially in the world of cheap virtual cloud computing.  The biggest challenge that Java has is not concurrency or io, its memory.  Unless Loom is going to be available via a native compiler like Graal, Java will continue to be squeezed by less performant languages/VMs that run in a much smaller footprint.  We're having a massive explosion of deployments with functions/lambdas.  We need massive work in the JVM to reduce memory usage, metaspace, etc.   That should be the real focus and challenge.  I mean, I hope Loom kills reactive Java, but I still think it was the wrong focus.

We are on Azure, and it's not cheap at all. The thing is, with Loom it comes for free, I keep writing simple blocking code and the environment does it for me.

I agree with you on memory, that is a big challenge, indeed frameworks and the JDK should optimize for that. There have been some good optimizations on the JDK side between JDK 11 and JDK15. I would expect Graal to add support for Loom at some point, and that would be a double win. They've also started "Project Leyden" to work on this (https://www.infoq.com/news/2020/05/java-leyden/)

Regarding Lambdas/Functions/Serverless: If the focus is "cold start-up time" then Java would not be able to compete with languages like Rust, AssemblyScript, etc. Many companies do not use Lambdas because they also sell their product "on-premise" or because they don't want to be locked with a certain provider. 

Supporting serverless deployment with Quarkus (non-preview) would be nice.

 

[Alboz]

On Thursday, January 21, 2021 at 11:52:50 AM UTC ken...@gmail.com wrote:

"biggest challenge that Java has is not concurrency or io, its memory"

+1 this and compile time.

I recently wrote some simpler APIs in Golang for the first time ever and the compile/iteration times were ridiculously fast even if it's a much cruder language: I'd say that is the #2.  The runtime optimization snapshots should help the runtime speeds of graalvm/aot which is #3.

Slow Compilation/iteration time? I'm not sure what are you talking about?

With Quarkus you just write code, no need to press any "compile/deploy" button. I doubt there is anything else out there as productive. 

Developer friendliness is one of the top reasons why we picked Quarkus.

[Alboz]

On Thursday, January 21, 2021 at 12:40:26 AM UTC sdou...@redhat.com wrote:

RESTEasy Reactive is designed to work in a blocking manner as well, and was designed with loom in mind. It's handler loop based architecture means that you have very short stack traces, so suspend and resume of virtual threads should be much cheaper than with more traditional designs.

To give you an idea the stack in RR invoking a blocking method is 4 lines deep (excluding the executor, which would not be present under loom):

        at org.acme.GreetingResource.hello(GreetingResource.java:30)
        at org.acme.GreetingResource$quarkusrestinvoker$hello_e747664148511e1e5212d3e0f4b40d45c56ab8a1.invoke(GreetingResource$quarkusrestinvoker$hello_e747664148511e1e5212d3e0f4b40d45c56ab8a1.zig:33)
        at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
        at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:7)
        at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:108)

This will work really well with loom, as there is no real stack state to save/restore each time.

 

Stuart that is good to hear (Georgios also said the same thing). "Assuming" that your measurements for @Blocking ReastEasy reactive are correct:

Why would that be more performant than classical RestEasy? I can see two reasons:

1. RestEasy Reactive is a better implementation with better optimizations
2. RestEasy Reactive has a restricted set of features compared to classic RestEasy and it's not really RestEasy or a JAX-RS implementation.

If 1 is true, then shouldn't you merge this code and this becomes the "new RestEasy classic" so that every project running on JBoss/Wildfly takes advantage of that too?

If 2 is true then the comparison might not  be fair :)

 

[Ken Yee]

"With Quarkus you just write code, no need to press any "compile/deploy" button. I doubt there is anything else out there as productive. "

Totally agree with that.. Other Java dev environments are worse..

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/80d2efcc-f677-4e16-8cca-64241a63b339n%40googlegroups.com.

[Georgios Andrianakis]

On Thu, Jan 21, 2021 at 2:35 PM Alboz <albi...@gmail.com> wrote:

On Thursday, January 21, 2021 at 12:40:26 AM UTC sdou...@redhat.com wrote:

RESTEasy Reactive is designed to work in a blocking manner as well, and was designed with loom in mind. It's handler loop based architecture means that you have very short stack traces, so suspend and resume of virtual threads should be much cheaper than with more traditional designs.

To give you an idea the stack in RR invoking a blocking method is 4 lines deep (excluding the executor, which would not be present under loom):

        at org.acme.GreetingResource.hello(GreetingResource.java:30)
        at org.acme.GreetingResource$quarkusrestinvoker$hello_e747664148511e1e5212d3e0f4b40d45c56ab8a1.invoke(GreetingResource$quarkusrestinvoker$hello_e747664148511e1e5212d3e0f4b40d45c56ab8a1.zig:33)
        at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
        at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:7)
        at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:108)

This will work really well with loom, as there is no real stack state to save/restore each time.

 

Stuart that is good to hear (Georgios also said the same thing). "Assuming" that your measurements for @Blocking ReastEasy reactive are correct:

Why would that be more performant than classical RestEasy? I can see two reasons:

1. RestEasy Reactive is a better implementation with better optimizations
2. RestEasy Reactive has a restricted set of features compared to classic RestEasy and it's not really RestEasy or a JAX-RS implementation.

There are a few basic reasons it's better:

* It uses Vert.x natively which in itself is very performant

* It benefits from build time optimization that Quarkus can provide

If 1 is true, then shouldn't you merge this code and this becomes the "new RestEasy classic" so that every project running on JBoss/Wildfly takes advantage of that too?

If 2 is true then the comparison might not  be fair :)

 

RESTEasy Reactive does implement almost the entirety of the JAX-RS spec so the comparison of it using @Blocking vs RESTEasy Classic is very meaningful

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/63554b17-bb47-44ae-b2ce-0eb281196b29n%40googlegroups.com.

[William Burke]

I don't believe you that Java cannot compete against Rust etc. for startup time, especially with Quarkus and Graal.  But that's not my point

I'm talking soley about app server to Microservices to Lambdas.  Deployments are becoming more and more fine grained.  Just do the math memory wise.  One microservice maybe had 4-12 endpoints?  Took up maybe 100-200meg memory?  Multiply that by 4-12 as you break those microservices into functions.  Relatively the same footprint for each deployment because of the base costs of the JVM and the frameworks deployed on it, but an explosion of deployments.  The JVM needs serious fundamental work to address this.  And I'm not talking about garbage collection.  Java was optimized for long running large deployments, now we have short running small deployments and things need to change.

Again, I hope Loom kills reactive.  The whole functional programming + fluent apis + reactive coding has made Java development ridiculously hard to maintain and debug.  And if Loom can remove one of those beasts, we'll all be much happier as our code and our bodies get older and we become the Cobol developers of the 21st century.

[Jaikiran Pai]

On 21/01/21 7:33 pm, William Burke wrote:

Again, I hope Loom kills reactive.  The whole functional programming + fluent apis + reactive coding has made Java development ridiculously hard to maintain and debug.  And if Loom can remove one of those beasts, we'll all be much happier as our code and our bodies get older and we become the Cobol developers of the 21st century.

Haven't been following Loom closely but I'm glad to see that I'm not the only one who feels this way :)

-Jaikiran

[Paul Carter-Brown]

Some interesting thoughts and discussions coming through. I guess constant RAM usage is a driver for serverless as it's still relatively expensive in the cloud. I would love an EC2 instance with 1vCPU and 32GB ram for microservices that run seldom yet when they do, need to be semi-warm and ready to serve. The most you can get is 2GB RAM for a 1 VCPU instance. It thus makes economic sense to go serverless instead of paying for CPU's you don't need for the RAM you do.

My personal opinion is that architectures built with Lambdas and Serverless will end up being big balls of mud. I just can't fathom how a complex system with lots of interactions could possibly perform or be maintainable. Sure, maybe for systems with intermittent load and long running functions which are not latency critical then it makes sense not to have it running doing nothing while there is no work to do, but surely there are better ways of solving this problem at a hardware/OS/VM layer than at the application layer? It's not impossible to imagine a container technology coming up with a means of snapshotting the resident memory to disk and then resuming upon a trigger from something like an incoming TCP connection. I remember when speeding up the boot time of one's OS was all the rage up until sleeping when you close the lid worked consistently. If storage is getting so cheap, surely we can find a way of paging containers in and out of RAM without needing to re architect the app layer from the ground up. Swapping has been around for decades, let's just do it between RAM & SSD where a page is now a container's resident set instead.

Just a comment on splitting systems up into microservices - we have taken the approach of microservices being more of a development approach than a deployment decision. We have microservices per bounded context with their own tables, well defined interface etc etc. At deployment time, we happen to create a Quarkus jar with say 10 microservices in it. Each one does not know that it may or may not be in the same process space as another. They discover each other through a service discovery mechanism and may happen to be calling back into the same process over TCP/HTTP. This is done purely to end up with an RSS of say 600MB as opposed to 10 lots of 300MB RSS. Many consider this to be an antipattern, but it works for us, has no downside and saves a lot of money and resources.

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/cfbe0f80-d05b-5b0a-6ab8-1b990e3479b7%40gmail.com.