►
From YouTube: 2021-10-07 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
D
A
A
E
E
D
So
please
add
your
name
to
the
candy
list
in
the
in
the
meeting
notes.
Also,
if
you
have
anything
to
discuss
attitude
agenda,
I
pre-edit
a
few
things,
so
just
starting
with
the
first
one.
This
is
the
the
old
tab
that
we
have
looking
have
been
looking
at
the
other
last
last
few
weeks,
which
proposes
like
the
scenarios
and
also
very
rudimentary
roadmap.
D
D
Otherwise,
maybe
it
would
be
great
if,
if
you
could
just
approve
the
pr
I
mean,
even
if
you're,
not
an
official
approver
for
this,
for
this
repository
you
can
still
approve,
and
your
approve
will
just
not
show
up
as
a
green
check
mark,
but
there's
a
great
check
mark
here,
but
I
think
it's
just
good
to
convey
that
yeah.
We
came
to
some
consensus
here
and
that
that
we
see
that
certain
people
involved
in
this
work
group
agree
on
the
scenarios
and
on
the
scope.
D
Not
sure
if
any
of
you
who
are
here
have
like
still
any
any
blockers
for
this
pr,
if
you
have
anything
in
mind,
you
could
also
discuss
here.
Otherwise,
please
just
have
another
look
at
the
pr
and
yeah.
If
there's
anything
that
you
think
is
blocking
add
a
comment.
Otherwise,
maybe
a
proof.
D
And
for
four
next
steps,
then
I
think
today
we
have
something:
that's
a
bit
like
off
topic
like
the
semantic
convention
for
cloud
events.
I
mean
off-topic
regarding
of
this
of
this
old
tap
here,
but
I
think
next
steps
would
be
that
ludmila
she
volunteered
to
give
a
demo
today
about
how
messaging
instrumentation
looks
for
azure,
sdk
and
azure
monitor
to
think
that
could
give
us
an
an
idea
of
like
what
we
are
trying
to
achieve,
or
might
also
give
us
an
interior.
D
But
maybe
do
we
want
to
do
better
and
based
on
this
in
the
next
meeting,
then
yeah
I
would
if
no
blockers
come
up
here.
I
would
like
dania
to
start
then
talking
about
the
actual
spec
changes
that
we're
gonna
do
maybe,
starting
with
how
we
are,
how
we
plan
to
handle
context
propagation.
E
D
Awesome
then,
let's
go
to
the
next
point
here
to
semantic
convention
for
cloud
events.
There
is
a
pr
by
rau.
There
have
been.
Some
has
been
quite
some
discussion
on
the
pr,
also
some
opposing
opinions,
mostly
regarding
whether
we
want
to
also
define
I
mean
there
is
consensus
about
the
attributes.
D
I
myself,
I
did
not
have
a
too
strong
opinion
about
that.
I
voted
for
just
having
the
attributes
there,
but
there
are
other
people
like
luke
miller
and
also,
I
think,
show
you
in
your
initial
pr
use,
packed
out
like
a
span
structure
and
autoload
miller
would
like
to
have
like
this
more
kind
of
would
have
this
a
more
like
a
more
rigid
specification
around.
B
So
without
defining
expanse,
maybe
temporary
it's
an
experimental
spec
right,
so
we
don't
have
to
keep
it
forever,
but
without
defining
expense.
I
don't
feel
we
can.
We
should.
We
should
emerge
it
because
it's
it's
not
enough.
It's
not
going
to
enable
anyone
to
do
anything.
Basically,
I
cannot
implement
it
in
my
sdks.
E
E
E
It's
called
captain,
it's
also
in
go
and
they
use
this
go
sdk
and
it
has
proved
to
be
useful
because
the
http
auto
instrumentation
is
basically
like
it's
nice,
but
it
doesn't
doesn't
really
help
much
when
investigating
like
why
this
doesn't
work
or
what
what
operation
was
this
because
it
yeah.
So
I
I'm
also
on
the
side
that
I
think
creating
this
pen
also
helps.
E
But
the
part
where
I'm
not
sure
which
is
probably
hard
is
about
the
about
the
context
propagation
in
this.
This
distributed
tracing
extension
that
they
have,
because
for
my
case
that
I
that
for
the
application
that
I'm
instrumenting
on,
they
send
the
event
vhtp
and
then
this
event
gets
put
into
queue
and
then
some
other
process
takes
it
and
then
there's
no
way
to
continue
the
trace
at
that
point
yeah.
So
what
I
did
is
I
used
it
was
convenient
that
they
already
had
this
in
the
go
sdk.
E
E
B
In
our
sd
case,
when
we
cannot
continue
the
trace,
we
are
considering
getting
some
convenience
method
like
it
would
be.
I
don't
know
something
on
the
clone
event
or
around
it
to
extract
the
context
and
populate
the
spam
context.
Instead
and
it's
useful
beyond
cloud
events,
it's
useful
basically
for
any
messaging
system.
When
the
protocol
is
user,
don't
care
right,
so
they
they
want
to
just
extract
the
context.
So
maybe
we
want
to
even
hide
the
the
propagator
behind
some
method.
E
Yeah,
but
that's
what
I
did
in
the
go
sdk
I
created
this
helper
method,
just
yeah,
you
just
pass
the
event
and
the
goal
context
and
it
just
does
the
magic.
So
if
you
pass
the,
if
you
want
to
inject,
you
pass
the
same,
clean
context
and
the
event
now
the
context
with
the
spam
contacts
already
and
the
cleaning
event
and
then
injects
into
the
event,
and
then
you
want
to
extract.
E
E
B
So
I
guess
the
rule
of
thumb
when
we
cannot
trace
so
I
I
can
like
formulate
some
proposal
around
how
to
create
stance
how
to
propagate
the
context
it
can
be
temporary.
It
doesn't
have
to
be
like
if
it
will
ever
contradict
with
whatever
we
decide
for
messaging
systems.
B
We
can
change
it,
but
basically
the
idea
that
I
think
is
not
very
controversial
that
once
the
cloud
event
is
created,
there
should
be
a
context
assigned
to
it
right
and
put
into
this
extension
and
then,
when
you
send
it,
it's
irrelevant
like
to
the
to
the
cloud
events
right.
B
Maybe
you
send
a
budge
whatever,
but
basically
we
create
a
producer's
pen.
When
message
is
created,
it's.
It
is
strange
in
terms
of
open,
telemetry
and
we'll
talk
about
it
in
messaging,
but
we
don't
have
other
way
to
have
a
unique
context,
except
if
we
create
a
span.
So
it's
a
producer's
pen.
B
The
context
is
populated
on
the
cloud
event
and
on
the
consumer
side
it's
either
the
sdk
that
can
read
a
stun
start.
The
span
from
this
cloud
event
or
create
the
link
from
this
cloud
event
for
the
consumer
spend
or
it's
the
user
who
creates
the
spam,
because
sdk
just
doesn't
have
the
api
to
process
the
event.
B
So
we
have
a
producer
and
consumer
spends
and
they,
the
context
is
propagated
through
quote
event,
it's
pretty
straightforward
and
probably
will
be
similar
to
what
we
do
for
messaging.
D
E
Okay,
but
then
what
I
was
thinking
is,
but
what
happens
if
the
so,
for
example,
in
my
case,
I
I
I
put
this
on
the
on
the
event.
So
like
your
example,
so
before
saving,
I
create
a
span
for
the
cloud
events.
E
I
put
this
the
current
context,
which
is
the
one
that
I
just
created
into
the
event
and
then
I
send
so
what
happens
if
the
protocol
that
I
am
using
is
already
auto
instrumented,
then
it
will
create
another
span
right
of
the
outgoing
message
and
then
let's
say
that
the
receiver
is
also
also
instrumented
and
then
the
called
event
expanded
is
inside
is
already,
let's
say,
not
the
latest
or
it's
it's
old
in
the
in
the
chain.
Right.
B
You
see
the
transport
calls
are
to
some
extent
irrelevant,
so
you
can
send
clock
bunch
of
cloud
events
right
then
this
transport
call
it
can
even
happen
in
a
different
context.
I
will
show
later
in
my
demo
that
you
can
send
a
budge
and
you
can
buffer
it
and
you
send
it
later
right
receiving
your
receipt,
but
you
don't
even
know
what
you
receive
if
you
cannot
associate
it
nicely
with
what
you
receive
well,
there
are.
B
There
are
some
tricks
open
to
other
attempts
to
do
currently,
but
basically
the
transport
call
is
irrelevant.
You
don't
have
to
think
about
it.
So
what
I
suggest
that,
maybe
when
we
do
it
with
the
actual
messaging
stuff,
then
we
will
have
to
think
how,
like
maybe
the
send
call
correlates
to
what
it
sends
right.
So
we
should
know
when
the
message
was
actually
sent
if
it
was
sent
in
batch
and
buffered.
D
When
we
look
at
this
stages
that
fill
it
out
here
that
we
have
basically
that
we
somehow
work
with
two
like
layers
of
context
that
have
a
transport
context
which
works
on
the
transport
layer,
which
might
be
like
passing
context
between
publish
and
receive
spans.
D
D
So
we
basically
have
have
those
two
layers
that
somehow
correspond
to
each
other,
and
this
is
basically
mirrored
in
those
in
the
context,
propagation
logic
that
we
come
up
with
and
then
maybe
that
is
a
anyway
contrary
to
what
I
said
initially
good,
that
we
start
to
work
on
that
for
cloud
events,
because
I
think
it
ties
in
very
well
with
the
context
propagation
discussions
that
we
will
need
for
messaging.
In
general.
E
Because
this
diagram
is
quite
useful
because
I
can
use
it
to
explain
so
in
my
case,
what
I
did
is
so
there
is
like
three
applications
in
my
case
like
like
we
have
now.
So
there
is
the
producer
and
in
my
case
I
create
the
cloud
events
and
I
create
a
spam,
but
I
don't
put
the
current
spam
yet
into
it.
E
Yeah
and
then
I
send
to
intermediary
via
http,
and
then
this
intermediary
is
all
instrumental,
so
it
will
have
the
the
the
hotel
middleware
automatic
created,
stand
in
there
and
then
before
putting
into
the
queue
which
is
my
intermediary.
Does
it
publish
it
to
a
queue
so
before
pushing
to
a
queue?
Then
I
take
the
current
span
and
put
inside
the
event
and
then
the
receiver
on
the
consumer
side.
E
Then
it
gets
the
message
from
the
queue
or
the
notification
from
the
queue
and
then
it
reads
from
the
event:
the
the
current
trace
context.
B
So
the
problem
with
it
like
if
we
go
beyond
this
specific
case,
that
let's
say
you
have
a
service
as
an
intermediary:
it's
not
the
direct
http
request
you
make
and,
for
example,
in
azure
it's
called
event
grid.
I
think
there's
something
similar
in
aws
event,
bus
or
something
like
that.
So
you
create
an
event.
You
publish
it
and
it
goes
through
you.
You
don't
know
how
many
hopes
right
right.
So
it's
not
up
to
you.
You
don't
even
have
this
telemetry,
it's
just
lost
right.
B
D
Okay,
so
for
for
this
topic,
then
I
I
gathered
that
ludmila
and
rao
you
both
will
work
on
basically
maybe
specking
out,
and
I
don't
know
maybe
other
prototyping,
like
the
cloud
events
like
a
more
detailed
cloud.
Events
spec.
D
Okay
awesome,
then,
I
will
capture
that
here
and
also
write
a
note
in.
B
Thank
you
for
letting
me
can
you
can
you
let
me
share,
because
I
cannot
share
well
you're
sharing
your
story.
B
Sorry
it's
an
early
morning
for
me,
so
I
I
can't
forget
my
own
name
yeah.
So
what
I
wanted
to
show
is
what
we
do
with
messaging
in
azure.
As
the
case
we
created
the
instrumentation
before
the
current
conventions
were
published.
So
it's
a
bit
different
from
what
we
have
and
the
current
conventions
don't
work
for
us.
B
So
I
guess
we're
still
pretty
close,
but
we
use
old,
attribute
names
from
open
tracing
and
it
it's
been
quite
different.
Oh
I'm
sorry,
I'm
definitely
it's
too
early
and
I'm
sharing
their
own
quinoa.
B
So
the
first
thing
is
sdk,
instrumentation
and
messaging.
We
have
to
think
about
the
api
like
what
api
do
we
expose
to
users
and
the
this
is
the
event
hub
sdk,
and
we
assume
that
people
must
descend
batches,
because
it's
like
the
kafka,
we
assume
it's
either
we
send
batches
or
we
receive
batches
or
both
or
basically
it's
some
streaming.
B
So
maybe
individual
messages
don't
make
too
much
sense,
but
basically
the
api
we
have
is
that
we
have
a
badge
and
we
put
messages
into
it
and
we
send
it.
We
can
send
individual
events.
This
is
the
api.
We
have
too
so
and
let's
think
about
it,
so
this
is
the
web
application,
but
potentially
it
can
have
some
other
application
where
I
indeed
buffer
up
messages
and
they
send
them
once
I
have
enough.
B
Maybe
I
want
to
optimize
some
bandwidth
or
something,
but
basically
this
is
my
very
naive
attempt
to
create
such
thing.
What
it
does
is,
it
keeps
adding
messages
to
a
badge
until
it
reaches
certain
sites
and
then
it
sends
it
or
until
it
cannot
add
more
so
what
you
can
see
in
in
this
case,
we
will
have
messages
created
in
a
context
of
http
requests
and
sent
later
in
context
of
something
else,
maybe
a
background
thread
or
something
right.
So
this
is
the
possibility.
B
So,
on
the
consumer
side,
we
also
have
different
deep
guys,
and
one
of
them
is
like
this
is
the
through
some
java
magic
that
we
consume
a
single
message
right.
There
could
be
a
case
when
we
consume
a
batch.
This
is
a
badge,
so
we
have
api
to
consumer
page.
We
also
have
an
api
to
just
call
the
consumer
and
receive
stuff
without
processing.
We
we
don't
even
process
those
messages.
Right,
so
can
users
receive
just
a
list
of
events
and
whatever
they
do
with
them.
We
don't
know
we
don't
control
it.
B
We
don't
know
if
for
loop,
is
there
or
basically
nothing
about
it?
Okay,
so
was
this
how
we
end
up
instrumenting-
and
I
I
didn't
have
time
to
prepare
the
azure
monitor
example.
So
I
have
some
screenshots,
but
I
will
show
you
jager
instead
and
it's
not
because
azure
monitor
doesn't
work,
it's
because
I
I
didn't
have
time.
B
So
this
is
a
very
simple
example
when
this
is
the
the
control.
So
this
is
the
http
request.
The
controller
so
interesting
stuff
starts
here.
So
this
is
the
consumers.
When
we
create
it's
a
message,
it
has
somehow
it
has
60
millisecond
duration,
but
maybe
it
was
just
me
debugging
stuff,
so
this
is
the
local
call
it
doesn't.
It's
just
creates
the
context.
Does
nothing
else
except
creating
a
context.
B
It
has
some
information
to
identify
the
entity,
the
event
tab
service
that
we
work
with,
though,
but
basically
it
captures
the
context,
and
here
is
where
it's
processed,
it's
processed
twice.
Probably
I
didn't
checkpoint
it
correctly.
First
time
or
something,
but
you
see
there
are
two
different
processings
and
then
there
is
a
stuff
happening
underneath,
and
this
is
actually
check
pointing
post.
B
B
So
this
is
the
example
when
we
buffer
events
before
sending
them.
So
here
we
create
a
message
and
it's
processed
twice
processed
twice
I
don't
know,
and
then
we
see
that
there
is
a
sent
call.
It
contains
multiple
references,
it's
links
to
all
the
messages.
This
is
this
message
that
we
see
in
this
trace,
but
those
are
different
traces
because
there
was
five
messages
in
this,
but
in
the
send
call
so
we
can
in
jager
we
can
move
to
this
thing.
It
doesn't
show.
B
Unfortunately,
it
doesn't
show
the
processing
because
it
was
batch
processing
and
it's
linked,
but
the
the
actual
process
call
has
a
link
to
this
message.
It
can
be
shown
in
yeah
in
azure,
monitor
ui.
So
this
is
a
similar
case
where
we
have
a
message
it's
linked
to
send,
even
though
it's
a
different
trace
and
it's
linked
to
process.
E
E
One
that
is
open
is
is
what
they,
because
I
was
reading
the
old
map
that
johannes
mentioned,
and
then
I
saw
some
things
mentioned
like
logical
scent
and
then
because
in
some
place,
logicals
logical
standard,
logical
great.
So
this
this
is
just
creating
the
the
the
message
right
like
creating
the
the
actually
instantiated
the
messaging.
So
as
part
of
that,
you
also
create
a
spam.
Okay,
yeah.
E
Is
the
actual
transport
call
okay
and
then
you
you
when
you
send,
then
you
link
this
the
message
to
this
transport
scan.
A
B
It's
fully
magical
right
so
because
we
we
know
when
messages
created
in
which
scope
right,
we
can
attach
context
to
it
and
then,
when
we
send
it,
we
can
actually
link
this
context
to
the
send
operation.
E
Okay,
but
is
this
something
that
you
did
in
the,
but
this
is
part
of
the
of
the
of
your
sdk.
The
azure
monitor
okay,
gotcha,
okay,.
B
Yeah
so,
for
example,
here
I
have
a
call
where
I
have
a
message
still
to
processing.
I
don't
know
why.
But
basically
I
have
a
message.
I
have
a
process.
There
is
no
scent
here,
it's
just
jagger
who
cannot
find
it,
but
like
still,
we
have
the
scent
somewhere,
which
has
the
link
to
this
message.
So
assuming
you
have
some
indexing
on
the
back
end,
you
can
still
show
it.
E
But
how
well,
how
is
the
linking
going
to
happen
so
so
for
so,
if
I
got
it,
if
I
understand
it
correctly,
is
that
you
will
put
this
the
the
situation
context
into
the
message
and
then,
when
you
send
it,
the
the
instrumentation
will
say:
okay,
I
already
have
a
context
in
this
match.
I'll
add
a
link
because
I
have
it.
Is
that
your
idea?
Okay,
I
think
that's
that's
good.
Actually,.
D
D
B
B
B
So
if
we
knew
we
are
sending
cloud
events,
we
can
possibly
access
the
the
tracing
context
of
the
cloud
event,
but
we
don't
know
so
it
sounds
like
we
cannot
do
a
good
job
here.
So
we
we
should
either
support
cloud
events
and
then
don't
instrument
messages
in
the
event
hub
or
other
messaging
facilities,
or
we
should
ignore
the
cloud
event
context
and
only
care
about
the
messaging.
D
Yeah
because
I,
for
example,
wonder
if
this
this
link
from
the
basically
those
to
stick
with
how
recorded
in
our
model
before
from
the
publishing
to
the
creation
context,
which
I
think
to
see
this
here
is.
I
wonder
if
this
can
only
be
a
best
effort
thing,
because
I
wonder
in
pub
whether
in
the
publishing
stage,
you
maybe
even
don't-
have
an
idea
of
the
format
of
the
message
that
you're
sending.
B
A
E
Question
sorry
about
your
question,
is
I
didn't
quite
get
so
you
said
like
three
but
but
for
example,
let
me
show
now
she
creates
the
span
for
the
creating
the
message,
but
the
problem
is
that
I
mean,
if
I
do
the
same,
let's
say
I'm
using
cloud
events.
If
I
do
the
same,
when
I
create
the
cloud
event
and
the
producer
I
create,
then
I
also
create
the
context
and
I
put
inside
the
event,
but
the
problem
is
that
you
don't
know
if
it's
this.
E
B
E
Yeah,
it
is
because
in
the
go
sdk
they
have
the
client
and
and
then
the
client
is
saying,
that's
what
I
did
so.
I
create
the
the
spam
because
the
the
sdk
offers
a
hook
where
I
can
just
create
spams
when
it's
sending
or
receiving
things
like
that,
but
it's
not
in
the
specters,
so
I
think
only
the
go.
Sdk
is
doing
it,
not
the
others.
As
far
as
I
looked.
B
B
So
how
do
I
hide
it
here?
So
you
see
there
are
links
here.
It
contains
multiple
references
and
this
is
the
things
it
processes
so
because
we
receive
the
batch
we
don't
know
like.
We
cannot
create
a
spend
per
message
right,
because
the
api
is
the
thing
that
we
call
looks
like
this
right.
So
this
is
the
user
code
running
whatever
they
do
here.
Maybe
they
drop
it
on
the
floor.
Maybe
they
process
just
the
first
message:
we
it's
unlikely,
but
we
we
have
no
control
over
it.
B
We
cannot
instrument
for
each
loop,
even
though
I'm
redeed
in
node.js
right
yeah.
So
we
we
cannot.
We
want,
and
basically
the
thing
we
can
do-
we
can
create
a
span
around
it
and
we
can
link
anything
that
happens
outside
of
this
call
right
and
then,
if
we
had
the
convenience
method
that
will
take
context
from
this
batch
like
I
want
to
write
something
like
event,
data
extract
context,
and
I
I
want
to
create
a
span
from
it.
The
users
can
do
it
and
like
in
our
documentation.
B
B
So
then
the
feedback
we've
got,
we
kind
of
tried
to
be
very
generic,
so
we
always
do
links
like
when
we
send.
We
have
a
message,
spend
like
this
creation
and
send
spend
the
publishing
and
it's
confusing
to
everyone
who
don't
use
this
batching
and
for
those
who
uses
batching.
Probably
it's
also
confusing.
B
So
what
people
complain
about,
for
example,
here
that
if
they
send
a
budge,
there
are
just
too
many
messages
and
they
complain
about
costs.
I
don't
know
how
to
solve
this
problem.
B
They
don't
understand
why
the
send
call
is
like
it
doesn't
follow
the
message
thing,
because
we
give
a
preference
to
like
the
processing
and
like
the
children
rather
than
this.
This
is
a
sibling
actually
to
the
message
for
in
common
case.
B
The
sand
is
a
logical
goal,
so
it
should
hydrate
right,
so
I'm
I'm
just
trying
to
find
out
what
they
can
do
to
for
users.
Maybe
this
should
be.
The
span
should
be
even
lighter.
Maybe
it
shouldn't
have
any
attributes,
but
then
it
would
be
hard
to
show
it
like
the
topology
map,
because
we
won't
be
able
to
know
where
this
message
was
sent
to
yeah.
So,
like
the
feedback
is
it's
it's
a
bit
costly
and
confusing
to
see
my
champion
works.
D
I
mean
I
can
say
something
or
it
is
a
bit
confusing
to
me
to
see
like
the
link
to
the
process
stage
actually
before
the
sense
fan
appears
yeah.
That's.
E
E
E
I
was
going
to
ask
what
did
they
say
about
this
expensive
costly,
but
why.
B
B
D
D
Is
that
is
that
a
link,
or
is
that
a
span?
It's
not
the.
D
B
Yeah
yeah
and
one
more
thing:
I
we
don't
do
we
don't
instrument
receiving
messages
at
all
and
the
reason
for
it.
It's
because
we
have
like
school
that
we
have.
Let's
say
users
do
this:
they
just
receive
something
what
it
means
that
actually
we
are
waiting
for
event
hub
to
push
messages
to
us
in
the
client
application
and
either
for
timeout
or
the
number
of
messages,
and
it's
it's
not
a
remote
call.
It
doesn't.
The
duration
doesn't
tell
you
anything
because
it's
just
how
many
messages
are
there
are
flowing
right.
B
It
doesn't
tell
me
about
my
service
basically
about
the
pressure
I
have
and
also
like
it's
the
sampling
problem,
assuming
I'm
sampling.
I
will
sample
this
span
inconsistently
with
whatever
I
will
receive,
because
I
don't
know
what
I
will
receive.
So
we
kind
of
thought
that
I
don't
we
don't
know
how
to
do
it
properly.
B
We
have
some
feedback
that
people
wanted.
As
far
as
I
understand
mostly
to
show
this
the
the
topology
map
that
we
have
something
like
this
so
like
they
want
to
know
that.
Okay,
even
if
even
if
I
didn't
process
anything
I
connected
to
this
event
hub,
I
am
receiving
the
messages
from
it,
but
we
still
don't
know
how
to
they
make
their
receive,
call
consistent
and
make
it
make
sure
it's
sampled
properly,
and
I
don't
think
we
have
any
way
to
do
it
now.
D
So
basically
the
receive
operation
so
does
the
send
operation?
Does
it
send
its
context
at
all,
or
does
it
propagate
its
context?.
B
Well,
no
so
like,
maybe
because
the
batch
of
messages
is
wrapped
into
amqp.
Perhaps
we
stamp
some
context
on
this.
The
batch
message-
I'm
not
actually
sure,
but
there
is
nothing
that
cares
about
it.
Yeah.
If
I
do.
C
The
for
the
receive
spans,
what
we're
doing
in
the
java
instrumentation
today
is
we
don't
we
track
the
timing
from
before
the
receive
call
was
made
when
the
receive
call
starts,
but
we
don't
create
the
span
until
it
returns
so
that
we
can
look
at
if
there
were
any
messages
received.
B
I'm
a
bit
worried
about
like
let's
say
if
we
report
some
logs
that
whatever
happens
before
we
create
a
span,
is
not
correlated,
but
that's
that's
a
minor
thing:
yeah
yeah
and
basically,
in
the
past,
we've
instrumented,
even
before
open
telemetry,
we've
instrumented
some
of
the
libraries
that
we
have
like
the
event
hub
of
previous
version
of
service
bus
and
we
instrumented
receive
call,
and
it
was
not
great.
We
got
a
lot
of
feedback.
That
user
complain
like
they
see
this
operation
that
lasts
for
60
seconds,
for
example,
and
it's
a
timeout.
B
It
basically
means
that
you
didn't
receive
anything
in
one
minute:
it's
not
an
error,
it's
not
a
failure.
It's
perfectly
fine!
It's
just
you!
Don't
have
any
load
on
your
system,
so
we've
got
a
lot
of
complaints
about,
like
the
schools
being
confusing
and
noisy.
So
it's
just
immediate!
You
you
go
and
you
think
you
you
request
more
and
more
messages
and
you
never
got
anything
and
it's
full
of
errors
and
long
operations.
That,
like
don't
look
great
so
probably
we
will
solve
this
problem,
but
we
don't
have
a
solution
yet.
C
Yeah
I've
found
receive
spans,
also
yeah,
I've
gotten
similar
feedback
on
the
receive
spans.
We
introduced
a
flag
in
the
java
instrumentation
to
suppress,
receive
spans
and
in
our
distro.
C
We
are
suppressing
those
receive
spans
by
default,
just
because
yeah
it's
it's
we've
gotten
more
questions
and
confusion
than
it
has
been
helpful
and
and
also
there's
not
really,
since
it
doesn't
really
contribute
to
the
flow.
There's.
Not
a
the
value
is
a
lot
less.
B
F
Yeah,
so
I
just
just
wanted
to
make
this
kind
of
remark
or
ask
a
question.
So
basically,
every
time
we
are
instrumenting
this,
like
asynchronous
communication
with
messaging.
Basically,
we
want
to
provide
users,
some
insights,
what
is
happening
like
on
sent
on
receive,
and
sometimes
as
we
see
here
in,
like
a
buffer
processing
or
buffer
receiving,
we
have
a
batches
right
so
basically
like
we
are
multiplexing
these
events
like
putting
them
to
batches
and
then
we
are
demultiplexing
them.
F
So
that's
definitely
there
are
links,
but
the
way
how
sdk
works,
at
least
for,
like
even
hubs
on
the
receiver
side.
We
have
this
kind
of
background
threat.
It
actually
consumes
all
messages
to
the
client
regardless
right.
If
you
want
to
receive
them
or
not,
because
every
time
you
just
start
a
consumer,
it
just
starts
consuming
all
these
messages.
F
So,
like
my
idea,
maybe
here
will
be
just
maybe
we
can.
You
know
somehow
combine
transport
level
with
this
kind
of
messaging
level.
In
terms
of
we
can
we
can
treat
messaging
as
a
logical
thing
and
transport
as
transfer,
so
by
combining
this
together
we
can
understand
the
flow,
but
definitely
this
flow
will
be
extremely
verbose.
F
So
maybe
we
can
also
apply
this
idea
of
kind
of
collapsing.
Some
events,
or
something
like
this
so
like
just
just
trying
to
thinking
out
loud
in
terms
of
the
end
goal
so
and
end
users
just
want
to
see
this
consistent,
end-to-end
trace
or
consistent
and
in-trend
flows
flow,
which
can
contain
many
traces
and
looks
like
just
just
staying
on
the
messaging
like
a
layer.
F
We
cannot
achieve
this
exact
flow,
so
we
cannot
visualize
or
we
cannot
collect
enough
information
just
to
just
visualize
this
and
to
end
flow.
B
What
do
you
mean?
We
can't
like,
for
example,
this
is
the
simple
example:
this
is
the
end-to-end
flow
right,
so
the
idea
of
putting
the
cent
call
the
law
was
that
it's
it's
irrelevant
to
your
application
logic.
It's
just
the
transport
right,
so
it
it
it.
It
doesn't
work
great.
But
basically,
here
this
is
the
flow.
What's
the
problem
with
this
approach,
why
don't
we
can't
we
visualize
it?
We
can.
F
Yeah,
but
in
this
particular
case
we
have
just
kind
of
one
message
right
so
yeah,
even
if
we
just
forget
for
a
second
or
like
about
this
sent
call
in
like
in
the
end
below
right.
So
we
can
just
think
about
this
as
a
message
sent
message
put
to
cue,
then
process,
basically
consumer
spam
and
then
add
player,
something
probably
related
to
business
logic,
but
this
is
for
individual
message
right,
so
it
is
really
similar
to
like
a
synchronized
communication.
Synchronous
http
actually
called
right.
F
So,
but
if
you
have
batch
of
messages,
then
we
have
this
idea
of
batching
them
on
the
on
a
producer's
side,
then
again
we
are
extracting
them
on
a
consumer
side,
so
we
are
probably
working
at
this
point
with
many
traces
right
and,
as
you
said,
we
have
different
ways
of
receiving
messages,
so
we
can
receive
them
with
checkpointing
or
we
can
receive
them
just
just
receive
like
I
just
just
get
these
messages
without
any
like
a
callback
or
this
is
applicable
for
even
hubs
and
kafka,
but
we
have
a
lot
of
different
types
of
messaging
like
and
maybe
we
can
also
like.
F
We
can
like
a
receive,
or
we
can
pick
right.
So
this
is
like
a
two
ways
of
doing
or
communicating
and
for
peak.
I
don't
know
like
a
as
you
said.
Maybe
we
don't
have
any
kind
of
client
or
consumer
side
spans.
So
in
this
case
we
will
not
see
any
kind
of
communication
with
with
the
messaging
system.
So
like
just
my
idea,
maybe
here
just
like
that,
we
probably
need
to
include
transport
layer
to
this
kind
of
communication.
F
The
transfer
layer
I
mean
that's
like
a
communication
layer,
or
should
it
be
like
mkp
tcp,
whatever
it
is,
or
what
we
have
underneath
yeah.
B
But
the
send
call
it's
it's
a
logical
thing
that
hide
the
tal.
We
might
instrument
the
mkp,
but
it
will
be
underneath
it.
F
D
I
mean
I,
I
think
the
receive
instrumentation
it,
especially
in
those
scenarios,
can
be
pretty
complex
because
I
just
think
about
the
others
like
if,
when
some
like,
sdks
prefetch
events,
how
would
you
model
like
to
receive
call
in
that
case
and
that
I
think,
could
even
be
very
confusing
for
users
to
to
have
that
modeled
out-
and
I
mean
one
thought
it
just
came
to
me
here-
is
that
the
I
mean
we
have.
D
Our
two
scenarios
worked
out
the
first
15
minutes
settlement,
the
second
village
with
the
checkpoint
settlement,
and
maybe
we
might
come
to
different
kind
of
optimal
solutions
for
those
two
scenarios,
because
I
think
for
the
individual
settlement.
There's
often,
I
think
much
less
complexity
in
the
transport
layer
than
there
is
for
the
checkpoint
settlement,
like
what
we
see
here
with
event
tabs.
F
Yeah,
it
might
work
better,
but
still
for
individual,
like
settlements.
We
have
these
two,
like
we
have
different
semantics,
like
a
like
a
receive,
is
blocking
right,
for
example,
for
series
bus.
We
can
say
that
we
are
blocking
this
message
until
we
process
it
right
and
we
can
pick
it
so
many
clients
can
pick
the
same
message.
So
that's
basically
the
same
and
as
you
as
you
said,
for
this
prefetching
prefetching
stuff.
It's
basically
the
way
how
even
hub
clients
works
on
the
consumer
side
yeah.
F
So
all
the
messages
already
present
on
the
clients,
because
we
have
prefetching
mechanism
and
definitely,
as
I
said
like
it
will
be
two
verbose,
because
all
this,
if
you
just
go
like
a
straight
instrumenting
all
these
calls,
it
can
be
two.
It
will
be
two
verbose,
so
it
will
be
probably
useful
useless
for
end
users.
So
it
looks
like
we
need
to
have
some
kind
of
collapsing
mechanism
here.
So
that's
that's.
What's
in
my
head.
B
Yeah,
maybe
if,
if
you,
if
you
believe
there
is
a
I'm,
so
I'm
sure
I
captured
the
concern,
but
if
you
can,
maybe
I
don't
know
draw
it
what
we
should
collapse
and
how
I
can
think
about
it.
D
I
think
we
have
to-
or
we
should
like,
wrap
up
now,
because
I
think
still
this
meeting
id
is
reused,
but
that
was
awesome,
luke
miller,
thanks
for
for
sharing
that,
I
think
that
helps
a
lot
to
get
us
going
with
the
with
the
context.
Propagation
discussions
also
showed
us
some
complexities
we'll
have
to
deal
with
so
for
just
for
like
quickly
to
wrap
up
for
action
items
for
now.
So
I
think
that
mill
and
trial
you
will
look
into
the
cloud
events,
semantic
conventions
and
I
for
next
week
for
getting
started.