►
From YouTube: Jakarta Tech Talk - Use of virtual threads in Helidon
Description
With introduction of Virtual threads in Java 19 (as a preview feature), we could start looking into creating a framework to write services that are blocking, and at the same time provide great performance even under heavy parallel load.
Where we had to use reactive programming to achieve the same goal, we can now write simpler, more maintainable code and achieve the same results. With Helidon Níma (Web Server designed for Virtual threads), and other Helidon libraries, we now have a framework to build
blocking and performant services (now in Alpha, until Virtual threads are release in Java as a non-preview feature).
You will learn how we benefit from virtual threads when writing (Micro)services, and whether our performance assumptions were correct.
A
Hello,
everyone
and
welcome
to
another
Jakarta
Tech
talk.
My
name
is
Serena
and
joining
us
today
is
Thomas
Langer,
who
will
be
presenting
on
the
topic
of
use
of
virtual
threads
in
heladon.
If
you
have
any
questions
for
Thomas
as
we
move
through,
today's
presentation
feel
free
to
ask
them
in
the
chat
or
you
can
click
on
the
ask
a
questions
tab
without
any
further
delay.
Thomas
over
to
you.
B
Thank
you
very
much
hello
everybody
good
morning
and
good
afternoon,
depending
on
where
you
are
I,
will
talk
a
bit
about
virtual
threats
and
specifically
how
we
decided
to
use
them
in
project
halidon.
I
am
architect
of
a
project
and
I
have
been
with
it
since
its
Inception.
So
let's
have
a
look
and
what
halidon
is
a
very
short
introduction.
Halidon
is
a
framework
for
developing
Java
microservices.
The
micro
is
intentionally
in
Brackets.
We
can
also
build
quite
big
Services.
It
really
depends
on
the
choice
of
the
developer.
B
One
of
the
main
points
here
is
that
helidon
application
is
just
a
Java
SE
application.
You
run
it
using
Java
minus
jar,
which
makes
it
very
easy
to
containerize
or
to
run
locally
and
to
play
around
with
it.
I
will
not
dive
very
deep
into
it.
I
will
just
show
a
brief
history
of
how
we
have
worked
on
the
project.
We
started
in
2018,
where
we
had
a
pre
1.0
version
on
Java
8,
and
we
have
moved
through
the
Java
versions
up
until
today,
where
the
active
version
is.
B
B
There
is
not
much
possibility
to
cross
these
unless
you
dedicate
a
lot
of
time
to
designing
everything
and
making
sure
your
scalability
is
up
to
par
with
your
requirements
for
performance,
so
for
ease
of
use.
You
usually
want
to
use
a
booking
Paradigm,
because
it's
very
easy
to
reason
about
and
to
code.
You
want
to
have
white
Library
support.
You
need
to
have
easy
maintenance
and
you
need
to
have
easy
troubleshooting,
but
most
commonly
in
Java
with
these
requirements
the
performance
suffers.
So
why
does
it
suffer?
B
In
most
cases,
this
is
because
of
the
limited
number
of
threads
that
you
can
have
in
a
Java
application,
because
the
threads
are
a
limited
resources,
curse
resource
you
need
to
allocate
them
correctly,
and
the
problem
with
blocking
code
is
that,
as
long
as
you
are
blocking
and
waiting
for
somebody
else
to
finish
their
tasks,
such
as
a
remote
HTTP
service,
your
thread
is
not
allocated
correctly.
It's
doing
nothing,
but
it's
still
consuming
resources.
B
This
can
very
easily
lead
to
things
like
threat
starvation,
where
you
submit
a
task
to
a
executive
service
to
complete
something
asynchronously.
But
you
wait
for
the
task
in
your
thread
and
if
you
do
this
too
many
times
in
parallel,
you
may
run
out
of
threads
to
run
your
asynchronous
tasks
and
then
you
just
stop
working.
B
So
all
of
these
things
leads
to
a
problem
that,
if
you
have
an
application
that
requires
heavily
heavily
concurrent
requests,
such
as
an
HTTP
application,
which
is
the
usual
use
case.
This
approach
is
not
very
good,
so
how
do
we
solve
that?
We
solved
it
with
the
reactive,
Paradigm
and
reactive
programming
really
allows
us
to
utilize
threads
as
much
as
possible.
B
Side
effect
is
that
it
is
more
complicated.
There
is
a
very
steep
learning
curve.
Troubleshooting
and
maintenance
of
these
Solutions
are
much
harder,
even
though
we
have
a
lot
of
good
Frameworks
that
help
you
with
it,
usually
through
reactive
stream
operators,
for
example,
we
have
one
inhaladen.
There
is
one
in
most
of
the
Frameworks
that
support
reactive
programming.
B
It's
very
easy
to
break
it.
So
a
lot
of
times
when
we
get
support
requests,
we
will
find
out
that
somebody
eventually
decided
to
call
that
completable
future
dot
get
within
a
reactive
stream
pipeline
and,
of
course
that
breaks
the
whole
thing,
because
you
walk
a
thread
and
as
soon
as
you
block
a
threat
in
reactive
stream,
you
basically
broke
your
server,
so
it's
very
hard
to
get
right.
You
need
to
occur
a
lot
about
exceptionally
blocks.
B
B
To
do
more
than
one
task
in
parallel,
so
imagine
you
get
a
request
and
then
you
need
to
split
this
request
into
four
parallel
tasks
that
execute
and
then
you
need
to
join
them
back
together
and
return,
something
in
reactive
programming.
You
need
to
be
really
an
expert
to
be
able
to
do
something
like
that
correctly.
B
There
are
other
pitfalls,
for
example,
if
you
look
at
reactive
streams,
you
will
look
at
the
flow
interface
in
Java,
where
you
have
the
publisher,
subscriber
and
a
lot
of
people
tend
to
write
their
own
subscribers.
If
you
do
that,
you
are
kind
of
guaranteed
to
to
fail
because
that's
a
very
tough
interface
to
implement.
B
So,
even
though
there
are
a
lot
of
negatives
to
using
reactive
programming,
we
still
support
it,
because
that's
the
only
way
how
to
write,
really
performant
applications
in
Java-
and
you
can
see
that
at
the
bottom
I
have
put
the
our
icons
of
our
two
flavors.
What
we
call
a
holiday
and
that's
hold
on
MP
MP
stands
for
micro
profile
and
helidon
SE
and
helidon.
Sc
is
a
right
now
until
version
three
fully
reactive
implementation.
B
Halidon
MV
is,
on
the
other
other
side
built
on
top
of
CDI,
Jox,
RS
and
it's
foremost
a
blocking
implementation.
There
are
also
some
asynchronous
things
that
you
can
do,
but
by
default
you
just
build
your
application
as
a
blocking
application
and
of
course,
you
hit
all
the
advantages
and
disadvantages
of
these
two
things,
and
we
want
to
solve
that
and
luckily,
for
us,
Java
came
up
with
something
called
project:
Loom
and
project.
Loom
is
a
project
to
explore
and
incubate
VM
features
and
apis
for
implementation
of
virtual
threads.
B
There
are
three
Jabs
for
that:
virtual
threads,
which
is
a
Java
21
GA
feature
right
now.
It's
jab
444.
There
is
scoped
values,
which
is
a
preview
feature
in
Java
21.
It
used
to
be
an
incubator
in
Java
20
and
before
in
Java
19,
let's
jump
446
and
there
is
structured,
concurrency
I
still
haven't
seen
the
jib
for
Java
21,
but
it
was
second
incubator
in
Java
20..
B
B
Virtual
threads,
obviously,
so
what
is
a
virtual
thread?
It's
a
threat
that
you
can
have
a
huge
number
of.
You
can
have
millions
of
them
running
in
a
jvm.
It
uses
the
thread
API.
It
uses
the
four
joint
pool
to
schedule
its
work.
All
virtual
threads
are
demonstrates.
They
always
have
a
group
called
virtual
threads
and
they
have
a
no
permission
with
a
security
manager.
B
The
existing
threads
that
we
know
from
java
language
are
now
called
platforms
threads.
So
what
is
the
you
know?
How
does
it
work
so
virtual
threads
actually
do
use
platform
threads
and
they
do
use
them
by
mounting
on
the
platform's
thread,
which
is
called
a
carrier
to
run
some
tasks,
and
when
there
is
a
blocking
operation
they
will
unmount
from
it
and
do
nothing
and
the
platform
thread
can
continue
running
a
different
virtual
thread
for
the
duration
of
the
debate.
B
B
Now,
up
to
this
point,
we
are
running
on
a
carrier
thread,
because
virtual
threat
on
its
own
cannot
run.
It
needs
to
run
on
a
carrier
thread
when
we
hit
this
point
where
we
call
response
future.get,
the
call
is
invoked,
but
the
current
thread
stops
being
carried
by
the
platform
thread
and
is
put
aside
unmounted
from
it
when
the
completable
future
completes
and
somebody
on.
B
Side
of
the
equation
calls
completable
future
dot
complete
or
complete.
Exceptionally,
our
thread
will
be
revived,
it
will
be
mounted
to
a
carriers
thread
again
and
it
will
continue
processing
and
all
of
this
is
happening
in
the
background.
You
don't
need
to
know
it.
It
just
happens
by
the
virtual
machine.
B
B
You
can
also
check
if
a
thread
is
virtual
using
the
API,
so
all
of
this
together
allows
us
to
build
an
application
that
is
fully
written
as
a
blocking
application,
but
at
the
same
time,
doesn't
need
to
care
about
the
blocking
points.
So
we
no
longer
need
to
do
reactive
programming
to
be
able
to
fully
utilize
our
threads
and
to
have
high
concurrency.
We
can
actually
use
a
blocking
code
because,
as
long
as
you
are
blocking
so,
for
example,
you
invoke
that
SQL
statement
that
takes
10
seconds
to
execute.
B
B
According
to
the
requirements
of
your
application,
the
jvm
will
do
that
for
you
and
make
it
easier
with
every
feature.
There
are
some
limitations.
So
let's
look
at
the
known
limitations.
We
have
right
now.
So
first
one
is.
There
are
several
cases
when
the
virtual
threat
cannot
unmount
from
the
platform
thread.
B
First,
our
operating
system
level
limitations,
for
example,
file
system
operations,
are
all
blocking
on
the
native
level
and
because
of
that,
there
is
no
way
how
to
handle
it.
The
Java
team
is
working
on
some
changes
in
this
area
because
there
are
new
apis,
also
written
in
Linux
itself,
which
will
allow
us
to
also
have
asynchronous
non-blocking
file
system
operations,
but
it's
not
there
yet.
So
when
you
use
a
file
system
like
you
read
a
file,
your
platforms
thread
will
not
be
unmounted.
B
Another
limitation
are
limitations
are
coming
from
the
jdk
itself,
for
example,
if
you
use
object.weight
also,
your
carrier
thread
will
not
be
unmounted.
These
two
operations
are
actually
understood
by
the
jvm
and
Java
will
compensated
by
temporarily
increasing
the
number
of
threads
in
the
four
gen
pool.
So.
A
B
There
is
a
second
set
of
limitations
which
are
a
bit
worse
because
these
operations
actually
do
hinder
application
scalability,
because
the
carrier
thread
is
pinned
and
the
jvm
will
not
create
a
new
thread
for
you,
and
there
are
two
cases
again.
First
one
is
a
synchronized
block.
Now
synchronization
is
fine
in
Java
as
long
as
you
do
not
do
blocking
operations
within
the
synchronized
block.
B
So
if
you
synchronize
on
a
map,
for
example,
either
using
the
alt
hash
table
or
using
a
synchronized
map,
you
are
probably
not
that
much
in
trouble
if
you
just
create
a
new
linked
list
as
part
of
that
operation.
On
the
other
hand,
if
you
try
to
call
a
remote
system
within
that
synchronized
block
using
HTTP,
then
you
will
probably
break
your
application,
so
synchronized
blocks
do
have
some
impact
on
Virtual.
Threads.
Second
part
are
native
methods
and
foreign
functions.
So
if
you
use
native
code
from
java
Java
cannot
decide
how
to
handle
that.
B
So
for
synchronize
there
is
a
good
solution.
We
can
use
the
Java
Java
util,
locking
mechanism,
which
is
fully
supporting
virtual
threads
for
Native
methods.
Obviously,
there
is
more
work
to
be
done,
so
if
you
are
heavily
depending
on
Native
methods,
then
maybe
this
is
something
that
you
need
to
wait
until
you,
the
library
that
you
use,
resolves
this
problem.
B
A
B
Structured
concurrency
allows
creation
of
structure
within
concurrent
tasks,
so
if
you
want
to,
for
example,
create
a
task
that
spawns
five
subtasks
and
you
only
care
about
all
of
them
completing
and
if
one
of
them
fails,
you
want
the
other
ones
to
be
canceled
right
now
in
Java,
this
is
really
hard
to
do
with
structured
concurrency.
There
is
now
a
way
to
define
policies
how
you
want
to
handle
it.
So
if
you
start
these
subtasks,
you
can
say
if
one
fails,
I
want
all
of
them
to
fail,
or
we
want
to
say.
B
B
As
you
expect,
your
threat
will
be
blocked,
it
will
be
unmounted
from
the
carrier
thread,
the
asynchronous
task
will
be
executed
and
the
results
will
be
correctly
collected
and
returned
back
to
you.
What
is
really
interesting
about
the
support
is
that
it's
also
supported
in
thread
dumps.
So
once
we
use
structured
concurrency
when
we
do
a
thread
dump,
we
will
also
see
the
structure
of
the
tasks
that
was
that
were
executed.
B
Unfortunately,
it's
still
a
preview
feature,
so
we
cannot
utilize
it
in
the
product
in
the
ga
version,
but
for
the
future
this
will
be
very
useful
things
for,
for
example,
in
Paladin
or
other
servers,
you
will
be
able
to
see
all
tasks
that
were
spawned
by
a
single
socket,
for
example,
so
you'll
be
able
to
really
see
it
from
the
thread.
Dump
that
you
know
my
admin
socket
has
25
tasks
where
it
shouldn't
have
any
the
class
that
you
want
to
look
at
is
structured
task
scope.
B
So,
if
you
want
to
play
around
with
it,
javadoc
will
probably
guide
you
and
there
are
resources
on
the
net.
A
very
interesting
feature
of
project
Loom,
the
next
and
the
last
feature
that
is
right
now
available
in
Java,
is
scope,
values.
Again,
it's
still
a
preview
feature,
unfortunately,
because
scope
features
are
kind
of
a
replacement
for
threat,
locals
scope,
values.
Allow
you
to
share
immutable
data
across
threads.
B
When
you
finish
your
task
again
with
threat
locals
when
you
set
a
thread
local
on
a
platform
thread,
it
will
stay
there
forever
or
until
you
call
remove
and
to
be
honest,
you
know,
remove
is
not
being
called
properly
by
most
developers,
so
you
will
have
a
lot
of
things
associated
with
a
thread
that
probably
shouldn't
be
associated
with
it.
So
this
is
what's
scope.
Value
volumes
are
fixing
also
inheritance,
it's
very
expensive
to
copy
threat
locals
to
child
threads
with
Coke
volume.
B
This
is
actually
designed
and
works
nicely,
and
we
have
to
understand
that
with
virtual
threads,
we
need
to
start
counting
in
thousands
and
hundreds
of
thousands
of
threads.
So
these
things
need
to
be
really
well
designed.
Otherwise,
you
will
run
out
of
memory
or
you
may
have
some
performance
impacts
and
threat.
Locals
are
exactly
that.
They
are
a
performance
impact
to
any
application
that
wants
to
fully
utilize
virtual
threats,
because
you
obviously
need
to
synchronize
on
a
threat
local,
so
based
on
all
these
features
that
we
have
seen
are
coming
to
Java.
B
What
we
wanted
to
do
is
to
achieve
performance
of
reactive
programming
with
the
Simplicity
of
looking
code
and
as
I
always
say
on
the
on
on
these
talks.
Our
Benchmark
is
what
Neti
is
capable
of.
We
are
using
Neti
in
Haledon
one
two
and
three,
and
we
know
it's
a
performance
web
server
and
we
wanted
to
see
if
we
can
achieve
similar
performance
using
virtual
threads
and
properly
blocking
code,
and
because
we
found
out
that
this
is
achievable.
We
actually
came
up
with
Nema
and
the
Nema
web
server
is
the
new
core
of
helidon.
B
So
how
do
we
utilize
virtual
threats
when
you
use
HTTP
1.1?
It's
quite
simple:
there
is
just
a
single
virtual
thread
per
connection,
and
this
virtual
threat
is
responsible
for
reading
data
from
the
connection
invoking
your
route
and
then
writing
response
data.
We
have
some
ways
how
to
tweak
it.
For
example,
you
can
have
an
asynchronous
right
for
HTTP
1.1
connections,
where
you
will
actually
have
two
virtual
threads
one
reading
the
data,
one
writing
them
for
optimizations.
It.
A
B
On
some
systems
it
doesn't
own
others.
On
the
other
hand,
HTTP
2
is
actually
very
interesting,
because
that
really
utilizes
the
power
of
virtual
threads.
You
have
one
virtual
thread
per
connection
which
is
handling
the
maintenance
of
the
connection,
because
in
HTTP
2
there
is
one
connection
and
you
have
packets
that
are
running
around
and
each
of
them
returns
to
one
stream
and
the
stream
is
basically
your
request
response,
HTTP
interaction,
so
each
of
these
streams
also
runs
a
single
virtual
thread.
B
So
this
is
the
main
thing
that
we
have
with
the
holiday
4
over
0
will
be
running
on
Virtual
threads,
and
we
will
be.
We
will
be
utilizing
them
from
the
core
of
the
web.
Server
I
will
talk
a
bit
about
the
things
that
we
have
learned
during.
That
I
will
just
show
a
quick
peek
into
our
performance
measurements,
so
the
smaller
number,
the
dark
one,
is
the
number
that
we
could
see
on
helidon
SE.
A
B
B
So
for
me,
the
biggest
lesson
learned
was
you
actually
need
to
unlearn
asynchronous
programming
with
all
the
problems
that
we
had
in?
You
know
Enterprise
applications
in
the
past
decades
when
he
wanted
to
do
anything
fast.
You
always
ended
up
using
it
doing
something
asynchronously
and
now
we
don't
need
to
do
that
and
honestly,
it's
hard
to
tell
yourself
that
you
don't
need
to
do
it,
but
once
you
unlearn
that
you
will
find
out
that
everything
is
easier
to
write,
it
is
easier
to
read
and
it
is
easier
to
maintain.
B
B
B
B
Obviously,
you
need
to
look
at
synchronized
code
in
your
application
to
make
sure
that
you
don't
do
something
that
would
break
the
performance.
I
talked
about
it
before,
especially
when
you
have
any
kind
of
blocking
code
that
is
executed
within
a
synchronized
block
that
needs
to
be
refactored
to
Locks.
B
You
should
think
about
threat
locals
use
them
not
that
much
try
to
remove
them
as
much
as
possible.
There
are
obviously
cases
where
there
is
no
way
around
it,
but
we
have
found
out
that
it's
not
that
big
problem
to
use
a
couple.
It's
a
problem,
if
you
need,
if
you
use
too
many
and
for
me,
which
shows
threads,
are
the
best
Improvement
in
Java
ever
and
I'm
working
with
Java
since
version
1.1
and
honestly.
This
is
like
the
best
thing
that
ever
happened
to
it.
So.
B
B
We
have
found
out
that
the
jvm
has
no
problem
garbage
collecting
it
very
fast
and
we
didn't
see
any
performance
impact
of
this
part.
On
the
other
hand,
when
we
try
to
reuse
buffers
with
all
the
virtual
threads
that
you
have,
it's
actually
costing
you
time
and
CPU,
so
it
is
better
not
to
reuse
them
and
again
relearn
to
use
blocking.
It
is
much
easier
for
everything
we
found
out
something
that
is
a
bit
unfortunate.
B
There
are
a
few
performance,
sensitive
things
that
depend
on
the
operating
system,
and
one
of
those
I
already
talked
about
is
asynchronous
rights,
TCP
no
delay
or
the
Nagle
algorithm.
Sometimes
it's
faster.
Sometimes
it's
not
if
you
use
Mac
OS,
it
works
just
fine
with
TCP,
no
delay
and
synchronous
rights.
If
you
use
the
latest
Linux
kernel,
you
will
find
out
that
it's
not
so
good.
If
you
use
an
older
Linux
kernel,
it
works
the
same
as
on
Mac
OS.
So
there
is
like
a
bunch
of
things
that
are
happening.
B
So
if
you
want
to
achieve
top
performance-
and
you
have
requirements
of-
let's
say
hundreds
of
thousands
to
Millions
requests
per
second
on
your
system,
you
will
need
to
do
proper
due
diligence
on
your
environment
and
you
should
not
upgrade
your
Linux
kernel
blindly.
You
should
first
make
sure
that
there
is
no
performance
impact
and
this
is
not
really
a
performance
impact
on
holiday
side.
It
is
on
the
socket
level
of
jvm
I
think
that
this
will
improve
over
time.
B
B
Again,
HTTP
2
I
was
surprised
that
HTTP
2
is
quite
complicated.
It's
much
harder
to
read
for
humans.
What
is
happening
on
the
network.
On
the
other
hand,
it's
the
best
thing
for
virtual
threats,
so
I
would
recommend
to
use
HTTP
2.
It
really
is
the
Right
Way
Forward
Right
Way
Forward,
because
you
utilize
your
connections
better.
You
don't
need
to
have
10
connections
from
a
single
client
just
because
you
are
running
10
things
in
parallel.
You
can
use
a
single
connection
and
run
it
all
on
that
single
one.
B
B
If
you
want
to
run
grpc,
you
need
to
run
it
as
a
separate
server,
because
there
we
use
the
Neti
grpc,
which
cannot
be
combined
with
the
rest
of
halidon,
and
one
of
the
targets
that
we
set
is
to
actually
remove
all
dependencies
on
Native
from
alidon.
So
the
only
server
that
will
be
in
early
learn
will
be
holiday.
B
Nema
now
last
thing:
I
have
a
slide,
for
is
one
thing
that
we
don't
solve,
and
this
cannot
be
solved
with
virtual
threads
and
it
can
be
solved
in
reactive
as
well
and
that's
obstruction
of
a
threat,
and
we
get
this
question
quite
often
like.
So
how
do
you
solve
the
problem?
And
you
know
a
threat
wants
to
run
a
long-term
task.
That
is
fully
utilizing
it
and
it's
using
yields,
and
my
answer
will
be
well
you
do
it
the
same
way
that
you
did
it
in
reactive.
B
You
run
it
on
a
different
executor
service
and
you
wait
until
it
finishes
so
with
reactive.
You
would
probably
have
some
completable
future,
where
you
would
say
then
accept-
and
you
know,
do
your
task
well
in
Virtual
threats
and
in
helidon.
You
would
just
have
call
get
on
that.
Completable
future
and
your
virtuous
threat
will
be
blocked
and
that
asynchronous
obstructing
tasks
can
run
the
way
that
you
intended
it
to
run
so.
B
B
B
On
the
left,
I
have
code
that
is
written
for
helidon
Nema
and
on
the
right.
I
have
code
that
is
written
for
Holiday
reactive,
and
we
can
see
that
as
long
as
you
do
a
very
simple
task
like
in
this
case
I'm
just
calling
a
remote,
client
and
I'm
getting
the
string
entity
from
it
and
then
I'm
sending
it
back.
B
It
looks
very
similar,
like
you
get
your
requests,
you
get
a
future
of
a
string.
Single
is
just
a
like
a
computable
future
in
halidon,
and
then
on
that
response.
You
say:
okay
for
single,
which
is
similar
to
then
except
for
a
completed
future.
Just
send
it
over
the
response,
and
if
there
is
an
exception,
send
it
exception
using
the
response,
and
this
will
do
an
internal
server
error
with
halidon
4,
it's
booking,
so
you
say:
I
want
to
get
my
remote
string
entity.
B
You
just
get
it.
You
don't
get
a
future.
You
get
that
entity
and
I
said:
oh
I
want
to
send
it
over
the
response
and
I'm
done.
I,
don't
care
about
exceptions?
If
an
exception
happens,
it
will
be
taken
care
of
by
the
system,
and
you
will
get
that
appropriate
internal
server,
or
maybe
that
exception
will
be
mapped
correctly
to
an
error.
Handler
that
you
have
registered
with
the
server
but
where
it
becomes
inter
more
interesting
is
in
in
the
complex
cases.
B
So,
let's
say
I
want
to
use
the
status
code
that
was
returned
by
the
remote
site
and
I
want
to
set
it
on
the
response
and
in
blocking
world
I
submit
my
request.
I
get
a
response
and
then
I
set
the
status
and
I
send
the
response,
and
if
I
wanted
to
send
an
entity,
I
could
just
say
you
know,
client
response.
B
B
You
do.
The
same
thing
in
reactive
programming
suddenly
needs
to
expand
your
lambdas,
and
here
in
the
correct
place
you
will
say:
oh
here,
I
get
my
response.
I
can
do
something,
but
if
you
wanted
to
do
something
with
the
publisher,
it
will
be
actually
much
more
complicated
and
now
imagine
that
here,
when
you
re,
when
you
get
the
response,
you
would
like
to
do
two
tasks
in
parallel
and
then,
depending
on
the
response,
you
will
need
to
do
something
and
I
can
tell
you.
I
did
that
code
we
actually
implemented
it.
B
I
spent
probably
one
hour
trying
to
troubleshoot
it
and
make
sure
that
everything
works
correctly,
and
it
is
really
done
asynchronously,
because
it's
not
a
simple
task.
If
I
did
it
in
broken
code,
I
know
my
executor.submit
and
you
know
how
to
handle
that
and
how
to
wait
for
the
future.
So
really
my
world
isn't
much
simpler.
Now,
I
I
don't
have
a
problem
with
writing
code
for
synchronous.
I
do
always
have
a
problem.
Writing
code
for
reactive
and
I
can
tell
you
I'm,
not
the
only
one.
B
A
A
So
if
you
are
interested
kindly
fill
out
the
form
that
I'm
going
to
link
into
the
chat
and,
of
course,
if
you
have
any
feedback
on
the
tech,
talk
programs,
we
would
love
to
hear
from
you.
So
once
we
end
the
broadcast,
just
click
on
the
green
button
that
pops
accept
and
let
us
know
how
we
can
improve
it.
A
B
Think
that
one
of
the
reasons
is
that
you
know
the
out
of
memory.
You
would
really
need
to
fill
your
memory
with
all
the
HTTP
headers
that
are
coming
in
and
because
the
lifetime
of
a
single
request
is
quite
short,
you
know
the
garbage
poetry
has
enough
time
to
clean
it
up
so
I'm
sure
you
could
run
out
of
memory.
B
You
know
if
you
build
an
application
that
will
read
everything
from
the
request
and
then
sleep
for
10
seconds
and
then
return
it,
and
then
you
hit
it
with
1
million
requests.
Yeah.
You
will
probably
run
out
of
memory,
but
that
is
a
new.
It's
not
a
new
thing.
You
know
the
same
thing
happens
in
reactive.
B
The
same
thing
happens
if
you
have
a
booking
application,
if
you
have
too
many
in
progress
requests,
you
will
run
out
of
memory,
but
you
always
have
an
option
to
you
know
control
how
many
requests
you
have
in
memory
so,
like
I,
think
that
there
are
a
lot
of
problems
that
didn't
disappear.
You
know
you
will
still
need
to
take
care
of
performance.
We
will
hit
different
bottlenecks
than
we
used
to
hit
so,
for
example,
in
the
old
applications.
B
Usually
your
database
was
one
of
the
biggest
bottlenecks
and
your
threads
were
the
biggest
second
biggest
bottleneck
with
virtual
threads.
You
know
database
will
stay
and
there
is
no
difference
unless
the
databases
come
up
with
a
solution
to
you
know
better
utilize,
utilization
of
HTTP
or
sockets
to
handle
multiple
requests.
There
will
probably
be
the
bottleneck
still
and
memory,
of
course,
will
become
the
next
bottleneck
when
you
have
all
of
requests,
because
you
will
be
able
to
load
your
services
with
higher
load.