Switching to Quarkus.io

[Johannes Lichtenberger]

Hi,

I'd like to switch an existing Vert.x project (a Maven/Gradle module of a multi module project) to Quarkus.io. Do you have any documentation on this?

The sad thing is, that the use of Java 13 will prevent me from building native images. Otherwise I'm not using any Reflection or other stuff hopefully which wouldn't work. Hope the GraalVM catches up soon (also with Java 14, because the introduction of records will be great).

Kind regards
Johannes

[Thomas SEGISMONT]

Hi,

The Quarkus website has docs on how to leverage Vert.x tech in Quarkus apps. I would start there.

Regards,

Thomas

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5299da65-3217-460f-9078-ae5ff954a9c1%40googlegroups.com.

[Johannes Lichtenberger]

So, basically create a new Quarkus module with Maven and copy the classes... over?

https://quarkus.io/guides/vertx

However, I don't want to use JAX-RS (I think that these annotations rather hurt readability). I'd like to use the router for instance as before:

https://github.com/sirixdb/sirix/blob/master/bundles/sirix-rest-api/src/main/kotlin/org/sirix/rest/SirixVerticle.kt

Kind regards
Johannes

[Thomas SEGISMONT]

To use reactive routes in a Quarkus app, see https://quarkus.io/guides/reactive-routes

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/149bca59-35e4-48a2-b3e7-3687e65c329f%40googlegroups.com.

[Johannes Lichtenberger]

Ah, do they have a hello world example somewhere with the Context of where to put this method?

And can I still use the Vert.x config file and such things?

[Thomas SEGISMONT]

Have you tried to ask on the Quarkus user forum?

Le ven. 3 janv. 2020 à 17:28, Johannes Lichtenberger <lichtenberg...@gmail.com> a écrit :

Ah, do they have a hello world example somewhere with the Context of where to put this method?

And can I still use the Vert.x config file and such things?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/71c4e1e1-a51a-4314-8f51-3947f71ad856%40googlegroups.com.

[Julien Viet]

Hi,

I think there is something important we should warn people about before they do such migration.

Quarkus has a different way of handling concurrency than Vert.x

If you use Quarkus has a shell to run an existing Vert.x application and deploy Verticles it will be fine and work mostly the same (Quarkus will act as a bootstrap and perform dependency injection).

Otherwise if you use Quarkus managed HTTP then it will leverage all available event loops to start the default HTTP server and it will use Resteasy.

This means that:

1/ you won't choose anymore how event-loop are assigned to Verticles since HTTP will use all available event-loop by default

2/ by default Resteasy assumes you will be blocking, so if you are using jax-rs annotations then you will lose the run on io benefits. Note that there will be ways to run Resteasy on IO thread in the future.

3/ currently the Quarkus integration will start 2 Vert.x instances because there is some work to do in Resteasy to make it fully non-blocking (this is related to 2/).

4/ the consequence is that if you are using Vert.x clients they will likely run on a different event-loop than the current thread of execution and you will have message passing in your application. I think this is fine most of the time, but you might have created your application in a way that you control event-loops and you assume that all inbound and outbound IO will be on the same event-loop.

The Quarkus team is currently working on solving 2/ and 3/ (Stephane) though and it should improve in the future.

I believe those facts are important if you have an existing runtime and you want to benefit from Quarkus, you should check that these items are not show stopper for your application.

cheers

Julien

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CACiEr_R2bZ0QJszGWq3-GsJ%3DW_Lp8EWjp1bNgR8DnJhFqX8BAg%40mail.gmail.com.

[Julien Viet]

read "as a shell"

[Johannes Lichtenberger]

I'm starting a Vert.x based HTTP-Server by overriding the start method of the CoroutineVerticle:

```kotlin
override suspend fun start() {
val router = createRouter()

// Start an HTTP/2 server
val server = vertx.createHttpServer(
httpServerOptionsOf()
.setSsl(true)
.setUseAlpn(true)
.setPemKeyCertOptions(
PemKeyCertOptions().setKeyPath(location.resolve("key.pem").toString())
.setCertPath(
location.resolve("cert.pem").toString()
)
)
)

server.requestHandler { router.handle(it) }
.listenAwait(config.getInteger("https.port", 9443))
}
```

