Next Steps for Vertx on Loom

[augus...@gmail.com]

Vertx-web is my favorite Java web framework. It is fast, well maintained, and offers a pure-java api without annotations or other magic.

The one (major) problem I've always had with Vertx is debugging, and it looks like Project Loom can solve that.

I'd be interested in contributing to getting Vertx working Loom; are there any current experiments? In terms of approach, it seems like a first step that's already been discussed is forking the Rx generator and modifying it. A more intensive effort could replace the event-loop model entirely with fibers but that seems like an intensive effort that would likely regress performance in the end.

All I care about is having nice debugging.

What do you think?

Regards,

August

[Julien Viet]

Hi August,

we are looking forward to have an initial integration with a synchrononous generated API in the first steps.

We believe this is the best option for the moment because it is relatively cheap to implement and has the potential to provide immediate value.

Using Loom internally is a more radical change and would actually mean a rewrite of Vert.x internals because currently it is not designed for this (partly because of Netty).

If you are willing to step up and experiment this generator approach we would be welcome to accept this contribution.

Julien

--
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/4df249b5-4035-4d7e-b128-54da02980678n%40googlegroups.com.

[August Nagro]

Thanks Julian.

Would generating a blocking api achieve the goal of improved debugging?

And can you provide a brief outline of what needs to be done? I have never used Rx, but would I want to fork [1] and just make everything block instead of return future?

1: https://github.com/vert-x3/vertx-rx

You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/nUYdn7oPVLQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CA%2BH-X48m7etDcVvtCdRHOZnM62DYJ0YMV2Q%3DjwO0ZMB7QKdaYQ%40mail.gmail.com.

[Julien Viet]

Hi,

I think it can help debugging as long as you don't step into Vert.x code.

I can write a short RFC page in the wiki to describe what we could do here, if you agree.

Julien

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAHNb0ZOym8Uk0Y-akTs4AdXnF%3DFkEO%2BHaHV3jJc47eOxdjMjzA%40mail.gmail.com.

[Haddock]

"A more intensive effort could replace the event-loop model entirely with fibers but that seems like an intensive effort that would likely regress performance in the end."

This would result in a completely different approach where async callback handlers in vert.x would be replaced by fibers taking items from channels and being blocked when an channel is empty. If a channel is empty the Java thread reading from it would be blocked till it receives an item. Not so with fibers (or Goroutines in Go) where the fiber can be withdrawn from the channel and be placed there again when the preivously empty channel receives an item.

Implementing that change of paradigm in vert.x would indeed be effortful. I don't see why there would be a performance regression. A solution with fibers/goroutines does not always yield better performance than with Java threads (where 1 Java thread corresponds to 1 OS thread). Sometimes the conventional solution with Java threads results in better performance. It depends on the situation. Mixing Java threads and fibers in Loom will not be something the masses will get along with well, I fear.

[August Nagro]

> I can write a short RFC page in the wiki to describe what we could do here, if you agree.

Yes please!

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CA%2BH-X48cCXwvvLvArfbP%2BfAw33yH3OBwXiueVR5fJfTsyzrb9g%40mail.gmail.com.

[August Nagro]

> Mixing Java threads and fibers in Loom will not be something the masses will get along with well, I fear

Why do you say that?

--

You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/nUYdn7oPVLQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5eeb47bd-a588-4573-be36-9ce5f0e85fb0n%40googlegroups.com.

[Haddock]

" Why do you say that?"

