►
From YouTube: 2023-01-12 meeting
Description
Instrumentation: Messaging
B
D
B
C
E
Right
away,
we're
going
to
click
here,
six
minutes
past
is
on
the
agenda.
Please
add
your
name
to
the
10d
list.
There
is
a
three
things
on
there
actually
last
time.
E
I
said:
oh
I
really
want
to
talk
about
the
adding
links
after
spank
Creation
in
the
spec,
but
when
going
through
the
project
board,
I
saw
some
quite
a
bunch
of
issues
on
there
that
are
still
related
to
attributes
and
I
think
it
would
be
great
if
we
could
go
through
those
and
see
whether
there
is
still
like
work
or
what
work
or
battery
is
working
or
still
needed
or
left
on
attribute
site
so
that
we
can
wrap
up
those
and
then
Luke
Miller
put
that
on
the
trender
and
I
think
that
also
fits
in
actually
pretty
well
with
this,
because,
as
far
as
you
saw,
her
proposal
here
is
also
about
attributes
for
settlement
scenarios.
E
So
maybe
we
could
start
a
disorder
today
that
we
look
through
those.
Let's
look
at
the
board.
Look
through
the
issues,
talk
about
settlement
and
then
adjust
time
left.
We
we
talk
about
spendings
after
creation,
so
the
board
I
tried
to
keying
this
up.
A
bit
in
the
sense
that
I
see
what
issues
are
relevant
and
what
the
I
hear
in
this
table
for
the
V1
column,
I
tried
to
do
some
sorting
and
the
ordering
and
basically
the
first
five
items
here.
They
are
all
related
to
attributes
and
the
rest
here.
E
This
are
related
to
to
a
span
structure.
So
it's
already
that
way.
So
I
thought,
if
you
can
go
from
top
to
bottom,
we
kind
of
can
see
what
is
left
for
the
attribute
work
and
then
we
can.
We
can
also
see
a
bit
of
those
actually
but.
E
Do
we,
what
can
we
do
to
fix
those
effus
and
or
are
there
stuff
here
that
we
actually
don't
want
to
tackle
or
just
postpone
so
it
should
suggests
we
just
go
through
one
by
one.
The
first
is
this:
this
issue
here
that
asks
to
make
the
consumer
client
ID
more
generic
across.
E
So
they
are,
there
are
several
attributes
relating
to
Consumer
group
and
we
have
a
client
group.
We
have
a
client
at
ID,
we
have
a
consumer
ID
and
that's
basically
spread
out
over
like
a
generic
attributes
that
is
Kafka
specific.
That
is
rocket
and
queue
specific
and
let's
actually
open
the
actual
semantic
convention.
So
we
see
because
that
was
all
done
before.
E
E
Okay,
here,
that's
that's,
I,
think
a
good
starting
point.
We
have
here
the
we
have
a
consumer
I,
the
consumer
ID
basically
still
exists,
but
now
it's
it's
like
the
consumer
namespace
and
we
have
the.
We
have
the
DOT
ID
extension
here
and
we
also
have
consumer
basically,
as
a
sub
namespace,
underneath
Kafka
with
consumer.group,
that
you
see
your
basic
results.
We
have
like
the
dot
instead
of
the
underscore
and
under
Kafka.
We
also
have
like
a
client
ID.
E
So
that
is
what
is
I
think
referred
to
here
like
to
ask
for
a
generic
client
ID.
And
let's
see
if
you
also
have
like
a
giant
group.
E
Yes
and
here's
basically
the
rocket
mq,
where
there's
also
a
client,
ID
and
also
client
group.
Basically
client
ID
exists
for
both
rocket
mq
and
Kafka,
and
it
sees
it
yeah
it
exists
currently
for
Kafka
and
for
rocket
mq
and
client
group
I,
think
that
was
only
for
rocket
mq
yeah.
So
here
the
proposal
or
the
ask
basically
is
to
kind
of
make
those
make
those
generic
that
we
will
have
the
client
ID.
E
E
Don't
understand
anybody
from
you
have
like
ideas
or
opinions
on
this.
E
I
I
kind
of
I
mean,
from
my
point
of
view,
I
kind
of
agree
that
it's
a
bit
confusing
having
those
Concepts
like
a
consumer
group
and
client
group
spread
out
like
across
across
different
namespaces,
but
also
have
a
feeling
it
would.
Somebody
would
need
to
take
the
time
and
look
into
this
and
compare
to
the
Cross
systems
to
come
to
a
like
a
good
conclusion
here.
B
So
my
thought
on
this
is
that
from
the
perspective
of
the
user
or
the
the
customer
or
whatever
the
the
person-
that's
maybe
not
the
one
writing
the
instrumentation,
but
actually
looking
at
the
the
traces
have
having
something
named
in
a
way
that
doesn't
really
correlate
with
the
product
that
they're
used
to
using
so
like,
for
example,
if
you
use
Kafka,
you
probably
have
a
good
understanding
of
what
a
consumer
group
is.
B
So
if
we
try
to
enforce
a
different
naming
convention
just
to
make
it
consistent
across
different
messaging
systems,
that's
probably
going
to
create
additional
confusion
for
the
the
person
actually
using
or
looking
at
the
traces
foreign.
B
So
I
think
to
some
degree
it
makes
sense
to
utilize
the
names
that
the
the
platform
is
already
using.
E
Yes,
I
I
agree
too
and
I
mean
for
me
also
I,
think
the
for
for
me
here:
I'm,
actually
doubtful,
weather
and
I.
Think
that's
the
idea
here
that
basically
also
consumer
group
and
consumer
D
can
be
merged
into
a
client,
ID
and
a
client
group,
but
I.
Think,
like
a
consumer
group,
is
something
inherently
different
from
like
a
client,
ID
or
a
client
group.
E
So
I'm
kind
of
also
hesitant
from
that
angle,
without,
like
looking
into
it
too
deeply.
B
Rabbit
or
rocket
mq
I,
don't
know
what
a
a
consumer
or
sorry
a
client
group
does.
That's
what
I
mean.
E
Yes,
with
client
groups,
I'm
also
not
sure
I
mean
consumer
group
on
on
the
Kafka
side.
I
know
that
is
kind
of
the
that
is
more
or
less
like
a
a
container
or
an
identifier
where
you
basically
save
your
individual
checkpointing
information
right,
but
I
think
that
is
inherently
different
from
what
the
client
group
or
client
ID
is,
but
maybe
let's
I
mean
here.
Interestingly,
for
the
consumer
ID
in
like
the
the
generic
definition,
we
have.
E
A
I'm
sorry
I
was
something
didn't
work
for
me,
so
I
think
here
I,
just
the
reason
why
there
is
Kafka,
client,
ID
and
messaging
consumer
ID
I
just
overlooked
that
there
is
Kafka,
client,
deity
and
I
think
there.
There
is
a
big
inconsistency
here,
because
maybe
we
should
have
producer
ID,
but
my
reasoning
there
why
I
introduced
consumer
ID
and
didn't
introduce
producer
ID
was
that
it
seems.
A
Consumer
ID
is
interesting,
but
Kardashian
ID
is
just
like
the
the
instance
of
the
machine,
mostly
so
I
didn't
see
it
fast
in
current
conventions
that
if
anyone
except
Kafka
wanted
to
have
one
and
I
thought,
maybe
it's
less
important.
Maybe
consumer
ID
is
more
interesting
because
of
the
nature
of
the
message:
consumption
and
then
the
question
is
like
how
much
users
will
benefit
if
we
say
okay,
everyone
would
need
to
at
the
producer
ID
at
least
it's
it's
recommended.
How
much
value
would
it
bring.
E
So
the
let
me
talk
about
produce
when
consumer
ID
in
not
made
in
world
record,
would
that
be
different
from
like
having
a
generic
client
ID?
Is
it
just
the
fact
that
we
want
to
pack
the
consumer
group
into
this
ID
too.
E
A
E
Use,
but
that's
not
of
much
use
yes
and
what's
what's
the
inconsistency
that
you
mentioned,
that
you
see
in
regard?
Is
it?
Is
it
what
the
does
it
correspond
to
what
is
pointed
out
here
by
by
in
this
issue,
because
it
seems
the
inconsistency
that
is
seen
here
is
basically
that
there
are
the
two
concepts
of
consumer
group
and
ID
and
client
group
ID,
and
the
proposal
is
trustum
rotating
one
which
I
think
is
not
feasible.
A
Yeah
I
think
I
I
would
rather
keep
consumer
and
clients,
apart
than
use
the
terminology
and
messaging
systems,
and
it's
okay,
if
later
on
in
version
two,
or
can
we
decide
to
make
a
generic?
But
the
inconsistency
is
that
on
Kafka
we
have
both
client
ID
and
consumer
ID.
Yes,.
E
E
A
Why
would
entertain
the
idea
of
removing
Kafka
client
ID?
Okay,
like
what
is
what's
the
value
of
having
this
attribute.
E
A
I
see
okay,
then
I
would
like
to
maybe
look
into
the
blame
and
see
how
we
ended
up
there.
The
pull
requests
and
discussions
before
making
this
decision.
E
Okay,
so
for
this,
for
this
issue,
I
will
interest
either
comments
that
we
are
will
we
will
evaluate
that
further?
What
kind
of
clarification
or
like
optimizations
we
can
make
here.
E
So
it
seems
it's
not
just
like
Kafka
issue,
but
it
also
might
apply
to
Rocket
mq
because
also
for
rocket
and
Q.
Then
there's
a
car
in
the
deep
but
there's
also
This
Global
consumer
ID.
E
But
then
I
will
for
this,
for
this
issue
then,
like
I,
will
then
just
write
a
comment
that
yeah
that
we
will
need
to
look
into
that
and
and
and
and
figure
out
how
to
best
solve
the
inconsistent
inconsistencies
instead
of
making
here,
if
they
are
there
at
all.
E
You
see
I
would
also
need
to
think
about
this
more.
It
doesn't
seem
clear
enough
for
me
now
with
any
recommendation
Okay.
So
that
seems
to
be
that
issue
will
still
remain
and
we
look
further
into
that.
Then
this
here
I
think
that's
rather
smaller
issue.
That
asked
just
ask
for
an
additional
attribute
for
Kafka
for
cluster
ID.
Another
ID,
that's
interesting
to
the
adding
to
the
consumer.
Id
client
that
the
adding
a
cluster
ID
I,
think
that
is
for
environments
with
a
multiple
clusters:
I'm,
not
hundred
percent.
E
Sure
I
also
would
need
to
look
into
that
would
need
to
look
into
that
further
I'm,
not
100
sure
whether
that
is
producer,
consumer
related
or
whether
that
is
intermediary.
Instrumentation
related
the
the
problem
to
deal
with
like
Mark
Deeper.
E
Dusters
but
I
think
it's
probably.
It
might
be
the
case
that
with
maybe
with
a
host
name,
you
cannot
uniquely
identify
a
cluster,
but
you
need
this
additional
cluster
ID
to
kind
of
identifying.
A
E
A
E
E
But
I
can
I
can
add
a
comment
on
the
issue
here
and
ask
him
for
more.
E
For
more
information,
I
mean
it's
kind
of
low
cost
to
just
add
an
additional
Kafka,
specific
clusterity,
but
especially
related
to
the
discussion
with
before,
where
people
are
already
confused
by
consumer
ID,
client
ID.
Adding
a
cluster
ID
into
the
mix
for
some
people,
maybe
adds
more
confusion
than
it
adds
actual
value.
In
the
end.
E
E
E
Here
that
is
the
last
one
that
is
actually
corresponding
to
an
issue
and
that's
an
interesting
one
that
does
not
just
refer
to
to
messaging
alone,
but
that's
that
is
kind
of
of
getting
attributes
describing
the
content
length
or
the
payload
size
in
attributes
and
the
the
aim
of
this
issue
to
make
that
more
consistent
across
across
different
semantic
conventions.
Because
for
HTTP
we
have
request
content
length
for
to
your
PC,
it's
just
called
compressed
size
and
for
messaging
systems.
You
have
something
like
message:
payload,
size,
bytes
and
I.
E
Think
one
of
the
one
of
the
confusing
thing
here
is
that
actually
messaging
is
the
only
one
that
has
a
unit
attached,
whereas
here
there
is
no
unit
attached
and
also
must.
Basically
all
the
other
ones
have.
E
Oh
here
to
your
PC
has
compressed
uncompressed:
HTTP
only
has
uncompressed
and
messaging
only
has
compressed,
and
basically
there's
the
other
one
without
a
identifier
and
the
other
basic
audience
of
proposal
here,
for
basically
keeping
HTTP
as
it
is,
and
making
qrbc
and
messaging
consistent,
but
for
messaging
here
would
mean
just
having
payload
size
here,
leaving
the
unit
out
and
then
having
a
payload
size
uncompressed.
E
So
this
is
actually
basically
instead
of
compressed
here.
We
have
uncompressed
here
and
we
leave
the
bytes
out.
A
I
I
have
a
comment
on
this,
so
on
HTTP
we
no
longer
have
uncompressed
and
I've
done
some
research
there
and
I
I
was
the
one
to
remove
it,
because
it's
generally
impossible
and
instrumentation's
done
some
weird
stuff
too.
A
Sometimes
they
populate
a
Time
compressed.
Sometimes
they
populated
the
content
plans.
So
we
should
assume
that
it's
we
know
only
one
and
we
don't
know
if
it's
compressed
or
not
so
they
can
say
Okay
payload
size
makes
sense.
But
then,
if
we
populate
payload
size
and
angry,
we
should
remove
bites.
Yeah
I'm,
sorry
I
overlooked
it
in
my
PR,
but
we
actually.
If
we
are
dealing
with
batching,
we
would
also
have
badge
payload
size.
A
E
Let's
see,
basically,
we
could
have
this
payload
size
attribute,
then,
on
the
in
the
message
sub
namespace
to
put
a
message
specific,
but
it
can
also
exist
basically
like
in
the
global
messaging
namespace,
which
would
denote
like
that.
It's
referring
to
the
patch.
E
F
Like
I
think
we
did
if
it's
a
mass
batch,
then
you
feel
this.
Otherwise
you
feel
the
other
one.
F
A
F
E
Yeah
I
guess
it
can
be
useful
if
it
kind
of
can
be
easily
determined.
Because
then,
if
you
have
I
mean
if
the
size
looks
suspicious
on
the
batch,
then
you
can
look
up
say
what
kind
of
message
actually
contributes
most
to
the
seism
and
maybe
when
there's
something
going.
If
it's
a
naturally
large,
maybe
it's
just
a
single
message
that
causes
that
and
when
you
kind
of
lack
the
message,
specific
information.
E
So
we
seem
then
more
or
less
in
line
with
what
is
proposed
here
with
the
kind
of
addition
that
we
are
just
like
digital
uncompressed
attribute.
E
And
here
I
mean
that
is
not
just
related
to
messaging,
but
it
wouldn't
be
also
related
to
I
mean
HTTP
stays
as
it
is,
but
to
your
PC.
It
also
basically
change
to
your
PC
to
be
consistent
with
messaging
and
I.
Guess
that
is
maybe,
then
something
that
should
probably
be
also
discussed
in
the
general
semantic
convention.
Work
group,
or
maybe
we
could
also
just
come
up
with
a
I-
think
there
was
even
a
draft
PR
at
some.
E
Point
here
that
mostly
referred
to
like
not
changing
the
attributes
itself,
but
about
having
a
unit,
names
and
attributes.
E
Okay,
so
I
think
there
was
not
an
actual
PR
yet
that
that
did
actually
the
change
is
proposed
here.
Foreign.
F
E
That
is
because
Western
I
think
in
the
spirit
of
this
of
this
issue
here
I
think.
The
main
aim
is
that
it's
consistent
for
trpc
and
messaging.
So
from
that
view
I
would
say:
okay,
maybe
it
should
be
done
the
same.
Maybe
there's
this
question
from
tropc
Forks
that
they
say:
okay,
no,
that
does
not
work
for
us.
We
need
yeah,
it's
not
here.
We
need
something
else,
but
yeah.
F
Yeah,
it's
better
old
as
well,
so
the
Demi
said
I
think
the
HTTP
ones
are
already
different.
So
maybe
you
can
just
comment
and
see
what
the
internet
still
is
and
now
then
we
can
follow
up
from
from
there.
Yes,
because
from
our
side
it
will
be
pretty
easy
to
send
a
PR
to
to
to
change
hours,
to
remove
the
sun,
compressed
and
units,
and
so
on.
E
Because
I
will
update
the
info
here
that
for
messaging
point
of
view,
we
don't
need
uncompressed
and
we
would
be
fine
by
just
having
this
messaging.payload
size.
Basically,
both
in
like
a
badge
and
in
a
message.
Namespace
and
I
will
then
also
put
out
the
question
whether
that
asking
whether
there's
any
like
qpc
expert
who
can
comment
better
whether
this
what
is
proposed
here
is
acceptable
for
to
your
PC
and
then,
let's
see
who
what
responses
we
get
and
then
maybe
we
can
move
forward
with
that.
E
Okay,
sound
looks
good,
so
those
are
basically
the
three
issues
so
for
this
I
will
put
here
we'll
ask
for
gamification
whether
that's
information
in
clusterity
that
we
not
get
via
hostname
in
terms
of
identifying
a
cluster
identity.
E
Here,
we'll
ask
whether
I
need
your
PC
expert
can
comment
on
this
and
hear
about
this
I
think
we
will.
We
will
need
to
look
into
it
and
think
more
about
how
to
make
that
consistent,
and
then
there
is
the
last
Point
here
that
is
I
mean
I.
Think
we
don't
need
to
really
talk
about
the
specific
messaging
system,
attributes
that
we
are
anyway
doing
mostly
here.
That
is
just
kind
of
this.
This
issue
here
is
just
for
us.
E
And
I
think
this
is
related
to
the
messaging
kind,
where
we
currently
have
or
the
destination
or
Source
kind,
where
we
currently
have
q
and
topic,
and
we
don't
allow
anything
else,
the
only
values
allowed
or
q
and
topic.
And
here
the
question
basically
is
two.
E
Maybe
allow
others
instead
of
Q
and
topic,
like
one
request.
Here's
address,
for
example,
when
you,
maybe
you
don't
know
whether
it's
a
queue
or
topic,
and
then
you
can
use
address,
that's
an
mqp
term,
let's
referred
to
as
that
here
and
yeah.
I
think.
The
effect
here
would
be
that
we
don't
make
this
like
restricted
to
the
two
types,
q
and
topic,
but
yeah
customers
can
also
use
custom
values
to
describe
what
is
the
kind
of
the
source
and
the
destination.
E
And
from
my
point
of
view,
I
don't
see
any
like
strong
reason
for
us
to
be
strict
here
and
say:
okay,
it
must
I
Ruby
queue
or
topic,
and
you
must
not
put
anything
else
in
there.
I
can
see
situations
where,
where,
where
you
want
to
have
like
an
other
identifier
there,
so
from
my
point
of
view,
I
don't
see
any
benefit
from
being
strict
there,
but
wondering
about
other
other
opinions.
A
Yeah,
so
if
we
forget
about
the
address
per
second,
so
on
mqp
site
topic
work,
you
are
not
mqp
terminology
and
like,
for
example,
Azure
mqp
messaging
systems,
I,
don't
actually
it's
a
keyword.
Topic
is
a
consumer
concern,
an
API
concern,
but
they
can
say:
okay,
I'm,
sending
to
q
and
Center
topic
and
other
way
around.
A
So
on
the
producer
side,
it
doesn't
even
matter
so
I
agree
that
sticking
to
Q
and
topic
and
not
allowing
something
else,
Maybe
it's
limiting
in
some
sense,
and
we
should
probably
allow
more
than
that
at
the
same
time,
I
looked
into
if
there
is
other
terminology
and
pure
on
topic
or
just
like
everything
you
read
about
messaging,
is
focused
around
those
two.
So
I
think
what
we
have
now
is
probably
good
enough,
but
it
also
doesn't
hurt
to
be
less
restrictive.
E
That
is
the
trim
as
topology,
where
you
either
have
q,
or
you
have
topic
and
I
mean.
That
was
something
that
we
think
discussed
in
the
very
beginning
where
we
say:
okay,
yeah,
it's
basically
just
those
two
more
or
less
different,
like
checkpointing
approaches
or
the
two
like
settlement
approaches
that
you
have
where,
with
the
Q
basically
means
you
have
like
a
a
per
message
settlement,
the
rest
with
the
topic.
You
have
kind
of
a
checkpoint
based
settlement.
E
So
it's
kind
of
this
basically
different
settlement
approaches
are
kind
of
hidden
behind
this
cue
and
topic
terminology
and
I.
Think
from
that
point
of
view,
yeah
there's
only
two
I,
don't
know
of
any
other
settlement
approach.
Besides
the
checkpoint-based
approach
and
the
and
the
message
specific
approach
for
you
basically
settle
each
message
individually,
I
think
there
is
no
other
approach.
Therefore,
so
from
that
point
of
view
it
seems
to
make
sense
to
just
have
two
values,
but
I
also.
E
See
that
just
having
q
and
topic
here
as
kind
is
kind
of
in
some
context,
maybe
when
you,
when
you
have
different
terminology,
might
not
make
sense
so
yeah
from
that
point
of
view,
I'm
a
bit
kind
of
porn
actually,
because
when
you
see
it
as
kind
of
describing
which
settlement
approach
is
used,
I
think
the
that
that
there
is
only
two
kind
of
makes
sense,
but
the
yeah,
on
the
other
hand,
maybe
with
this
kind
that
can
also
be
like
different.
E
Even
even
when
we
have
this
as
description
of
the
settlement
approach
in
mind,
I
mean
we
could
have
additional
terms
that
describe
it
like
more
in
detail.
Winter
might
be
different,
like
message
specific
settlement
approaches,
so
all
in
all
I
think
for
me.
It's
fine
to
kind
of
allow
other
values
here.
Besides
q
and
topic.
G
Yeah
my
thoughts
on
this
sort
of
that,
like
the
systems
I'm
familiar
with,
like
we'll
just
kind
of
JMS
and
and
Solace
that
q
and
topic,
you
know
sort
of
imply
some
behavior
in
terms
of
the
system
and
it
doesn't
really
impact
settlement
per
se
but
like
if
you're
going
publishing
to
a
queue.
G
That's
that's
that's
happening,
and
it's
just
it's
potentially
interesting
I
think
if
amqp
isn't
as
much
of
a
messaging
system,
it's
just
a
protocol
for
how
to
get
things
from
A
to
B
and
and
it
doesn't
prescribe
any
semantics
for
how
what
what
the
receiver
does
based
on
the
address
and
that's,
and
so
my
thinking
is
that
an
amtp
Trace,
probably
just
this,
just-
isn't
interesting
right
like
you,
so
whether
you'd
bother
to
put
a
like
if
this
was
just
optional.
G
My
thinking
is
in
amtrps,
wouldn't
bother
to
put
a
kind
in
here
at
all,
but
if
someone
wanted
to
put
it
put
something
in
there,
if
they
want
to
put
another
value
like
address
I'm,
not
against
letting
people
put
whatever,
they
want
to
try
to
describe
destination
kinds
or
Source
like
yeah,
so
I
I,
just
don't
know
if
it's
interesting,
but
at
the
same
time
I
don't
think
we
need
to
restrict
it
to
just
q
and
topic.
E
Yes,
that's
also,
that's
also,
that's
also
my
opinion
here.
So
basically,
I
agree
that
q
and
topic
can
give
you
like
some
can
give
you
some
interesting
information
and,
if
I,
if
I
understood
your
right
to
end,
it's
basically
that
you
that
you,
that
you
know,
okay,
when
I
send
to
a
queue
there
is
like
just
your
own
consumer
and
when
I
send
to
a
topic
to
my
text,
repeal
of
multiple
consumers
on
the
other
way.
E
So
in
that
regard
yeah
it
gives
you
some
useful
information,
but
I
I,
don't
see
it
like
any
value
into
us
just
forcefully.
Restricting
these
two
two
values.
E
So
yeah,
maybe
we
can,
if
there
is
not
nobody
speaking
against
this,
we
can
loosen
loosen
this
up
and
allow
additional
values
here.
C
C
But
it
felt
really
strange
to
why
the
the
name
topic
there,
because
they
don't
use
this
term
terminology
so
like
we,
your
Force,
like
I,
was
forced
to
write
topic,
even
though
it's
not
related
I
wanted
to
write
like
home
in
the
because
this
is
the
terms
that
people
that
use
socket,
IO
use
so
yeah.
Just.
E
That
makes
sense
here,
basically,
that's
something
we
would
make
possible,
then
that
you
can
use
them
the
specific
like
terms
like
room
or
certain
systems.
Okay,
so
we
are
through
those
four
here.
One
question:
I,
don't
want
to
put
out
there
that
yeah
there
are
now
I
mean
here
we
already
agreed.
Okay,
there
is
like
a
change
we
want
to
do
for
for
this.
Regarding
the
attributes
also,
here
for
this
payload,
we
agreed
I,
don't
messaging
size.
It
was
really
strange.
E
We
just
need
to
clarify
whether
it's
a
a
consistent
change
can
be
made
for
grpc2
and
also
here
there
is
potentially
changes
to
clean
up
some
ambiguity,
and
here
we
need
to
clarify
this.
The
question
main
question
I
have
now:
should
we
try
to
do
all
these
changes
at
once
at
some
point,
once
we
figure
them
out
or
should
we
should?
Are
we
fine
having
like
smaller
individual
PR's,
doing
like
those
Point
changes,
Q.
F
F
E
That
sounds
good,
then.
So
in
that
regard,
basically,
when
we
have
like
say
we
have
different
PRS
here's
anybody
interested
in
taking
on
any
of
those.
E
E
F
It
off
I
can
also
follow
the
cluster
ID,
but
yeah
I
can
just
follow
the
ticket
and
then
once
there
is
some
some
discussion.
I
can
also
send
API
in.
E
Okay
sounds
good,
so
for
those
first,
two
I
will
start
off
asking
for
clarification
and
adding
comments,
and
then
we
see
who
actually
does
the
pr
isoner.
You
are
going
to
look
into
those
two.
Thank
you.
Then.
We
have
like
30
minutes,
left
and
I.
Think
as
we
are
talking
about
attributes,
maybe
Lut
Miller.
You
want
to
talk
about
your
proposal.
E
A
Okay,
cool
yeah,
so
I
made
some
research
around
settlement
and
I
tried
to
find
some
common
terminology
and
what
would
be
a
good
set
of
attributes
and
the
short
conclusion
is:
there
is
very
little
consistency
and,
most
importantly,
we're
really
the
consistency
in
terms
of
what
is
settled.
A
So
let
me
show
you,
the
I
think
some
examples
of
what
different
systems
do
and
based
on
this
I'll
explain
my
proposal.
So
Johannes
do
you
prefer
to
scroll
for
me
or
do
you
want
me
to
share.
D
A
E
A
Okay,
so
in
Kafka
yeah
there
is
settlement,
it's
Kafka,
it's
called
commit
and
there
are
different
modes.
There
are.
The
auto
mode
is
actually
done
on
periodic
intervals.
It's
not
done
in
scope
of
individual
messages
and
then
there
is
synchronous
in
asynchronous
versions,
which
are
probably
not
that
interesting
for
the
instrumentation
side.
So
Kafka
commits
offsets
right,
so
we
probably
and
they
are
specific
to
partition.
A
So
those
are
not
related
to
settlement
per
se,
but
they
are
important
to
know,
but
we
should
already
have
them
on
attributes
anyway,
so
Kafka
commits
offset.
Then
I
was
also
thinking.
What
could
be
the
parent
and
links
for
this
thing?
So
if
it's
an
in
author
mode,
then
there
is
it's
an
empty,
probably
no
parent.
It's
some
backgrounds
read
that
commits
and
who
you
would
only
know
the
offset
so
I'm,
not
even
sure
it's.
A
It
makes
sense
to
create
this
pen,
it's
more
like
a
metric
or
an
event
or
something
than
for
explicit
manual
commit.
Then
the
parent
would
be
either
delivery
scan
if
we
have
one
or
a
manual
processing
span
like
it's
an
ambient
context
that
we
don't
guarantee.
That
is
there
right,
especially
for
Kafka
and
for
links
like
we
probably
don't
won't
have
them
so
there
could
be
like.
A
Sometimes
we
might
be
able
to
know,
but
it's
up
to
the
instrumentation
and
instrumentation
library
and
instrumental
library
to
have
this
information
because
from
API
standpoint
you
think
you
commit
not
sure
if
you
commit
a
message.
Probably
you
come
you
you
commit
the
last
offset,
but
anyway,
so
we
can
say
that
if
links
are,
if
cut,
if
subtle
messages
are
known,
you
can
populate
them
on
links
right,
but
it's
no
guaranteed
and
yeah.
A
G
Sorry
we
merely
this
question
on
Cafe,
like
so
you're
describing
consumer
settlementist
effectively
is.
Is
there
also
producer
settlement
as
well?
Are
we
just?
Are
we
restricted
in
scope,
consumers
at
this
point.
A
Yeah
I
didn't
look
into
producer.
Someone
I
think
here
we're
talking
about
consumer
settlement
produce
Your
settlement.
Where
exists,
my
understanding,
it
is
mostly
like
a
TCP
Arc
or
something
like
this
so
like.
Basically,
if
we
know
like
it's
like
right,
when
you
write
this
call
in
your
code,
you
wait
for
a
response
or
you
don't
wait
for
a
response
right,
but
the
span
created
tracks
the
the
time
it
takes
to
perform
the
job.
It
might
even
know
whether
it
was
like
finished
correctly.
A
Even
if
user
didn't
care
so
I'm
wondering
when
we
talk
about
producers
at
women,
do
we
want
to
spag
it
out?
Does
it
make
any
sense.
G
Well,
I
think
so
because,
like
a
lot
of
messaging
systems
have
asynchronous
acknowledgment
of
produced
messages
and
I
think
you
would
probably
want
to
know,
like
I,
think
that's
valuable
from
information
to
know
when
the
producer
kind
of
learns
that
his
message
has
been
accepted
by
the
system.
Yeah.
G
So
JMS
1.1,
that
is
the
case,
JMS
2.0.
They
have
asynchronous
delivery
where
you
get
a
call
back
for
the
message
after
your
send
call,
which
allows
for
much
higher
like
allows
for
kind
of
pipeline
messaging
is
kind
of
one
of
the
big
weaknesses
of
JMS
1.1
that
you
know,
performance
is
usually
very
bad,
and
and
people
do
weird
things
to
get
better
performance
like
use
transactions,
but
JMS,
2.0
and
other
messaging
systems.
It's
it's
ampp,
for
example,
and
Solace.
A
And
right
and
what
I'm
saying
that?
Maybe
the
answer
to
this
is
not
to
instrument
settlement
in
some
sense
but
say
that,
regardless
of
the
mechanism,
how
responses
received
by
user
right,
the
instrumentation
library
or
instrumented
Library
should
end
the
span
once
this
callback
is
called
in
case
of
asynchronous
settlement,
so
that
the
span
duration
of
producer
call
matches
the
time
from
start
callback
to
the
end
callback
and
matches
the
outcome
of
the
broker
response.
G
G
I,
don't
want
to
derail
this
with
producer,
but
I
think
there
are
some
discussions
that
could
be
had
on
the
Priestess
side,
because
I
I
think
what
you're
proposing
might
you
know
might
be
a
good
approach,
but
at
the
same
time
you
have
to
kind
of
look
at
some
scenarios
like
what,
if
your
connection
to
the
broker
drops
before
you
get
an
acknowledgment,
what
happens
should
any
additional
spans
be
created
at
that
point,
and
so
I
think
there's
a
lot
to
think
about
there.
So
I,
I,
I,
I'd,
say
I.
G
A
Yeah
it
does,
but
let's
spend
a
few
more
minutes
on
this,
because
I
think
it's
important
to
say
that
to
limit
settlement.
So
when
we
talk
about
HTTP,
we
never
talk
about
how
https
done
an
API
level.
So
when
you
call
begin
request
and
then
wait
for
a
callback
to
receive
a
response,
we
never
specify
it
in
this
pack,
because
we
kind
of
imply
that
you
want
to
know
the
duration
of
the
HTTP
called.
A
If
your
connection
is
interrupted,
you've
got
an
exception
and
this
corresponding
span
to
make
HTTP
request
answers,
error
status
and
some
information
about
exception.
Right
and
essentially
this
is
the
low
level
protocol
information.
How
like
it's?
It's
done.
It
doesn't
matter.
Essentially
you
get
an
act
of
some
sort,
and
this
is
where
the
span
ends
and
I'm
not
sure
why
messaging
is
special
in
this
case.
Why
do
we
want
to
like?
Yes,
we
can
get
a
response
from
messaging
system,
saying:
okay,
the
producer
settlement
is
not
done.
A
The
message
is
rejected
right,
but
it's
the
same
in
any
other
semantic
convention.
We
have.
E
I
I
think
here
we
again
have
these
two
layers
that
we
talked
about
some
time
ago,
where
we
have
more
or
less
like
the
application
layer
and
the
transport
layer
and
a
single
application
layer.
Anything
with
what
Mill
is
talking
here
about
you.
Basically,
when
you
do
this
sync
async
settlement,
there's
an
operation
that
the
user
triggers
and
then
he
gets
some
kind
of
response,
whether
it's
like
successful
or
unsuccessful,
or
any
other
state,
and
whether
there
were
like
retries
during
this
operation
or
what
exact
happened
on
the
protocol
level.
E
I
think
it's
not
really
relevant
on
this
layer,
but
it's
different
when
you're
going
down
to
the
transport
layer
which
they
might
have
like
if
it
if
it's
instrumented
you
get
like
detailed
amqp
information
for
each
card
that
was
made
and
for
each
retry
that
was
made
on
this
level
and
what
exact
like
failed,
State
you
got
for
before
each
retry
and
I
think
it
makes
sense.
Also
in
this
regard,
to
keep
those
mentally
apart
and
say.
Okay,
here
for
what
we
propose
here,
we
are
still
like
on
the
application.
D
E
And
the
transport
layer,
basically,
that
is
a
level
deeper
that
we
Maybe
Might
tackle
in
the
future
or
that
other
groups
might
take
you
where
you
then
have
like
a
protocol
specific
spans,
like
mqp
spans.
G
Okay,
that
makes
sense
now
I
I
personally,
like
the
proposal
of
starting
a
span
when
you
send
it
and
getting
and
ending
it.
When
you
get
the
acknowledgment
there
was
some
talk.
G
This
goes
back
probably
a
couple
months:
I,
don't
remember
exactly
how
long
about
for
async
that
we'd
have
separate
spans
for
the
send
and
the
acknowledgment
but
I
I
kind
of
think
you
want
to
measure
the
duration
of
the
the
whole
operation
I
think,
makes
more
sense
whether
you're
kind
of
getting
zero
duration
spans,
but
I
think
the
argument
for
doing
separate
spans
was
more.
It's
reflecting
what
the
application
sees
better.
G
A
F
D
A
So,
let's
drop
off
I
think
we
will
spend
more
time
on
settlement
later
on.
But
if
you
have
a
chance,
please
go
through
this.
There
is
a
link
in
the
agenda
and
let
me
know
if
you
have
any
thoughts
on
the
feedback,
so
we
will
be
more
prepared
in
future.
Thank
you.