I don't want to use the Annotation stuff, and of course I like to use the non blocking Vert.x way _without_ having to execute every request on another thread from a thread pool.

Of course It's all open source, basically: https://github.com/sirixdb/sirix/blob/master/bundles/sirix-rest-api/src/main/kotlin/org/sirix/rest/SirixVerticle.kt

So I'm not sure if I gain a lot from using Quarkus, as I'm currently using Java 13 and Kotlin. But might be super interesting when the GraalVM catches up (and native inages) with the Java version. Right now it provides hot code replace plus compile time DI I think for SirixDB.

Hm, I guess it shouldn't be a problem, but I have to figure out how everything fits together. Otherwise I guess I won't switch. And currently I don't want to spend a lot of time. If it requires a few days to switch, I probably won't...

Kind regards
Johannes

[Paulo Lopes]

It seems you're not using any quarkus features as you wrote you want the traditional vert.x development api. In that case quarkus will only offer you the tooling to build native images as the default graalvm configurations are holded on its code.

Performance wise it's hard to tell that you will benefit anything as it has been said before more threads are involved, different event loops, etc. Yet quarkus defaults are different from vert.x core.

[Johannes Lichtenberger]

Plus maybe hot code replacement (automatic restart, when it detects file changes) and DI? But okay, maybe I can simply use the compile time DI as a simple dependency and build the native image on my own in the future. However, I read a blog entry where it's described that Netty has to be patched first plus other stuff. Maybe not so trivial after all?

[Johannes Lichtenberger]

More threads are definitely a downside!

[Julien Viet]

Hi

Netty is patched for native only (other stuff too) and that is one of the Quarkus value add which makes easier for you to build native images.

If you need DI and build tooling for graal vm then it makes sense to use it too.

Julien

> On 4 Jan 2020, at 09:53, Johannes Lichtenberger <lichtenberg...@gmail.com> wrote:
>
> Plus maybe hot code replacement (automatic restart, when it detects file changes) and DI? But okay, maybe I can simply use the compile time DI as a simple dependency and build the native image on my own in the future. However, I read a blog entry where it's described that Netty has to be patched first plus other stuff. Maybe not so trivial after all?
>

> --
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/ed3a248b-7828-44c6-804b-31f96c563ab4%40googlegroups.com.

[Johannes Lichtenberger]

So, do you know what needs to be done? Creating a new Quarkus module I guess via Maven, copy the classes and everything over and probably create a bean with this method where I'm getting the Vert.x Router as a parameter. However, then I'm still not sure how to use the Vert.x config file and all the other Vert.x stiff as for instance OAuth2 / OpenID Discovery with Keycloak, using the Vert.x context and so on.

I think it makes sense, as I want to scale (replicate and partition resources) SirixDB with a distributed log as for instance Kafka or Pulsar/BookKeeper in the future.

And I think these new Frameworks as for instance Quarkus and Micronaut might make building native images and managing Kubernetes Clusters even easier in comparison with a bare Vert.x cluster.

Kind regards
Johannes

[Paulo Lopes]

I don't think you can just copy paste and expect it to work for several reasons. But I may be totally wrong 🤷‍♂️

You are mentioning DI but do you care specific implementation or are you fine with CDI/arc ( what is offered by quarkus)?

As it was mentioned routing is exposed as resteasy (even though powered by vert.x) so by default you will get one extra layer of code.

