Add support to provide your own executor

[slinkydeveloper]

Add method to support providing your own executor for blocking services.

This allows to integrate with virtual threads:

RestateHttpEndpointBuilder.builder()
                    .withService(BlockingGreeterService(), Executors.newVirtualThreadPerTaskExecutor())

I tested this feature locally with the virtual thread executor and it works. Unfortunately I couldn't easily setup a test within this project because i need to change the minimum jdk version, and i need to use a beta version of the kotlin plugin. Perhaps we can add a test to the e2e repo.

[github-actions]

Unit Test Results

145 tests  ±0   145 ✔️ ±0   8s ⏱️ ±0s
  15 suites ±0       0 💤 ±0 
  15 files   ±0       0 ❌ ±0 

Results for commit b6a14c8. ± Comparison against base commit 529f59f.

♻️ This comment has been updated with latest results.

[tillrohrmann]

The change looks good to me. +1 for merging. Thanks for providing this PR @slinkydeveloper.

+1 for adding a test to our e2e test suite.

[tillrohrmann]

Unfortunately I couldn't easily setup a test within this project because i need to change the minimum jdk version, and i need to use a beta version of the kotlin plugin.

Do you need to use a beta version of the Kotlin plugin to make the SDK work with Java 21?

What should be the minimum required Java version for the SDK? Currently it is Java 11, right?

Are there some benefits of running the services in a virtual thread? I guess when doing blocking I/O. Would this also help when waiting on a future result?

[slinkydeveloper]

Do you need to use a beta version of the Kotlin plugin to make the SDK work with Java 21?

Yes, Kotlin on JDK 21 is not GA yet. Will be in december I think, the JDK 21 is just too new.

What should be the minimum required Java version for the SDK? Currently it is Java 11, right?

Yes, we had no reason to bump it to 17 yet. 21 is the latest LTS, 17 is the previous LTS.

Are there some benefits of running the services in a virtual thread?

As the current status quo of the sdk, when combined with the Vert.x http implementation, you get synchronous coding style in java (no futures, callbacks, etc) very cheaply on top of async i/o. Without virtual threads, you would use vertx.executeBlocking which under the hood uses a thread pool to achieve the same result. This thread pool is also unbounded, meaning that it potentially spawns one OS thread per connection in the worst case.

Would this also help when waiting on a future result?

In the virtual threads world you don't use futures.

I think in general, independently from virtual threads or not, this change is useful, as I can see users that want to bring their own executors to run their own code.

[tillrohrmann]

As the current status quo of the sdk, when combined with the Vert.x http implementation, you get synchronous coding style in java (no futures, callbacks, etc) very cheaply on top of async i/o. Without virtual threads, you would use vertx.executeBlocking which under the hood uses a thread pool to achieve the same result. This thread pool is also unbounded, meaning that it potentially spawns one OS thread per connection in the worst case.

This is beneficial if the users calls an external service from a side effect closure via some http client, I assume, right?

For the communication between the vertx based Restate communication layer and the service code we block on some CompleteableFutures, right? Would this also benefit from virtual threads or would this simply result in a blocked platform thread as before because the virtual thread cannot be unmounted?

[slinkydeveloper]

This is beneficial if the users calls an external service from a side effect closure via some http client, I assume, right?

I guess so, also this is also beneficial if you have many concurrent requests to this service endpoint, because for each of them you spawn one of these virtual threads.

For the communication between the vertx based Restate communication layer and the service code we block on some CompleteableFutures, right? Would this also benefit from virtual threads or would this simply result in a blocked platform thread as before because the virtual thread cannot be unmounted?

As far as i understood, all the locking primitives are virtual threads aware, so it would not block the OS thread but rather execute another virtual thread. But i'm fuzzy on the details TBH: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#virtual-threads