►
From YouTube: 2020-11-18 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
A
C
Good
evening,
good
afternoon,
sergey
good
morning,
you're
sort
of
morning
you're
late.
B
C
C
Oh
so
now
I
wonder
what
you
and
I
nikita
were
six
off.
I
wonder
if
nikita
has.
A
C
D
Not
the
whole
thing
I
went
to
the
breakout
sessions
because
I
didn't
get
up
early.
C
C
Was
like
eastern,
it
was
started
early.
I
guess,
for
europe
folks
in
europe.
D
And
then
I'm
I'm
going
to
be
in
the
splunk
booth
on
friday,
so
extra
fun.
C
D
Turn
off
my
video,
because
splunk
did
something
to
our
laptops
today
and
everyone's
complaining
that
they've
slowed
down
to
a
crawl.
C
A
D
Well,
I
think
the
the
thing
that
kind
of
started
me
down
the
path
of
confusion
was
trying
to
figure
out
how
to
have
the
sdk
builder.
Let
you
add
spam
processors,
which
is
very
it
seems
very,
very
easy
until
you
call
two
builder
on
an
existing
sdk
and
then
you
have,
what
do
you
do
with
the
tracer
provider?
That's
there
and
do
you
just
add
spam
processors
to
it,
which
means
that
any
other
instance
of
the
sdk
will
also
get
those
spam
processors.
D
D
There
was
also
the
confusion
that
I
ran
into,
which
is
a
little
bit
separate,
which
is
the
clock
and
the
resource
both
at
the
sdk
level
and
down
in
the
deeper
level.
And
what
do
you
do
with
those.
D
A
D
A
Yeah-
and
we
could
add
the
spam
processor
to
that
by
calling
to
builder
also,
I
think
right
like
so
one
thing
I
think
the
end
goal
still
not
sure
if
it's
possible,
but
one
of
them
goes,
is
to
make
sure
that
the
tracer
providers
were
actually
immutable
so
that
you
can't
add
an
existing
one.
You
always
have
to
build
around
those
also
does
that
help
with
the.
E
D
C
C
C
Oh,
I
remember
I
copy
pasted
this
to
this
was.
C
From
last
thursday,
but
I
will
just
keep
I'll
just
keep.
Oh
am
I
sharing?
Oh
I'm
sharing
the
the
big
screen.
Sorry,
I
usually
share
the
small
screen,
but
so
it's
probably
not
readable.
C
E
A
C
All
right
so
system,
metrics.
A
C
Yeah,
I
wasn't
really
sure
what
the
purpose
like
what
what
problem
would
it
solve
sergey
moving
the
instrumentation
to
the
java
repo.
B
Yeah
yeah
so
idea,
right
now,
from
from
like
vendor
specific
agent,
we
will
call
systematics
java
to
for
registration
all
observers
yeah
for
from
after
instrumentation.
We
cannot
call
it
because
it
produced
errors.
C
Okay,
so
there's
two
there.
I
guess
two
different
issues:
first,
on
moving
the
system
metrics
to
the
java
repo.
What
what
is
that
trying
to
solve.
C
So
where
are
you
putting
so
the
I
guess,
ideally
in
a
vendor
distribution,
you
could
just
you,
could
either
shade
it
or
put
it
in
your
in
the
agent
class
loader.
C
I
guess
putting
it
in
the
agent
class.
Loader
is
probably
ideal,
and
then
you
can
just
call
it.
B
C
Kind
of
talking
about
the
emit
sequence
and
also
the
class
loaders,
so
I
think
what
I
would
probably
be
doing
yeah
if
I
wanted
it
in
my
vendor
distribution
is,
I
would
probably
put
it
in
the
agent
class
loader,
because
then
it's
isolated
and
it's
not
in
the
bootstrap
class
loader
and
and
then
you
would
initialize
that
initialize
it
at
that
point
and
use
it
from
the
agent
class
loader.
C
C
C
C
I
think
it
would
probably
help
you
to
go
through.
Have
you
gone
through
nikita's
example?.
C
C
Yeah
check
out
this
pr.
I
would
just
pull
down
this
pr
directly
since
it's
not
merged
yet,
but
it
goes
through.
It
has
examples
of
all
of
the
different
customization
points
and
I
think
that's
going
to
help
you
a
lot.
B
C
C
But
start
with
this,
this
is
the.
This
is
a
really
good
example,
and
it
kind
of
is,
you
know,
we're
making
it
best
practices
and
how
to
build
a
vendor
distro.
C
So
if
you
follow
all
this,
and
if
you
can
point
us
to
your
distro
and
if
it
follows
this
pattern,
it'll
make
sense
to
us
also,
and
we
can.
We
can
help
probably
more
easily.
B
B
B
A
A
C
And
then
I
think
that
the
how
the
propagator
issues
looks
like
that
one,
the
spec
pr
should
get
merged
and
we'll
merge
that
I
think
we're
good
to
merge
this
tomorrow.
I
just
wanted
to
make
sure
there
weren't
any
spec
concerns,
and
then
there
was
the
other
one,
though
I
was.
C
C
So
I
I
think
that
we
should
get
it
into
the
spec,
the
problem,
if
we
don't
have
it
in
the
spec,
if
we
establish
this
behavior
for
the
hotel
propagators
environment
variable
if
they,
if
once
that,
is
specked,
if
it's
different,
then
it
would
be
a
breaking
change.
D
D
C
A
D
So
it
is
okay,
if
we
are
willing
to
have
the
default,
be
that
two
builders
will
end
up
having
everybody
share.
Tracer
providers.
A
D
A
D
Things
get
things
also
a
little
lower,
a
little
squirrely
with
the.
So,
if
the
builder,
if
you
call
set
tracer
provider
and
then
set
clock
like
what
should
the
behavior
be,
should
it
should
the
clock
be
ignored,
or
should
it
be
like
what
what
should
you
like?
It's
not
clear
what
should
happen
in
that
case.
Actually.
A
A
Yeah,
that
is
the
hardest
case.
I
think,
but
it's
a
builder
I
mean
we
could
always
just
like
the
later
calls
wins.
So
if
they
call
a
tracer
provider,
then
clock
we
reconfigure
the
clock.
If
it's
cost
increaser
provider,
it
gets
ignored
like
this.
That's
builder
normal
build
ordering,
but
it
is
tricky.
That's
definitely
true.
D
C
D
Adding
as
well
and
then
things
get
even
a
little
bit
weirder
because
the
clock
is
not
only
used
by
the
tracer
provider,
but
it's
used
by
like
the
the
it's
used
by
the
meter
provider.
So
if
you
call
set
clock,
what
is
the
expect?
What
should
the
behavior
be
like
if
I
have
an
existing
sdk?
I
call
two
builder
and
then
set
clock
like
what
should
happen.
Do
we
rebuild
the
tracer
provider
and
the
meter
provider
with
the
new
clock?
E
D
C
A
A
A
If
they're
still
using,
if
they
happen
to
use
the
same
spam
processor,
that
would
still
be
shared,
I
guess
we
would
never
share
the
same
instance
of
the
tracer
sdk
provider,
which
is
fine
because
it's
just
a
bag
of
other
stuff.
I
guess,
but
the
spam
process
just
could
still
be
shared.
If
that's
what
they
did.
D
D
So
the
meter
provider
is
the
metric
producer
right
and
I'm
doing
this
off
the
top
of
my
head,
because
I
don't
have
the
code
up
on
my
windows.
Machine
meter.
A
A
D
What
does
it
have?
It
has
the
metric
producer
and
the
component
registry.
The
component
registry
is
basically
where
all
of
the
trade
the
meters
are
registered.
I
believe,
and
the
shared
state
yeah
there's
also
views
registered
in
here,
there's
a
lot
of
state.
D
Let's
just
put
it
that
way:
a
lot
of
non-trivial
state
and
because
of
the
like,
if
you
have
the
an
exporter
hooked
up
via
a
timer
via
a
poll,
we
know,
we
know
that
you
could
only
have
one
associated
one
x,
one
thing
pulling
the
metric:
what
is
the
metric
producer
data
because
otherwise
you
get
like
you,
don't
get
the
right
data
unless
everything
is
configured
to
be
cumulative
and
then
it
works
fine,
but
you
can't
guarantee
that.
D
D
D
D
D
A
A
A
A
C
So
the
point
of
the
two
builders
currently
is
because,
if
you
want
to
add
like
something
you
want
to
modify
one
like
add
a
span
processor,
you
take
the
current
one
called
to
builder.
Add
your
spam
processor
build.
A
Yeah,
I
forgot
you
so
one
point
I'd
want
to
mention
is
the
main
use
cases
to
reconfigure
the
context
propagators,
I
think,
and
actually
the
first
version
of
my
code.
I
did
use
a
method
called
with
propagators,
because
I
thought
that
satisfies
the
main
use
case,
and
the
main
reason
I
went
with
two
builder
was
just
to
be
more
consistent
with
a
lot
of
other
classes
which
have
to
builder,
but
maybe
that
wasn't
a
good
idea.
A
A
D
Yeah
I
have
a,
I
guess.
I
have
a
hard
time,
knowing
what
other
use
cases
might
be
out
there.
I
mean
it
feels
like
there's
a
use
case
to
have
resources,
yeah
resource,
exactly
yeah.
A
C
C
D
Well,
if
you
wanna,
if
you
have,
I
mean
I'm
thinking
of
app
server
use
cases,
but
hopefully
we
handle
that
in
a
different
way.
But
if
you
have
two
different
applications
being
served
out
of
the
same
jvm
in
some
way
or
another,
in
some
sense.
C
C
The
state
problem
you're
talking
about
because
if
you
do
with
propagators
right,
you
get
a
new
copy
or
with
resources
you
get
a
new
copy.
You
you
have
the
shared
state,
but
is
it
not
a
problem
in
that
case
because
at
least
it's
all
consistent
within
each
open
telemetry
instance.
C
B
D
D
C
I
see
right
they're,
not
getting
a
clone
of
that
span.
Processor,
okay,
okay,.
A
D
So
what
about
the
so
there's
a
use
case
or
there's
another
use
case?
There's
a
usage
pattern
that
I
I
see
happening.
I
will
see
happening.
I
predict,
which
is
open
telemetry.
I
have
an
instance
a
little
open
telemetry
with
propagators
assign
new
propagators
so
that
I
have
a
new
instance
of
open
telemetry.
At
that
point,
and
I
can
call
assuming
I
have
a
handle
to
the
sdk,
I
can
call
get
tracer
management
and
add
a
spam
processor
at
that
point,
with
our
current
apis.
D
A
C
Yeah,
I
I
agree
like
I
find
it
less
confusing
like
if
I
got
a
copy
of
something
that
it's
going
to
share,
that
that
same
span
processor
instance,
but
once
I
get
a
copy.
If
I
do
something
to
that,
I
wouldn't
expect
that
to
affect
the
other.
D
A
A
A
A
C
D
So
from
so
I'm
happy
to
work
on
this,
I'm
trying
to
figure
out
what
the
like,
what
the
steps
I
should
take
like.
Are
there
incremental
steps,
or
does
it
kind
of
all
have
to
be
ripped
out
at
once?.
D
Let
me
let
me
let
me
take
a
look
at
this
tomorrow.
I
actually
have
I'm
not
going
to
be
completely
in
planning
meetings
all
day
tomorrow,
so
I
probably
have.
A
One
thing
that
this
probably
does
requires
making
the
tracing,
config
and
interface,
though,
because
being
able
to
dynamically
update
the
tracer
config
is
important.
That
doesn't
mean
it
has
to
be
by
mutation,
though
it
could
be
a
dynamic,
tracer,
config
implementation,
which,
to
me
seems
easier
to
reason
about
anyways.
D
C
Change
the
the
sampling
rate
at
runtime.
A
B
C
B
A
Race
config
itself
to
handle
the
dynamicism
like
and
sort
of
like
most
trace.
Configs
are
static.
Some
people
might
want
a
dynamic
one,
so
we
separating
those
use
cases
seems
good
anyways,
maybe
from
a
performance
aspect,
but
also
like
most
trace
configs.
If
they're
dynamic,
they're
going
to
be
like
pulling
from
some
config
service
and
then
updating
the
values
that
should
probably
just
be
its
own
implementation,
anyways.
A
D
Actually,
the
z
pages
right
now
see
pages
right
now
supports
updating,
trace,
config.
A
D
D
D
D
I
think
the
so
the
other
route
that
I've
been
thinking
about
is
providing
a
way
to
so
essentially
essentially
say
that
you
can
never
share
the
state
between
two
tracer
providers
and
that
when
you
do
two
builder,
you
basically
get
a
cloned
like
some
some
kind
of
cloning
of
of
the
current
configuration.
B
A
D
A
Yep
the
span
handler
is
shared,
and
that
makes
sense
to
me
I
mean
you
would
want
to
share
that.
I
think
yeah.
So
that's
like,
I
think
in
practice.
The
only
thing
you
ever
dynamically
reconfigure
or
want
to
reconfigure
is
the
sampling
and
the
brief
seems
to
have
special
case
for
that
and
share
everything
else.
C
A
D
C
D
A
Yeah-
and
so
in
that
case,
like
even
just
the
trace
id
ratio,
sampler
thing
sample
rate
can
be
middle
right
and
that
would
work
fine
with
the
z
pages
it
doesn't
have
to
be
at
the
trace
conflict
level,
because
looking
at
the
trace
config,
actually
the
trace
config
itself,
it
seems
to
be
mostly
content.
Con
constants,
like
your
max
num
events,
max
attributes
these
things
these.
I
don't
think
anyone
really
cares
about
mutating
everyone
playing.
A
C
A
A
A
C
I
did
that
for
my
sampler,
which
just
has
you
know
a
mutable
sampling
rate.
A
Yeah
yeah,
I
don't
I
wouldn't
imagine
people
wanting
to
change
their
sample
strategy
completely
at
runtime,
maybe,
but
that,
like
brave,
doesn't
support
it.
I
think
most
libraries
don't
support
that
that
I've
seen
we
do,
but
I
don't
know
if
people
really
need
it,
though
I
imagine
most
people
update
this
trace,
complete
just
to
replace
the
trace
id
sampler
with
another
trace3d
sampler
with
a
different
rate.
I
can't
imagine
anything
better
than
that.
D
Yeah
me
neither,
but
I
know
dynatrace
is
trying
to
do
some
crazy
stuff,
so.
C
D
Well,
I
think,
right
now
we
support
getting
like
calling
to
builder
on
the
trace
config.
C
C
And
that
that
could
stay,
I
was
just
thinking
that
the
sampler
might
make
more
sense
directly
off
of
the
tracer
provider.
C
As
opposed
to
embedded
down
inside
of
the
trace
config
because
trace
config
to
me
sounds
like
like
a
json
like
property
like
a
property
bag
and
sampler,
doesn't
feel
like
it
fits
that.
A
A
If
we
don't
support,
update,
trace
config
at
all,
you
have
a
dynamic
sampler.
You
call
when
you're
configuring
sdk,
you
call
set
updatable
sampler,
you
have
a
reference
updatable
simpler
outside
of
the
instances
and
then
it's
more
obvious
that
that's
shared
and
when
you
update
the
update
through
the
sampler,
not
through
the
open
telemetry.
A
A
A
D
It
almost
makes
me
want
to
just
make
the
propagators
mutable
always
like
go
back
to
set
propagators,
and
not
I
mean
have
the
not
propagators,
be
mutable,
but
the
like
that
being
the
one
piece
of
mutability
in
open
telemetry,
because
they
are
kind
of
as
we
we've
talked
about
they're
kind
of
off
in
their
own
world.
They're,
not
really
part
of
open
telemetry
we're
just
putting
them
there
for
ease
of
getting
a
handle
to
them.
D
A
C
But
why
why
are
we
grouping
the
other
ones
into?
Oh,
because
that's
to
pull
in
all
state.
D
Then
I
don't
need
to
worry
about
people
making
copies
of
things
and
not
understanding
that
they're
going
to
be
get
all
the
shared
like
get
all
of
the
other
shared
state
along
with
it
like.
If
they
just
can,
they
have
an
instance.
They
can
either
create
a
brand
new
instance
from
scratch,
or
they
can
take
their
instance
and
replace
the
propagators
and
they
don't
have
any
other
options,
except
whatever
configuration
we
already
have
exposed
via
tracer
sdk
management.
A
C
B
D
I
mean
that's
that
feels
like
that's
the
other
solution.
Is
you
either
make
it
essentially
completely
uncopyable
or
you
make
it
fully?
Copyable,
like,
I
think,
if
you're
in
some
sort
of
weird
in
between
state
reasoning
and
having
her
having
end
users,
reason
about
how
things
are
going
to
work
is
going
to
be
difficult.
A
D
A
D
A
C
A
A
For
otherwise,
you
have
to
make
sure
your
propagators
are
the
superset
of
what
all
your
back
and
support,
which
is
pretty
inefficient.
If
you
don't
need
it
like,
if
one
backhand
only
supports
b3,
the
other
supports
jaeger
or
whatever,
sending
all
of
them
to
everyone,
that's
a
huge
amount
of
duplication
and
headers.
A
C
D
I
mean
from
the
way
you
talk
about
that,
though.
That
makes
me
really
want
to
have
propagators,
be
a
separate
thing
that
isn't
related
to
the
open
telemetry
instance
at
all,
because
you
would
want
to
share
all
the
other
stuff
and
if
you
don't
want
to
share
the
propagators
like
inject
them
separately,
right.
A
D
So
I
think
in
in
that
case,
I
think
it
would
be
reasonable
to
have
the
global
have
a
some
propagators
that
can
be
updated,
but
then
have
information
instrumentation
be
able
to
get
its
own
copy
of
propagators.
If
that's
something
something
that
it
needs
like
if
it's
doing
client
or
server
well,
client
is
the
bigger
deal
right
server
doesn't
matter,
you
can
just
have
all
the
propagators
pulling
whatever.
Is
there
right?
A
D
So
most
instrumentation
you
can
just
you
know
either
just
use
the
globals
or
use
whatever's
on
your
configured
onto
your
open,
telemetry
and
well.
I
guess
I'm
saying
don't
put
it
on
the
open
telemetry
instance.
Aren't
I
yeah
well,
but
the
only
thing
that
needs
prop
needs.
Propagators
at
all
is
server
and
client
right.
Well,
I
guess
producer
consumer
also
needs
them
right.
A
A
A
D
A
My
bi-weekly
thing
on
the
spam
context
is
interesting.
Yeah,
which
one
expand
context
is
an
interface
of
course,
no
progress,
but
oh.
C
C
C
C
C
C
This
one
of
the
things
I
wanted
to
ask
john-
I
forgot
about
this
because
john
had
removed
his
he
had
approved
this
and
then
he
had
unapproved
it.
C
So
I
think
we
need
to
make
sure
he
buys
in
you
know.
I
think
we
need
to
get
him
to
reapprove.
C
Before
we
can
say
that
we're
blocked
on
bogdan
okay,
that's
true:
let's
get
him
on
thursday,
I'll
put
it
on
the.
C
A
C
That
makes
sense
to
me
allow
package
multiple
instrumentations
yeah
yeah,
I
mean
so.
I
agree
at
least
for
the
first
step
for
sure
not
trying
to
throw
the
whole.
I
know
nikita
had
proposed
doing
the
full
whole
agent
and
maybe-
and
we
can
test-
I
mean,
there's
two
concerns.
One
is
the
performance
slowness,
the
other
is
just
updating
all
of
our
tests.
C
If
there's
interdependencies
that
we
haven't-
which
I
guess
is
probably
a
good
thing
but.
A
A
C
If
possible
and
then
oh
yeah,
there
was
a
comment
about
the
you
were
asking
about
agent
tulene,
not
being
in
the
instrumentation
jar.
C
A
So
one
thing
I
ran
into
was
this
dependency
hell
where,
if
a
test
depend
on
the
tooling,
it
would
bring
in
bootstrap
and
break
the
agent
loading,
and
then
I
finally
was
able
to
figure
out
how
to
permanently
exclude
bootstrap
from
the
test
runtime
class
path.
So
it
solved
that,
but
I
found
myself
while
doing
this.
It
was
always
confusing
understanding
what's
bringing
in
which
dependency
like.
I
would
still
expect
it,
not
necessarily
this
project
called
java
agent,
but
it's
the
agent's
job
to
bring
in
its
functionality.
C
A
A
C
Agree
I
like
that,
if,
if
you
are
able
to
transition
that
out
that.
A
Yeah,
I
think
it's
because
also
like,
because
in
my
test
stage,
so
I
think
it
might
be
all
right
now,
since
I
switched
that
to
compile
only
the
smug
test
would
probably
fail
like
I'll
have
to
fix
that.
But
for
my
test
agent,
I,
when
I
found
I
needed
java
tooling
in
the
agent
class
loader,
I
just
added
as
a
dependence
to
my
exporter
jar
and
then
things
started
working,
and
so
it's
like
as
long
as
it
gets
into
that
ins,
it
doesn't.
C
A
A
C
Basically,
this
here
but
yeah
yeah,
that
makes
sense
to.
B
C
Yeah
yeah,
because
it
doesn't
it
it's
sort
of
overloading
the
concept
of
instrumentation
and
yep
yeah.
It
would
be
nice
and
then
it
would
also
help
the
the
build.
I
was
imagining.
It
would
help
the
build
times,
because
when
you're
modifying
instrumentation,
then
it
wouldn't
need
to
rejar
that
part
each
time
potentially
with
with
what
you're
doing
at
least
where
you're
only
reacharing.
A
Normally,
you
don't
yeah
so
that
I
think
is
not
an
issue.
Yeah
like
I
was
finding
myself
getting
confused
and
then
reconfused
several
times
just
because
like.
Why
is
this
depending
on
cooling
or
why
is
this
including
too
inverse
feeling
coming
from
man,
so
I
did
find
myself
confused
and
that's
the
main
reason.
I
added
that
comment
on
nikita
spr,
but
definitely
right
now
we're
just
using
that
one
project
as
sort
of
a
grab
bag
of
agent
class
loader
dependencies,
not
instrumentation.
C
C
Yes,
yes,
yeah
yeah,
and
it
does
make
for
a
very
that
is
I've
found
myself
getting
lost
in
this
gradle
file?
Oh,
it's
a
lot
better
than
it
used
to
be.
A
Are
you
sharing
something?
Are
you
trying
to
share
something.
C
Okay,
I
was,
I
thought
I
was
sharing
intellij.
I
thought
I
was
sharing
my
whole
screen,
but
let's
look
at
because
I
thought
it
used
to
be
a
lot
more
complicated.
D
A
A
A
Yeah
and
it's
because
for
some
reason,
if
the
bootstrap
projects,
its
jar,
is
on
the
runtime
class,
but
the
agent
was
getting
loaded
from
that
and
that's
not
what
I
would
expect,
because
the
java
agent
is
job
agent..
Why
would
it
look
at
any
other
jar
to
get
the
agent,
but
that
seems
to
be
what
was
happening
and
that
was
really
surprising
to
me.
C
Yeah,
you
know,
I
find
it
surprising
that
pre
main
runs
in
the
system
class
loader
with
your
whole,
like
system
class
path,
everything.
C
A
C
A
A
A
A
A
A
A
C
A
C
So
that's.
Why
agents
why
our
agent
and
other
agents
kind
of
typically
get
out
of
the
system
class
path
right
away.
A
C
And
switch
down
to
the
bootstrap
and
we
need
the
to
be
in
the
bootstrap
just
because
of
job
we
want
to.
If
we
want
to
instrument
java
classes
that
are
in
the
bridge,.
B
A
A
C
A
A
C
Yeah
you
you've
been
hitting
a
lot
of
good
ones
for
sure.
Did
you
see
pavel
ran
into
the
the
abstract,
the
the
default
interface
method?
One.
B
C
A
A
C
Very
normal
thing,
like
yep,
exactly
you'd,
expect
that
to
work,
and
then
you
get
a
verify
error.
Yeah.
A
A
C
A
C
A
A
C
Yeah,
I
I
mean,
then,
that
if
you
are
able
to
make
progress
on
other
things
and
ping
that
you
know
there's
some
particular
problem.
A
A
A
C
How
many
so
is
that
running
which
tests
are
you
you've,
run
you're
running
all
the
tests?
Now
all
the.
A
I
mean
I've
been,
I
was
running
it
and
then
we
had
her
call,
and
so
I
turned
it
off
to
not
delay
my
video
but
I'll
keep
on
running,
but
many
many
tests
are
passing
now
so
yeah
the
testing
common
and
those
are
like
the
tooling
tests
are
all
going
to
fail.
I
think
because
those
just
have
to
be
updated
because
things
have
changed,
but
the
instrumentation,
I
think
we're
almost
there
so.
C
Yeah,
I
really
liked
all
the
the
agent
test
runner
getting
gutted.
C
A
Cool,
no
any
thoughts
on
the
whatever
order
access
classes
like
is
that
the
pattern
you
would
sort
of
expect
for
this
project?
What
not
to
get
through
the
class
loader
bridge.
A
C
A
C
C
Yeah,
no,
it
made
a
lot
of
sense
to
me
yeah.
I
agree.
That's
the
only
other
op
I
mean
the
the
next
option.
The
other
option
I
would
consider,
is
a
bootstrap
class,
but
it's
it's
a
lot
nicer
than
doing
it
going
over
in
memory
there
than
over
a
socket.
C
C
A
A
C
C
A
Like
if
today
was
like
users,
can
our
internal
customers
tend
to
implement
their
context
themselves
anyways,
so
they
can
just
use
open
community
context.
It's
much
more
robust,
because
I
read
very
highly
robust
context.
Implementation.
It
has
the
like
one
thing
they
want.
Is
that
debug
thing
like
the
strict
scope,
storage
that
we
have
and
so.
A
That
stuff
in
x-ray
sdk
is
of
course,
an
option,
but
then
the
other
idea
came
to
mind.
I
guess
people
could
just
use
that
we're
not
ready
to
roll
out
open
telemetry
itself
for
some
time
until
we
get
more
used
to
running
the
collector
instead
of
the
x-ray
demon.
That's
some
production
experience
required
there,
but
open
telemetry
context
by
itself.
I
don't
see
any
problem
with
people
using
that,
so
we
might
actually
use
that.
C
For
so
is
open
telemetry
in
the,
because
I
assume
that
each
customer
runs
in
their
code
inside
their
own
inside
of
a
it's
a
class
loader
contained.
C
So
I
wouldn't
expect
if
a
customer
was
using
open
telemetry,
but
if
opened,
I
was
assuming
open.
Telemetry
is
in
the
the
root
class
loader
or
something
for
the
lambdas.
Now,
since
you
are
pulling
it
into
x-ray,.
A
A
No,
it's
you
could
it's
the
graphql
service,
so
it's
sort
of
a
proxy
server.
Basically,
the
business
logic
was
to
live
in
a
lambda
and
that's
fine,
but
the
proxy
server
forwards.
The
request
to
all
these
different
lambdas
without
using
isolated
class
loaders,
probably
like
that,
would
be
per
request,
not
for
customers.
Sort
of
so
I
don't
think
you
can
do
that.
Okay,.
A
A
Yeah
exactly
yeah,
but
that
wouldn't
have
the
cross
leak
with
this
because
most
of
our
managed
service
not
most
but
many
of
them
support,
reporting
stuff
decks
right.
So
all
the
proxy
servers
also
do
and
when
that
happens,
it
has
to
be
done
or
if
you
have
data
leaking
across
the
local
you're
in
a
disaster
zone,
and
that's
why
it's
been
a
week
of
meetings,
yeah
yeah,
but
on
the
right
side
we
have
like
that's
my
saving
grace
site.
A
C
Open
telemetry
context
is
that
in
its
own
artifact.
C
B
A
If
it
was
only
sdk,
I
mean
we
could
accelerate
getting
internal
customers
onto
open
telemetry
sdk,
but
we
also
require
the
collector
to
be
able
to
export
to
x-ray
and,
of
course,
then
replacing
a
production
server
type
of
thing,
but
demon
with
the
collector
that's
a
much
bigger
task,
security
reviews
and
all
that
stuff.
So
that's
I
mean
like
2022
is
when
I'm
hoping
that
we
have
a
good
story
for
onboarding
people
to
open
telemetry
2021
will
be
focusing
on
getting
ready
for
that.
I
think
internal.
A
C
A
A
C
C
C
E
C
Yeah
talk
to
you
on
thursday,
slash
friday.
Yeah
all
right
see
you.