Same for security, quarkus security builds on top of vert.x auth (but I can't tell how easy to get back the vertx api directly)

For building hot reload is already available on vert.x core or the vertx maven/gradle plugins (with different semantics than quarkus)

So on general terms, yes, theoretically you can create a new quarkus module, copy your code and inject the vertx instance into your bean. Use the annotations to route your http paths and handle security too.

Now you need to pay attention to the details. In your snippet you create an http2 server, which I am not sure it will work on native. Until graalvm 19.3 java 11 wasn't supported and alpn either. With 19.3 java 11 is supported but I don't know if netty has been verified for this yet. I've chatted with the graalvm team on slack a while ago to fix a few netty ssl issues but no pull request has been done yet. Alpn is yet another area that needs to be verified.

https://github.com/quarkusio/quarkus/blob/master/extensions/netty/runtime/src/main/java/io/quarkus/netty/runtime/graal/NettySubstitutions.java#L127

There's also a mention on java 13, which has no eta to land on graalvm, I believe they want to focus mainly on lts releases which means quarkus and micronaut will likely stay on these too.

Finally your mileage may vary with different frameworks because even though quarkus and micronaut both use netty they both patch internally the dependencies so this can introduce different behavior.

So I think if you give it a try please let us know how was the experience and we can all learn from it 😉

[Vincent Free]

It looks like DI and native image creation could pretty easily be added by yourself. If you’d use dagger2 or another compile time DI lib then only netty patching is something you’ll really gain sinds Paulo already stated that hot reload works through plugins(I’m also interested in these btw).
While experimenting with graalvm I had implemented the patches in less than an hour running a functional native app thanks to the how-to pages on the vertx site.

I have also thought about trying quarkus out for my next app but it's just not as stable as Vert.x at the moment and quite frankly it's not as fast. Though it looks like you'll gain a lot you'll also loose in my opinion in performance and flexibility.

Also most of my apps need high throughput so native is a no go at the moment.

[Johannes Lichtenberger]

Will Vert.x also provide better support for native images in the future? However, then I would wonder what Quarkus really adds. And why is another layer added on top of Vert.x at all for most of the stuff?

I really love the Vert.x APIs and I for instance don't get what JAX-RS for instance adds. I think the bare fluent router API is much nicer :-)

So, I've asked over here because I was of the impression that some of the Vert.x engineers also work on Quarkus and vice versa.

And I just watched some Quarkus videos over the Christmas holidays and thought it's a nice addition. Even though, if I don't need the other APIs and all the libraries they optionally have patched for native images I guess it would be cool if Vert.x would provide a patched version of Netty and thus perhaps also make it even easier to build native images :-)

So, I guess I'll not switch and simply use Dagger2 for DI (also for other modules in the project). Usually I still do it "by hand" with factories or well, sometimes with Spring at work, but I wouldn't want to include a Spring dependency and it also should be a compile time DI framework instead of a runtime framework.

[Paulo Lopes]

 
On Sunday, January 5, 2020 at 10:48:36 AM UTC+1, Johannes Lichtenberger wrote:

Will Vert.x also provide better support for native images in the future? However, then I would wonder what Quarkus really adds. And why is another layer added on top of Vert.x at all for most of the stuff?

Vert.x will not attempt to patch dependency libraries, instead we will just work with what is provided upstream. So what you can expect is a best effort solution, as you can see on the howtos:

https://github.com/vertx-howtos/graal-native-image-howto

So what quarkus offer is a tested set of dependencies that are known to work on native, and they take the extra effort to make it work if it doesn't out of the box.

 

I really love the Vert.x APIs and I for instance don't get what JAX-RS for instance adds. I think the bare fluent router API is much nicer :-)

I've to agree with you, but i know that many people still prefer the annotation blocked APIs as they are close to what they know how to use well. It's a trade off, to some this is a productivity boost that is acceptable in exchange of performance.

 

So, I've asked over here because I was of the impression that some of the Vert.x engineers also work on Quarkus and vice versa.

And I just watched some Quarkus videos over the Christmas holidays and thought it's a nice addition. Even though, if I don't need the other APIs and all the libraries they optionally have patched for native images I guess it would be cool if Vert.x would provide a patched version of Netty and thus perhaps also make it even easier to build native images :-)

As I wrote above, we prefer a different approach, let they things get patched upsteam (and they are, just go through netty github issues and you'll see ;-)