thx, but I still prefer this explanation https://youtu.be/zluKcazgkV4

On Fri, 1 Sept 2023, 11:34 ski n, <raymondmees...@gmail.com> wrote:

> Kotlin Coroutines and Java Virtual Threads are conceptually very similar.
> In details and implementation they are different, of course. A good
> presentation on comparing coroutines and virtual threads by Urs Peter:
>
> https://www.youtube.com/watch?v=bOLChQ3fFQo
>
> I was just referencing Kotlin Coroutines btw, for Camel only virtual
> threads are relevant.
>
> On Fri, Sep 1, 2023 at 11:01 AM bukaj_s <jsod...@gmail.com> wrote:
>
> > sry I meant executor.
> >
> > On Fri, 1 Sept 2023, 10:57 bukaj_s, <jsod...@gmail.com> wrote:
> >
> > > You are confusing coroutines and virtual threads.
> > > Afaik you can try to use virtual thread pool, question is how much
> > > synchronization is camel using under the hood.
> > >
> > > On Fri, 1 Sept 2023, 10:34 ski n, <raymondmees...@gmail.com> wrote:
> > >
> > >> OK, thanks. It will take some (couple of years) before most libraries
> > are
> > >> catching up.
> > >>
> > >> At least, Spring Boot will already support Java 21 with virtual
> threads
> > in
> > >> their next release (
> > >> https://spring.io/blog/2023/08/24/spring-boot-3-2-0-m2-available-now
> ).
> > I
> > >> don't know exactly how they do it, but they ship Spring as a multi
> > release
> > >> Jar for this purpose. When running Spring on Java 21 you can enable
> it (
> > >>
> > >>
> >
> https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2.0-M1-Release-Notes#support-for-virtual-threads
> > >> ).
> > >>
> > >> I was thinking more or less in the same lines for Camel. For most of
> the
> > >> cases the underlying libraries needs to be updated, but for some stuff
> > >> like
> > >> Seda or Stream caching this may already work from within the libraries
> > own
> > >> code.
> > >>
> > >> Raymond
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Fri, Sep 1, 2023 at 9:36 AM Claus Ibsen <claus.ib...@gmail.com>
> > wrote:
> > >>
> > >> > Hi
> > >> >
> > >> > No plan for virtual threads - this relies on 3rd party libraries and
> > >> many
> > >> > other frameworks starting to adopt them as well, which means Java 21
> > as
> > >> > minimum base version.
> > >> > Support for Java 21 is to run on JDK21. JDK17 will be primary
> > supported,
> > >> > and 21 secondary, that is the plan for this year.
> > >> >
> > >> >
> > >> > On Fri, Sep 1, 2023 at 9:34 AM ski n <raymondmees...@gmail.com>
> > wrote:
> > >> >
> > >> > > In integration there is a lot of Async I/O (calling disk,
> databases,
> > >> > api's
> > >> > > and other external systems). Though Camel is very fast, it's
> mostly
> > >> these
> > >> > > async I/O calls that take time and eat a lot of platform threads.
> > >> > >
> > >> > > For example:
> > >> > >
> > >> > > from("direct:start")
> > >> > >   .log("some log") //this takes less than 1 ms
> > >> > >   .setHeader(Exchange.HTTP_URI, constant("http://someapi";))
> //this
> > >> takes
> > >> > > less than 1 ms
> > >> > >   .to("http://someapi";) //this takes 3 seconds
> > >> > >   .setHeader("Result","Done") //this takes less than 1 ms
> > >> > >   .to("sql://insertindatabase")  //this takes less than 1 seconds
> > >> > >   ;
> > >> > >
> > >> > > One solution to this is using virtual threads. They are already
> part
> > >> of
> > >> > > Kotlin (coroutines), but now coming to Java as well in Java 21
> > >> (release
> > >> > > 19th September).
> > >> > >
> > >> > > In the Camel 4 blog "What's new" it states that:
> > >> > >
> > >> > > "We plan to support Java 21 on next LTS released by the end of
> this
> > >> > year."
> > >> > >
> > >> > > Camel next LTS release (4.2) is expected around December.
> > >> > >
> > >> > > I was wondering what the plans here are with supporting virtual
> > >> threads?
> > >> > > Will they part of 4.2 or planned for later?
> > >> > >
> > >> > > Raymond
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Claus Ibsen
> > >> > -----------------
> > >> > @davsclaus
> > >> > Camel in Action 2: https://www.manning.com/ibsen2
> > >> >
> > >>
> > >
> >
>

Reply via email to