Vert.x 5 status update?

[Gordan Krešić]

Hi all,

Could someone give us a status update regarding Vert.x 5, planned release date etc.?

Status page at:

https://github.com/eclipse-vertx/vert.x/wiki/Vert.x-5

says "We expect Vert.x 5 to be released in 2023." and tracking issue at:

https://github.com/vert-x3/issues/issues/610

still shows a lot of unchecked boxes.

A lot has changed with virtual thread support in Java with JDK 21 release this September and it would be a great pointer to know more on how Vert.x plans to fit in that picture.

And thanks for all the hard work so far.

-gkresic.

[Julien Viet]

On Tue, Oct 31, 2023 at 10:01 AM Gordan Krešić
<gordan...@steatoda.com> wrote:
>
> Hi all,
>
> Could someone give us a status update regarding Vert.x 5, planned release date etc.?
>
> Status page at:
>
> https://github.com/eclipse-vertx/vert.x/wiki/Vert.x-5
>
> says "We expect Vert.x 5 to be released in 2023." and tracking issue at:

I think it could only be in 2024 (hopefully first half), I will update
this statement.

>
> https://github.com/vert-x3/issues/issues/610
>
> still shows a lot of unchecked boxes.

I agree, however if you drill down in the boxes you will see that many
are mostly implemented like "CLI Cleanup", "SQL client improvements",
"Core API improvements".

>
> A lot has changed with virtual thread support in Java with JDK 21 release this September and it would be a great pointer to know more on how Vert.x plans to fit in that picture.

We will release Vert.x 4.5 (early November) which contains async/await
support for Java 21 with a virtual thread Verticles. You can read the
doc here https://vertx.io/vertx5/docs/vertx-core/java/#virtual_threads

>
> And thanks for all the hard work so far.

thanks :-)

>
> -gkresic.
>
> --
> 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/38e9bf9e-b6e7-4d59-9558-e81dbae9db84%40steatoda.com.

[Bezaleel]

we switched to 4.5 and the new threading model for verticles is awesome! congratulations!

are there any plans for hazelcast blocking api calls do internal await if call comes from such lightweight threads?
this way the api will not change, but the eventbus thread can handle other requests during hazalcast sync on api call?

[Julien Viet]

Hi,

do you mean that internal blocking calls of the cluster manager to
hazelcast would use virtual threads ?

Julien

> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/3245f371-3ec1-4ae7-b8ba-721d9b12635bn%40googlegroups.com.

[Bezaleel]

yes. so if you have a synchronous call like Map::get in hazelcast, internally it could use Future.await
when waiting. in this current implementation the current thread gets blocked (i guess).

but what i have seen is, that Vertx::executeBlocking uses the threads reserved on vertx startup,
where none of them are virtual.
this is crashing any Future::await.
i really do not know what is better: either Future::await works with execute blocking threads too, or
blocking threads can be configured to be virtual.
i really would appreciate everything virtual, but i am not sure about the consequences for vertx 

internally. and it definitely would be great for normal threads like the execute blocking threads
to be able to work with Future::await. (code can be reused)