►
From YouTube: 2022-05-11 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
C
E
D
Yeah
I
kisha
did
ask
me
about
that.
Oh
it
was
maybe
a
week
ago,
so
I
I
re-reviewed
it
and
added
some
more
more
comments.
E
C
E
Kernel
listener
example:
the
otl
instrumentation
bundle
and
teemo's
refactor
of
the
sdk
bundle.
So
I
think
that
right,
you
are
reviewing
the
refactor.
The
sdk
bundle.
Do
you
have?
Is
there
anything
else
that
you
wanted
to
talk
about
with
that.
D
Looks
like
I
was
pretty
happy
with
it
last
time
and
I
don't
have
anything
to
add,
but
I
don't
know
if
uniftimo
sort
of
sort
of
addressed
a
couple
of
small
things
I
did
mention.
E
C
Okay
and
then.
E
C
A
E
D
E
D
It's
very
mysterious
there's
a
lot
going
on
in
there
and
it
really
jumps
around
a
lot.
So
yeah.
E
Yeah
I
originally
implemented
that
with
a
co-worker
michael
orr,
and
we
were
we.
D
D
Okay
sounds
good
on
slack,
but
yes,
anyway,
so
the
the
the
concept
is
that
you
know
that
we,
I
think
we
need
to
expose
storage
so
that
you
know
concurrent
processors
can
can
have
their
own
storage,
so
they're
not
scribbling
on
each
other's
or
clobbering
each
other's
sort
of
context,
and
I
that's
the
that's
the
only
way
that
I
can
think
of
to
to
get
it
to
work.
D
I'm
a
little
concerned
that
we
might
get
memory
leaks
or
something,
and
I
I've
submitted
a
a
benchmark
test
as
well,
which
just
shows
that
it
does
use
a
lot
of
memory.
But
I
don't
know
if
it's
an
excessive
amount
of
memory,
yeah
well
yeah
I'll
play
with
that.
You
know
before
we
before
we
go
on
before
anything
gets
committed.
E
E
Excuse
me,
sorry,
I'm
getting
some
500
from
github
this
morning,
so
I'm
trying
to
follow
around,
but
I
think
that's
so
that
was
that.
Is
there
I
think,
there's
something
in
the
chat.
E
Thank
you.
You
want
to
discuss
issue
328.
B
Yeah,
actually,
this
is
regarding
the
implementing
rate
rise
in
grpc
exporter.
B
So
so,
if
you
remember
right
view,
I
was
trying
to
you
know
just
see
if
the
grpc
exporter
hotel,
pgrt
export
is
working
fine
or
not.
So
basically,
this
was
related
to
this
issue.
B
So
I
I
looked
into
the
implementation
of
other
hotel
signals
like
in
go
or
in
java
in
dotnet,
but
they
have
a
very
partial
implementation
done
for
the
retries
in
grpc
export,
and
I
try
to
look
into
the
same
where,
basically,
what
they
do
is
they
try
to
create
a
retry
policy
and
pass
on
the
retry
policy
in
the
grpc
configuration
itself
when
they
are
creating
the
client,
but
I
tried
to
look
into
the.
I
tried
to
look
up.
B
The
same
kind
of
you
know:
functionality
in
jrpc,
php,
more
library,
but
I
couldn't
find
it.
So
I'm
not
sure.
B
B
E
The
interesting
thing
is,
I
know
that
there
are
grpc
configurations
that
allow
you
to
do
retries
and
I
think
it's
very
language
dependent.
So
perhaps
we
should
do
some
research
on
on
php's
grpc
implementation,
see
if
it
does
retries
automatically.
D
I'd
be
wary
about
trying
to
build
retries
into
into
such
a
system
if
it
doesn't
support
them,
and
we
have
spoken
about,
maybe
not
for
grpc,
but
but
more
generally
about
retries
and
and
it's
worth
noting
that
the
hotel
collector
does
retries.
D
So
you
know
if
we
can
have
confidence
that
we
can
that
that
you
know
it
should
always
be
up.
C
E
There's
like
a
small
separation
of
concern
there,
because
you
know
the
client
retry
and
the
sir
and
the
collector
you
try
our
two
separate
they're
two
separate
things:
they.
D
E
Yeah
yeah,
so
I
I
understand
thank
you
or
you're.
Talking
about
with
wanting
to
implement,
like
that's
part
of
the
issue,
is
trying
to
figure
out
how
to
implement
retries
from
the
client
side,
and
I
posted
a
link
in
the
in
the
zoom
chat
about
grpc
connection
back
off
protocol.
There's
there
is
a
backup
algorithm
that
looks
like
it's
been
proposed.
I
don't
think
that
it's
quite
been
implemented.
Yet
I
think
1.45.0
is
the
most
recent
version
of
grpc
php.
E
By
the
way,
this
is
the
worst
website,
probably
ever,
but
I
think
that
yeah
I
agree
with
trying
to
implement
this
ourselves
might
be
full.
Not
I
don't
want
to
say
foolish,
but
it
might
be
difficult.
B
So
normally
other
languages
implement,
like
they
just
create
the
policy
based
on
this
parameters
and
pass
the
policy
to
the
grpc
package.
So
jrpg
package
itself
handles
the
rate
rise
based
on
this.
D
B
The
in
php,
I
didn't
find
you
know
any,
not
another
single
example
or
api
I'd,
look
to
the
documentation,
php
grpc,
but
apart
from
this
algorithm,
so
I
I
already
gone
through
this
algorithm
yesterday
or
day
before.
But
there
is
no
such
thing
like.
We
can
create
the
policy
and
pass
it
to
the
jrbc
package.
E
It
looks
like
I
just
I
found
an
I
found
a
grpc
issue
that
I
just
posted
in
the
zoom
chat.
It
looks
like
that
gives
a
pretty
good
example
of
attempting
to
do
a
re
retry
with
grpc,
and
it
looks
like
some
code
was
merged
in
in
on
september
1st
of
last
of
last
year
that
fixed
the
some
of
those
seg
faults
that
were
happening
when
retries
were
when
recharger
going
on.
E
So
that
might
be.
That
might
be
a
really
good.
That
issue
that
I
just
think
might
be
might
be
a
really
good
template
for
you
to
use
to
try
it.
E
Sure,
I
think
that's
that's
all
we
had
on
the
agenda.
Did
anybody
else
want
to
bring
anything
up.
B
328
is
related
specifically
to
grpc,
but
I
I
see
that
we
have
this
otlp
http
as
well
right,
so
do
we
have
to
implement
the
retry
mechanism
in
all
the
exporters,
because
I
can
see
in
the
from
the
discussion
that
some
people
want
to
be.
You
know
implement
that
generic,
not
in
a
very
specific
experience.
E
Yeah,
I
think
that
my
I
feel
like
that
should
be
a
function
of
the
core
library
and
not
the
exporters,
the
retry
part,
because
the
exporter
should
use
the
like
the
core
api
sdk
to
make
the
request
to
what
to
the
exporter
and
the
grpc
layer
is
independent
of
the
exporter.
So
I
would
I
would
you
know,
attempt
to
do
that
with
so
that
we
don't
have
to
replicate
that
logic
across
all
of
the
different
exporters.
E
Oh
okay,
sure!
So
let
me
let
me
try
and
say
a
little
more
concisely
too.
The
exporters
and
the
quora
api
and
sdk
should
be
independent
of
one
another,
and
I
feel
as
if
this,
the
retry
logic
for
both
for
jrpc
should
be
done
in
the
sdk
and
the
api,
so
that
the
exporters
can
use
it
and
that
we
don't
have
to
repeat
logic
over
and
over
again.
C
E
D
D
B
Right
but
one
question
that
so
you
said
that
we
we
should
be.
We
should
implement
the
retry
mechanism
in
the
sdk.
The
thing
is
the
example
that
you
shared
right
that
is
specific
to
grpc,
only
that
we
provide
the
retired
policy
as
part
of
the
grpc
client,
so
how
that
can
be
how
we
can
make
it
generic
for
http.
D
B
B
Sorry
well.
D
If
it
was,
if
it
was
to
be
generic,
then
you
wouldn't
do
it
in
that
grpc
client
you'd
have
to
I
don't
know,
we
would
have
to
invent
something
with
a
queue
or
you
know,
a
storage
for
unsent
messages,
and
you
know
a
way
to
retry
it
and,
and
even
then
it
would
have
to
be.
I
would
think
some
sort
of
storage-
that's
because
php
is
often
shared
nothing
and
completes
as
soon
as
the
request
is
done.
D
So
it
can't
it
can't
wait
around
for
a
connection
to
open
up
and
be
sent
in
the
future.
So
it's
it
sounds
like
a
fairly
big
and
complicated
problem
to
do
properly.
B
So
maybe
I
mean
the
the
generic
approach
could
be
like
that:
let's
send,
let's
export
it
and
based
on
the
status
we
can
have
a
you
know.
We
can
have
the
retry
policy,
not
as
part
of
the
exporter
mechanism,
but
in
an
sdk
where
it
will,
you
know,
tries
based
on
the
status.
D
D
But
just
going
back
to
what
I
was
saying
before
you
know,
we'd
have
to
retry
very
very
quickly,
most
of
the
time
or
maybe
as
part
of
exporter
shutdown
is
try
and
do
a
final
flush
of
anything
that
you
were
holding
on
to
that
you
hadn't
seen
just
in
case
it's
you
know
a
little
bit
of
time
has
elapsed
and,
and
you
could
could
send
it
that
that
might
be
a
way
to
do
it,
but
in
terms
of
you
know,
holding
on
to
it
for
a
long
time
you
know
like
minutes
or
something
until
you
know
a
network
comes
back
up.
F
D
May
he's
very,
very
good,
but
that's
that's
I
yeah
I.
I
don't
see
that
yeah.
E
Yeah,
I
think
I
think
that
this
one's
definitely,
I
think
that
we
could.
I
think
that
we
could
follow
like
the
following.
That
example
would
probably
be
sufficient
enough,
and
if
you
get
stuck
on
that,
we
can
always
punt
on
this
too,
because
I
don't
think
that
this
is.
It
says
that
this
is
required
for
ga,
but
I'm
not
certain
that
it
is.
E
D
D
E
B
B
But
I
let
me
see
if
it
was
must
or
you
can.
I
thought
it
mentioned
in
this
fact
that
you
can
implement
the
retries
with
a
jitter
retry
back
off
mechanism
with
the
jitter.
So.
B
The
retry
back
of
exponential
backup
with
jitter
that
was,
must,
if
you
are
implementing
the
retry
mechanism,
but
you
must
implement.
D
Yeah
yep,
I
mean
it
sounds
like
what
you
just
said
was:
if
you,
you
may
implement
retries,
and
if
you
do,
you
must
do
it
in
this
way,
yeah,
which
means
re
to
be
ritualized
and
not
required.
But
if
they
are
then
that's
the
way
they
should
be
done.
F
B
So
can
you
guys
see
my
screen?
Yes
yeah,
so
this
is
the
exporter
specification
right
and
here
it
says
that
the
transit
error
must
be
handled
with
a
return
strategy.
B
Data
strategy
must
implement
the
exponential
backup
with
cheater,
so
both
of
the
things
are
must
be
implemented,
maybe
to
go
to
ga.
That's
why
yeah.
D
B
Can
we
divide
this
issue?
You
know,
you
know
multiple
tickets
right
for
each
exporter.
We
can
implement
the
return
mechanism.
Let's
let
me
go
complete
this
grpc
first
and
maybe
we
can
in
the
next
step.
We
can
make
it
more
generic
to
see
if
it
is
working.
Fine,
is
it
possible
or
do
you
guys
want
to
be-
wants
the
return
mechanism
to
be
implemented
in
general
from
the
first
steps.
D
I'm
not
sure
what
I
think
I
I
I
think
what
bob
said
earlier
is
probably
sensible
in
that
it
should
be
done
once
in
in
the
sdk.
D
F
D
I
think
so,
which
is
responsible
for
exporting
and
then
gets
back.
The
response
of
the
export
failed
retriable
if
it
failed
retryable,
then
stash
it
somewhere
and
and
retry
again
and
and
that
would
be
the
spot
to
implement
the
the
mechanism
of
you
know.
Jitter
back
off
and
whatever
else
the
spec
says
there.
D
And
that
would
be
the
generic
way,
that's
reusable,
and
then
it
wouldn't
matter
what
the
exporter
is,
because
we
have
at
least
six
of
them.
I
think
there's
and
potentially
more
in
the
future.
So
so,
if
we
can,
if
we
can
do
it
once
in
the
sdk,
then
it
will
work.
D
You
know
henceforth
for
any
exporter.
D
So
if
you
wanted
to
try
that
you
yeah
I'm
imagining
we
have,
you
know,
maybe
we
add
some
storage
to
the
the
span
processor
for
failed,
your
retriable
failures
or
you
know
whatever
you
want
to
call
it.
So
when
something
fails
put
in
this
queue
and
then.