►
From YouTube: 2023-03-30 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
B
Ask
it's
don
hey.
C
A
B
C
G
B
B
Or
we
can
chat
about
this
I
was
looking
at
so
this
we
had.
We
discussed
this
I
think
previously
of
since
we
have
runtime
Telemetry,
GFR
and
runtime
telemetry
jmx
I
was
wondering
about
merging
those
into
a
single
module.
B
B
They
don't
really
see
jmx
or
JFR
I,
don't
think,
and
then
the
other
kind
of
what
part
of
it
felt
a
little
awkward
to
me
was
like.
What's
this
versus
jmx
metrics,
which
really
is
from
a
user
perspective
about
jmx
metrics.
B
So
I
think
I
think
we
had
discussed
it
briefly
previously
and
decided
to
have
them
split,
but
just
wanted
to
revisit
that.
I
think.
C
G
D
B
And
I
would
kind
of
be
painful
to
do
do
we
even
had
support
Mr
jars
in
instrumentation.
C
C
Yeah
so
like
we
probably
have
to
have
two
separate
modules
for
these,
but
we
maybe
could
use
the
same
property
like
the
same
instrumentation
level
is
so
instead
of
having
them
both
use.
A
separate
estimation,
name
I,
think
they
use
like
runtime,
metrics,
jmx
and
multimax
QX
JFR.
We.
E
Well,
sort
of
they
can
each
do
things
that
the
other
can't.
E
B
So,
with
the
the
okay
yeah,
I
mean
that
that
kind
of
makes
sense
to
me
from
the
perspective
of
this
is
only
use
it
like.
This
is
only
usable
on
17
plus.
D
B
Sorry
but
I
didn't
think
I
didn't
hear
one
thing
you
said:
I
just
wanted
to
make
sure
I
got
it.
You
were
just
saying
it's
kind
of
similar
to
how
we
do
the
regular
splits.
C
It
already
is
like
the
Java,
eight
and
Java
17
names
are
somewhat
similar
and
using
the
Java,
prefix
I
think
it
makes
things
a
little
more
clear
in
this
particular
case.
B
B
Okay,
I
I
might
throw
this
into
a
comment
on
that
issue
and
see
what
Robert
and
others
think.
B
Jack
I
threw
this
on
here.
Why?
Oh
yeah
I
was
kind
of
curious
to
get
the
broader
groups,
thoughts
on
the
jdk
HTTP
client
performance.
If
anybody
else
has
had
similar
experience
or
tried
to
Benchmark.
E
Yeah,
let
me
give
a
quick
summary,
so
this
is
actually
occupied.
Like
most
of
my
last
week,
I
I
don't
know
so
what
I've
been
trying
to
do
is
have
an
implementation
of
the
otlp
HTTP
exporters
that
uses
the
jdk
11
HTTP
client.
Instead
of
you,
know,
okay
HTTP,
because
that's
a
problematic
dependency,
because
if
it's
transitive
dependency
on
kotlin-
and
you
know,
I
I've
been
exploring
how
we
could
package
that
up
with
a
a
multi,
a
multi-version
jar.
E
So
we
have
a
Java
11
version
and
a
Java
8
version
that
seemed
to
work
and
I
was
surprised
when
I
went
to
Benchmark
this
and
the
performance
of
the
jdk
HTTP
client
was
significantly
worse
than
okay,
HTTP
or
Neti,
and
you
know
that
was
surprising
to
me
and
I've
been
spending
a
lot
of
time.
E
You
know
getting
familiar
with
the
API
and
in
the
internals
and
trying
to
figure
out
exactly
why
that
is,
and
if
there
was
any
user
error
involved
and
if
the
benchmarks
were
giving
an
inaccurate
picture
of
what's
have
been
happening,
and
so
it's
still
kind
of
actively
evolving.
But
this
PR
here
shows
kind
of
the
the
the
the
the
the
main
issue
here.
So
if
you
look
at
the
allocation
rate,
normalized
of
the
jdk
HTTP
exporter
so
actually
go
to
the
512
row
right
down
there.
E
So
each
time
you
know
an
export
happens
with
512
spans
220
000
bytes
are
allocated
and
for
the
other
exporters
you
know
the
grpc
based
ones
and
the
okay
HTTP
based
ones,
they're
all
around
20
000
bytes
versus
two
hundred
thousand.
So
it's
like
a
10x
difference
and
that's
not
good
enough.
I,
don't
think.
B
E
Yeah,
so
that's
a
function
of
payload
size.
So
what's
interesting
is
that
the
other
exporters,
the
allocations,
don't
really
vary
as
a
function
of
payload
size
they're.
You
know
they're
within
15,
20
percent
of
each
other,
but
the
the
jdk
exporter.
If
the
payload
size
goes
up,
you
know
the
the
allocations
go
up
proportionally.
E
And
kind
of
what
like,
after
digging
into
the
internals,
you
know
we're
talking
about
this
with
slack
I
asked
Ben
Evans.
If
he
had
any
input
on
this-
and
you
know,
I
I
found
this
part
of
the
internals
where
bite
buffers
which
are
used
as
this
intermediary
representation
to
read
bytes
from
the
input,
and
then
you
know
serialize
it
to
the
network
or
stream
it
to
the
network.
E
They're
they're
not
reused
in
the
jdk
HTTP
client,
so
there's
no
pooling
happening
so
every
time
you
need
one
of
these
bite
buffers
you
need
to
allocate
it
where
okay,
HTTP
and
the
Neti
ones
do
pooling
of
their
byte
buffers,
and
so
that
seems
to
be
like
the
Crux
of
the
issue
is
that
they
don't
reuse
their
bite,
buffers
and
I.
Think
kind
of
I
think
we
can
get
around
this.
Actually,
you
know
I'm,
just
thinking
out
loud
here.
E
I
haven't
done
this
yet,
but
I
think
we
can
vendor
in
the
the
the
portion
of
the
the
jdk
HTTP
client,
where
the
byte
buffers
are
are
allocated
every
time
and
you
know
adjust
it
to
to
pool
those
bite
buffers
instead.
F
Check
two
questions
on
the
approach
here.
The
first
one
is:
did
you
did
you
verify
or
is
there
a
way
to
verify
that
you
were
using
persistent
connections,
like
is
the
client
reusing
connections
or
is
it
creating
a
new
one?
Each
time.
F
Okay,
that's
fair,
just
something
to
think
about
and
then
I
think
the
jdk
11
can
be
used
in
both
an
async
and
a
sync
fashion.
Is
that
true.
E
It
is,
and
I've
I've
investigated
both
of
those
I
really
like
I,
really
bashed
my
head
against
this
problem,
trying
to
use
the
API
in
any
way
I
could
imagine
to
get
the
performance
in
line
yeah.
A
So
could
we
also
or
by
we
I,
mean
you,
maybe
you
and
Ben
working
together,
provide
a
patch
to
the
jdk
to
do
better
I
mean
I
know
it's
probably
not
going
to
make
it
into
like
backboards
to
11
or
17
or
whatever,
but
maybe
for
the
future.
B
I
can
ask
I,
can
ask
the
Microsoft
open
jdk
Team
to
take
a
look
at
this
also
see
if
they
have
any
thoughts.
Recommendations
for
I
mean,
like
you
said,
not
for
not
going
to
help
us
in
the
short
term.
E
Yeah
and
there's
some
useful
context
in
slack
that
I'll
include
in
this
PR
as
well
about
you
know,
specific
places
in
the
in
the
the
jdk
internals,
where
this
is
happening
so
I
kind
of
tracked
it
down.
E
But
yeah,
so
if
I
can
figure
this
out
and
I'm
more
optimistic
this
this
morning
than
I
was
two
hours
ago
because
of
this
option
to
vendor.
You
know:
I
think
this
is
this
would
be
really
promising
to
have.
E
You
know,
I,
don't
know
exactly
how
we
could
package
it
up.
We
could
do
a
multi-version
jar
where
we
have
a
Java
11
version
and
a
Java
8
version,
or
we
could
encode
something
in
the
artifact
name
itself.
That's
the
approach
that
guava
takes.
Guava
has
an
Android
version
and
a
JRE
version,
and
they
include
JRE
in
the
the
artifact
name
itself.
We
could
do
something
similar
to
to
make
it
less
magical.
Why
you're?
H
Sorry
I
missed
the
the
beginning
of
the
meeting.
I
I
just
jumped
in
on
this
part
back
to
the
the
kotlin
standard,
Library
question,
at
least
if
we
were
to
keep
the
OK
HTTP
client,
does
I
believe
that
some
of
those
libraries
that
do
the
the
the
renaming
like
shade
or
Shadow,
also
have
the
ability
to
prune
or
clean
out
depend
classes
that
are
unused.
H
So
if
we
did
that
with
the
the
kotlin
standard
Library,
maybe
that
would
reduce
the
size
and
the
impact
of
that.
And
then
we
could
potentially
keep
okay
HTTP
client
like
I
I
I'm,
not
opposed
to
what
you're
proposing
Jack
I'm,
just
making
sure
that
we
are
exploring
all
the
options.
D
But
removing
that
the
dependency
like
that
wouldn't
would
probably
break
the
library.
E
B
What
part
of
okay
GT
is
problematic
Jack?
Is
it
just
the
size
or
is
there
something
else
problematic.
H
I
mean
the
current.
The
version
that
we're
on
does
not
require
kotlin
right,
and
so
the
main
issue
is
that
we
can't
upgrade
past
that
and
if
we
want
to
upgrade
or
maybe
I'm
thinking
about
older
historical,
so
have
we
updated
to
a
newer
version
that
does
require
kotlin
believe.
E
E
H
Was
still
the
previous
that
was
not
kotlin,
so
we
upgraded
to
four,
and
now
we
do
have
that
kotlin
dependency.
I,
see
sorry
I'm
a
little
out
of
date
on
my
welcome
back.
B
H
Anyway,
the
the
proguard
I
think
might
be
worth
exploring
if,
if
we're
looking
to
vendor
okay
http.
H
E
This
kind
of
goes
away
if,
if
there's
a
a
dependency
free
version
of
this,
that
is
as
as
good
performance.
E
You
know
the
the
the
folks
that
would
care
about
this,
the
it's
it's
increasingly
small
intersections
in
the
Venn
diagram.
So
you
know
if
we
have
a
jdk,
11
plus
version
that
it
doesn't
use
any
dependencies
at
all
and
it's
high
performance,
then
the
folks
that
would
care
about
the
OK
HTTP
dependency
are
folks
that
are
stuck
on
Java
8
and
have
a
problem
with
the
the
kotlin
transitive
dependency,
yeah
and.
H
So
you
know,
but
you
were
saying
that
the
I
I
guess
I
I'm,
not
quite
understanding.
How
were
you
planning
on
getting
the
Java
11
HTTP
client
to
reuse
the
byte
buffers.
E
Oh
I
Can
Vendor
in
key
parts
of
the
internals
and
switch
the
implementation
I
just
kind
of
came
across
that
I
realized
that
this
morning.
H
And
is
this
with
the
Java
agent
or
with
the
the
the
SDK
or
both.
H
E
Yeah,
so
you
know
assuming
that
this
works
out
and
we
have
some
sort
of
multi-inversion
release
or
multi-release
jar,
or
you
know
jdk
HTTP
client
based
version
of
this,
then
the
folks
that
would
care
about
this.
Okay,
HTTP
dependency
are
stuck
on
Java,
eight
care
about
the
kotlin
dependency
and
are
not
using
the
agent
like.
That's
that's
a
hopefully,
a
really
small
portion
of
the
population.
The
user
base.
H
So
if
we
do
get
the
Java
11
we're
using
byte
buffers,
do
you
think
that
that
brings
the
performance
on
par
with
the
OK
http.
H
Well,
I
guess
great
work
on
owning
this
Jack
Bravo.
G
B
I
was
trying
to
think:
can
we
I
I
mean
it
would
be
nice
I,
I
kind
of
like
this
from
the
perspective
of
most
users
getting
than
not
having
that
transitive
dependency
in
their
class
path,
but
yeah.
F
F
B
E
E
I
think
there's
pros
and
cons
to
each
of
these
and,
like
the
multi-release
jar,
like
you
know,
one
strategy
that
we
use
elsewhere
in
the
repository
is
we
we
have
compile
time
dependencies
on
things
and
if
you
want
to
use
that
compile
time
dependency,
then
you
have
to
have
your
own.
You
know
dependency
on
that
implementation,
dependency
on
that
artifact.
E
We
could
do
a
similar
thing
and
you
know
essentially
assume
that
most
people
will
be
able
to
use
the
jdk
HTTP
implementation
and
for
the
folks
that
cannot,
you
have
to
add
this
additional
dependency
on
OK
HTTP.
So
it's
like
opt-in.
C
E
Okay,
HTTP
I
think
is
I,
mean
John
would
probably
know
best
or
Json
right,
but
I
was
under
the
impression
that
ok,
HTTP
was
kind
of
the
the
most
popular
HTTP
client
in
the
Android
space.
C
B
Hey
Splunk
team,
nice
I
saw
the
proposal
to
donate
the
rum.
The
Android
run
run
stuff.
That's
awesome,
cool.
F
G
F
H
So
question
on
the
the
proposal
to
kind
of
split
up
the
dependencies.
Sorry
back
to
the
the
HTTP
question:
what
is
the
is:
is
that
currently
bundled
directly
with
the
the
SDK?
Does
the
SDK
bundle
the
otlp
exporter
currently
now?
H
Okay?
So
it's
already
a
separate
dependency,
so
I
think
that
it
would
make
sense
to
potentially
have
it
split
up
then
to
have
maybe
an
otlp
exporter,
Java
11,
HTTP
client
and
a
otlp
exporter,
okay,
HTTP
client
and
maybe
just
have
two
different
implementations
of
that.
E
E
You
know
without
having
to
introduce
a
new
class
name
that
has
like
you
know
the
implementation
encoded
in
it
like
I,
don't
think
we
should
have
an
otlp
HTTP,
jdk
span
exporter
and
an
okay
otlp
HTTP,
okay,
HTTP
span
exporter,
I!
Don't
think
we
should
do
that.
I
think.
H
Yeah
no
I'm
not
suggesting
we
change
that
class,
name
and,
and
maybe
I,
don't
fully
understand
it,
but
I'm
just
suggesting
that
what
if
we
just
did
this
at
the
the
maven
dependency
layer
and
right,
the
the
class
name,
the
same
yeah.
E
So
that's
that's
this!
That's
the
second
option
here:
encode
implementation
into
the
artifact
name
and
that's
what
guava
does
and
you
know
I
think
I
I
like
that
in
a
in
a
lot
of
ways,
because
it's
you
know
it
forces
the
the
user
to
make
a
conscious
decision
of
of
what
they're
what
they're
consuming,
rather
than
being
surprised
by
the
behavior.
H
B
F
H
I
mean
even
if
we
have
it
split
up
where
that
we
have
a
default
transport
defined
as
a
hard
dependency.
H
If
somebody
wants
to
swap
it,
they
can
always
exclude
that
one
dependency
and
add
another
add
the
other
one.
So
by
default
you
you
have
one
selected
I.
H
By
going
down
this
route,
though,
it
seems
like
we're
kind
of
preferring
the
Java
agent
to
go
with
just
the
default
option.
If
we
have
the
the
Java
11
HTTP
client,
oh,
but
that
wouldn't
work,
never
mind.
I,
see
that
wouldn't
work
with
Java
8.
E
C
H
Okay,
so
if
we
go
down
this
route
of
having
two
different
transports,
the
Java
agent
would
still
use
the
OK
HTTP
one
because
it
doesn't
need
to
worry
about
exposing
the
kotlin
library,
because
it's
all
isolated.
D
B
If
I
can
find
it,
yes,
so
in
carcass,
so
we
were
looking
at
potentially
like
having
a
submitting
vendor
vendor
specific
exporter
to
corkus
sort
of
similar
to
like
the
gcp.
Here.
D
B
The
integration
testing
and
was
curious.
It
sounded
like
you,
wanted
integration
testing,
including
the
back
end
for
this.
D
So
by
integration,
testing
I
mean
there's
a
on
that
project.
If
you,
if
you
go
into
the
code,
there's
a
companion
project
which
is
just
for
integration
tests,
where
you
have
an
actual
application
that
will
use
that
exported
to
do
things.
D
So
yeah
and
yeah
integration
tests.
D
D
Well
any
well.
He
he
did
some
mocking
as
well
in
this
particular
PR,
but
I
think
it's
not
possible
to
just
check
with
gcp
and
see
if
it
works,
because
you
would
need
a
key
and
also
it's
not
the
good
practice
practice
to
have
a
90
tests.
That
depends
on
an
external
system
that
might
be
on
or
off
or
whatever.
B
Okay,
but
it
looks
like
it
is
okay,
spinning
up
of
like
a
pretty
I
guess
that
kind
of
my
question
was
partly
why
it
needed
to
be
such
an
extensive
integration
test
when
the
yeah,
if
there
was
any
way
to
just
you,
know,
unit
test
this
since
there's
already
a
contract.
The
open,
Telemetry
exporter
interface,
contract,
because.
D
D
D
Ty
extension,
but
the
younger
one
will
use
an
in-memory
exporter
for
sure.
Just
just
the
memory
exporter.
B
I
see,
okay
and
any
do
you
see
any
issue?
So
if
we
just
because
it
looked
like
the
actual
code
involved-
or
this
was
more
limited-
oh,
this
is
yeah.
Like
the
you
know,
config
stuff,
if
we
Host
this
outside
of
this
repo,
can
users
still
use
it
or
does
it
have
to
be
hosted
in
this
repo.
D
B
B
F
B
E
A
E
From
an
SSL
context,
you
can
get
a
socket
Factory,
I,
I,
guess
what
I'm
trying
to
figure
out
is.
Can
you
and
at
like
I,
got
close
to
this,
but
I
haven't
determined
it
fully
from
an
SSL
contacts?
Can
you
configure
the
OK
HTTP
client
with
its
socket
Factory
in
its
trust
manager
like?
Can
you
get
a
trust
manager
from
an
SSL
contacts
because
that's
a
required
argument?
Yeah.
F
E
Yeah
and
I
actually
think
this.
This
exercise
with
exploring
the
H
jdk
HTTP
client
has
been
helpful
because
you
know
it
forces
you
to
understand
how
yet
another
library
is
configured
from
a
an
SSL
perspective,
and
hopefully
this
is
the
last
API
change.
We
need
related
to
related
to
this
and
we
get
it
right.
Cool.
F
B
Hey
quick
question
for
everybody:
does
anybody
use
the
YouTube
recordings
meeting
recordings.
H
I
think
I
would,
if,
if,
if
it
were
fixed,
I
I
submitted
an
issue
about
this
a
while
ago
way
back
when
there
used
to
be
specific
playlists
for
each
of
the
Sig
meetings,
but
now
I
believe
the
Sig
meetings.
Individual
playlists,
don't
work
anymore,
and
it's
just
one
big
lump
sum
of
YouTube
recording.
So
you
have
to
kind
of
filter
through
each
of
the
ones
to
find
the
right.
One.
F
C
B
H
I
think
some
stick
meetings
like
this
one
do
a
much
better
job
at
taking
good
notes
so
bonus
to
you,
Trask
for
generally
being
the
one
to
take
those
good
notes.
Other
cigs
struggle
a
little
bit
more,
so
the
notes
aren't
quite
as
actionable.
B
And
that
was
yeah
that
was
raised.
I
think
we
would,
if
we
stop
the
recordings
there
would
be,
we
would
need
to
push
for
everybody,
including
even
ours,
to
you
know
like
really
have
the
notes
make.
H
Sense
another
option
that
might
be
worth
considering
is
Zoom.
Has
the
the
live,
captions
I
wonder
if
it
would
be
possible
to
take
that
and
Export
just
the
the
text
form
of
the
live
captions,
as
maybe
some
sort
of
an
additional
resource?
In
addition
to
the
notes.
H
D
But
how
it
would
solve
the
issue
with
harvesting
these
meetings
for
by
some
agents.
H
Ai
agents
I
think
the
concern
was
to
have
live
recordings
of
audio
and
video.
So
by
publishing.
Just
the
the
the
captions
then
I
think
that
maybe
that
wouldn't
be
as
big
of
a
concern.
E
G
B
Concern
that
was
brought
up,
not
the
not
the
general
harvesting
of
the
content
itself.
G
H
The
other
benefit
to
potentially
using
the
transcripts
is
I.
Think
it's
easier
to
search
and
find
information
in
text
than
it
is
to
scan
through
a
video.
B
Yeah
I'm
watching
these
the
captions
it's
so
far,
so
good.