Because fibers and communicating sequential processes by Toni Hoare (see http://www.usingcsp.com/cspbook.pdf) are very different from traditional thread models. This will confuse some people. In addition, sometimes using fibers gives better performance than Java threads. Sometimes you get better performance the other way round. So there will be no simple clear picture and that will cause problems for some people.

There was a lot of arguing against lambdas in Java. Lots of discussion that lambdas make a clean simple language blown up. In fact, the opposite is true: Lambdas remove a lot of boilerplate code in Java and makes code more concise and easier to understand at first sight. And this holds always true: So after a while there is no way to argue against Java lambdas. Meanwhile if you don't have a black belt in Java8 lambdas you are a second class programmer. But with fibers (now called virtual threads in Loom) it does not hold true that fibers are always better as what performance is concerned. So the arguing will not disappear that quickly as earlier with Java8 lambdas and some confusion will remain for a while.

[Julien Viet]

thanks that's interesting.

The Java blocking IO have been reimplemented on top of NIO as far as I know.

Rewriting Vert.x to use Java blocking IO / providing a blocking solution based on Vert.x are both similar, the main difference is that the switch between fiber/threads happens at different layer (e.g TCP vs HTTP).

That being said, Vert.x is based on Netty for various reasons and one of them is that Netty is committed to deliver performance (obviously :-) but also advanced networking capabilities that the JVM takes years to deliver when it does, e.g domain sockets are already available in Vert.x and not yet on JVM, that will be similar for HTTP 3, IO Uring, etc...

A Loom compatible Netty seems to be what we would ultimately need. I'm not sure though that in the plans of Netty.

Julien

--

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.

[Julien Viet]

I will do it soon.

Are you familiar with the code generator of vertx already ?

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAHNb0ZOz1A8jjRbfre%2BqjOapcryELAuVOrcZ5O8Wr2Bon%3DAnZw%40mail.gmail.com.

[August Nagro]

No I am not.

I have experience with annotation processors though. For example I made this: https://github.com/AugustNagro/vertx-repo

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CA%2BH-X4-cOtDEGTgHcqaM90QkWXRb%3DJwMEG8vajQ7q3k2xh9RMw%40mail.gmail.com.

[Julien Viet]

ok, in this case you need to become familliar with Vert.x model, which is a hierarchy of model that looks similar to java processing models but is adapted to vertx, e.g it understands asynchronous methods which is quite essential for such generators.

And also you need to look at how it is used in the current vertx-rx generator.

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

[August Nagro]

You are talking about vertx-codegen project? https://github.com/vert-x3/vertx-codegen

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CA%2BH-X482cEK6V5NNrfL%3DP82Y%2BZ-C%2Bd72Yj8BdotTLWZPyq5gBw%40mail.gmail.com.

[Julien Viet]

yes indeed, there is documentation inside in the adoc file + the README which are accurate.

this is somewhat trivial if you already know annotation processors.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAHNb0ZMnrJerqC5AXxp6enDcnobffckzt6ua5hCT9_RqzAGsHA%40mail.gmail.com.

[August Nagro]

Since the vertx-rx build is currently broken until the RC3 version is merged, I decided to make a small experiment in Scala 3. 

I created an extension method on vertx-web's Router named `reply`, that uses virtual threads:

case class User(first: String, last: String) derives JsonConv

class App extends AbstractVerticle:

  override def start(): Unit =
    val router = Router.router(vertx)
    router.get("/user").reply(getUser)

    vertx.createHttpServer()
      .requestHandler(router)
      .listen(8085)

  def getUser(ctx: RoutingContext): User =
    User("august", "nagro")

Hitting the endpoint returns

{"first":"august","last":"nagro"}

The implementation of `reply` accepts a function from RoutingContext to any T with a `given` (aka implicit) instance of JsonConv[T] available. JsonConv is essentially jackson-databind, but at compile time and supporting Scala 3's typeclass derivation.

trait JsonConv[T]:
  /**
   * Convert T to a JsonArray, JsonObject, or
   * a type that is implicitly considered Json,
   * like Int or Map
   */
  extension (t: T) def toJson: Any

  /**
   * Map json to type T. May throw any
   * RuntimeException subclass
   */

  def fromJson(json: Any): T  

And finally, the implementation of reply:

extension (route: Route)
  def reply[T](handler: RoutingContext => T)(using jc: JsonConv[T]): Route =
    route.respond(ctx =>
      val promise = Promise.promise[Any]()

      Thread.ofVirtual().start(() =>
        try
          promise.complete(handler(ctx).toJson)
        catch case t: Throwable =>
          promise.fail(t)
      )

      promise.future()
    )

I am curious about your thoughts. So far, I've found debugging to be quite nice.

One problem that is immediately apparent is that you still encounter Vertx Future, which needs a blocking `get` method that throws on failure. `result` returns null and does not throw. That can also be added by an extension method, but might be nice to have in the API proper.

I have not tested performance; should I fork the TechEmpower benchmarks or does Vertx have its own set of benchmarks?

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CA%2BH-X4-41_zCkeXS-UsCBamV7rp85e2aiarem2qF-MgygQ0A9Q%40mail.gmail.com.

[Julien Viet]

Hi,

the vertx-rx build is fixed.

Julien

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAHNb0ZPQpHQ2aNR_DRfgX48Cn94cwUCR9Fk3oGWXUQp7GZ3fxg%40mail.gmail.com.