►
From YouTube: 2022-06-30 meeting
Description
Instrumentation: Messaging
B
A
B
C
A
Quickly,
go
over
to
the
agenda.
Also,
please
add
your
name
to
the
gender
and
we
said
today
in
the
beginning,
we
want
to
wrap
up
the
on
the
aws
x-ray
demo
that
we
also
last
last
the
last
week
we
continued
on
that
we
didn't
with
something
else
also
going
on,
so
we
did.
We
went
when
we
weren't
able
to
finish
so
we
said
we
are
gonna.
Do
this
as
first
to
train
the
point
today,
so
we
can
wrap
them
up
on
that
and
then
maybe
we
can
continue
discussing
attribute
names
if
nothing
else
comes
up.
A
So
nirai,
if
you
want
to
kick
us
off
on
that.
D
Yeah
sure
thank
you,
so
let
me
share
my
screen
just
a
second.
D
Thanks
so
like
in
last
meeting,
we
were
discussing
about
the
agreement
that
we
had
on
16th
june
and
we
had
a
agreement
on
this
one,
and
we
were
talking
about
this
java
hotel
implementation.
So,
whatever
into
the
hotel,
there
is
a
open
telemetry.
This
java
instrumentation,
which
has
a
specific
implementation
for
aws
lambda,
so
just
sorry,
take
a
step
back.
So
what
we
were
saying
into
our
like
kind
of
what
agreement
we
had
is
by
default,
generate
the
links
in
a
managed
way
by
our
service.
D
D
So?
We
were
thinking
like
what
will
be
the
default
implementation
so
for
this
service
will
be
so
when
customers
actually
go
and
say
that
like
they
want
to,
like
our
links,
will
keep
generating
from
our
service
and
will
allow
customers
to
opt
out
if
there
is
a
cost
concerns
from
our
manager
solution.
D
D
What
like
our
understanding
of
this
library
is
that
it
allow
it
as
soon
as
customers
tries
to
instrument
with
this
library,
it
will
allow
customers
to
generate
the
links
at
the
lam
at
the
lambda
worker
side,
also,
so
by
default
they
will
get
this
linkings
at
the
lambda
worker,
so
you're
thinking
like
maybe
we
can
add
one
more
functionality
into
this
library
where
we'll
say,
okay
like
that
will
by
default
like
that,
will
not
generate
the
links
at
the
lambda
worker
side.
However,
there
are
options
like
that.
D
It
already
provides
an
options
to
generate
the
links,
so
we'll
actually
add
more
options
to
say
that
okay,
you
want
to
instrument
your
libraries
you
want
to
with
the
hotel
just
go
ahead,
but
like
this
will
not
generate
the
links
by
default,
and
then
you
can
customize
on
top
of
that
one
to
allow
the
linkings.
So
we
were
thinking.
Is
it
okay
to
actually
change
this
library
based
on
what
we
discussed.
D
Sorry,
like
the
thing
is
like
this:
this
library
is
used
into
the
lambda
function
into
the
customer
code
and
as
of
now,
our
understanding
is
that
it's
saying
that
like,
if
you
are
processing
the
message
one
by
one,
then
extend
it.
This,
like
tracing
sqs
messaging
handler
and
if
you
are
doing
the
batch
one,
then
it's
like
this.
Our
understanding
is
that
as
soon
as
customers
extend
these
functionalities
it
they
will
generate
the
links
by
default.
They
will
start
generating
the
links
by
default
and,
as
we
were
discussing
like,
ideally
not
by
like
default.
D
But
ideally
we
want
to
generate
the
links
in
a
managed
way,
and
customers
should
have
some
way
to
like
not
generate
the
links
on
the
lambda
worker.
If
they
want
like,
they
should
be
option
for
both,
like
node
generator
links
and
as
well
as
generate
the
links.
Our
understanding
is
that,
as
of
now,
customers
doesn't
have
a
way
to
not
generate
the
links
that
in
their
code
at
the
lambda
worker,
so
you
are
thinking
like
to
enhance,
add
more
options
into
this
library
to
say
that
these,
like.
D
F
And
then
try
like
instrumenting
or
creating
a
deploy,
an
app
using
this
auto
instrumentation.
Did
you
see
it
creating
links
or
or
it's
just
your
assumption
at
this
point.
F
Okay,
because
if
it's
a
library
and
you
want
it
to
prevent,
for
example,
of
creating
links
without
the
user,
actually
wanting
that,
then
all
right
like
if,
if,
if
this
library
does
this,
what
you're
saying
like
creating
links,
then
I
guess
it's
just
a
matter
of
of
you.
F
I
guess
the
intention
party
of
of
sqs,
then
you
can
just
add
whatever
configuration
right,
that
you
can
add
to
this
library
to
disable
this
and
the
customer
has
to
opt-in,
for
example,
into
creating
links
or
not
creating
links
and
and
and
things
like
that,
if
you,
if
you
control
this
library
or
if
you,
if
you
have
interest,
I
guess
and
if
it's
possible
to
implement
some
sort
of
configuration,
maybe
there
is
already
some
configuration,
then
I
guess
it's
just.
A
I
you
know
I
added
like
two
links
into
the
chat
here.
Maybe
you
can
open
the
last
one
of
that,
because
there
is
all
right.
Oh
yes,
open
that,
because
there
is
like
this
aws
lamp
instrumentation,
there
is
a
part
in
the
in
the
specification.
A
This
is.
This
is
part
of
the
open,
elementary
specification
of
the
semantic
convention
that
is
specific,
specific
for
aws
lender
and
here
on
sqs
event,
when
you
look
at
the
second
paragraph,
it
says
the
second
sentence,
it
says:
if
it
is
present,
then
open.
The
elementary
context
should
be
parsed
from
the
value
of
the
attribute
using
the
aws
x-ray
propagator
and
add
it
as
a
link
to
the
span.
A
So
actually,
this
is
even
this
even
seems
to
be
kind
of
stacked
out
in
this
kind
of
aws
specific
semantic
conventions.
So
I
think
it's
I've.
Actually
I
didn't
never
went
to
this.
I'm
surprised
in
what
detail
this
is
backed
out
here,
but
I
think
it
it
might
make
sense
to
maybe
just
go
over
this
specification
document
here
and
see
whether
kind
of
this.
D
Yeah
thanks
yeah,
and
I
think
we
will
definitely
take
the
ownership
of
that
one
and
we'll
we'll
change
that
one,
but
just
wanted
to
get
an
like.
You
know
kind
of
guidance
or
feedback
that
is
it
okay.
If
this
library
actually
always
generates
the
link,
is
it
okay
to
change
this
library
to
say
like
by
default?
It
will
not
generate
the
links,
but
customers
needs
to
opt
in
in
this
library
somewhere
by
some
config
to
actually
generate
the
links,
also
at
the
lambda
worker.
F
Yeah,
I
guess
that's
more
like
on
on-
I
guess
amazon,
let's
say
interest
rate,
because
in
the
end,
it's
what
amazon,
amazon
customers
will
see
in
the
trade.
So
if
this
is
something
that
that's
how
I
see,
for
example,
I
I
guess
starting
our
place,
for
example
to
say
I
know
this
is
a
good
idea
for
you.
It's
a
bad
idea.
I
guess
in
the
end,
if,
if
you
have
these
internal
requirements
that
you
want
to
do
this,
I
guess
then
it
makes
sense
to
to
do
it.
Yeah.
F
A
F
Exactly
it
might
be
just
necessary
when
you
make
changes
that,
let
you
explain
why
the
changes
are
being
made,
and
maybe
you
have
to
put
up
some
reasoning.
We,
I
don't
know
like
we.
We
have
customers
asking
for
this.
Our
customer
is
not
asking
for
this,
and
so
the
so
they
put
up
the
spec
approval
or
spec
process
goes
smoothly.
Otherwise
they
just
think
it's
just
like
a
random
change
and
like
where
did
this
came
from
and
so
on?
D
F
Thanks,
maybe
we
can
just
think
what,
with
the
initial
intention,
what
where
he
was,
and
so
maybe.
A
Also,
I
have
to
say,
and
that's
not
for
you
specific
neural,
but
that's
for
our
discussions.
It's
actually
a
pretty
interesting
document
because
they
just
see
there.
We
actually
have
this
two
layer
of
complex
propagation
in
there
like
when
you
have
this,
this
lambda
function.
You
basically
get
this.
You
have
a
parent
span.
A
That
is
basically
the
server
span
corresponding
to
the
function
invocation
that
you
get
some
context
there
and
then
you
also
obviously
have
some
context
in
this
message
system
attributes
and
that,
basically,
you
add
as
a
link
to
the
spam.
That
is
basically
the
the
the
span
creation
context
more
or
less
so
that's
basically
more
or
less
what
we.
What
we
oh.
A
Yes,
so
this
inside
the
first
paragraph,
basically
here
it's
about
the
the
parent
span,
this
is
more
or
less
the
transport
that
is
who
invokes
the
the
lambda
function
and
the
second
paragraph
it's
about
this
context,
that
is
some
embedded
in
the
messaging
system
attributes
and
that
is
used
as
a
link.
This
is
basically
the
the
the
creation
context,
so
it's
kind
of
we
have
it.
Basically,
we
have
it
used
here.
What
we
kind
of
discussed
previously,
which
is
kind
of
interesting,
to
see.
F
F
E
D
And
just
said
next
thing
is
like
this
link
direction.
I
think
there
was
some
discussions
earlier
by.
I
believe
we
joined
like
microsoft
person
like
one
microsoft
version,
was
actually
giving
a
demo
on
that
one
on
like
they
were
also
saying:
there's
some
link
issues
so
what
we
into
what
happens
into
the
specs?
It
says
that
links
like
this
particular
span
is
linked
to
some
other
span.
D
What
happens
in
our
x-ray,
especially
into
the
user
side?
When
customers
tries
to
read
this
data,
we
always
show
them
the
directions
like
this
is
how
the
your
request
is
flowing
from
one
like
from
one
node
to
another
node,
and
we
this
arrow
is
used
to.
Actually,
you
know
help
customers
like
in
in
their
mental
model
like
how
their
requests
are
flowing
end
to
so
in
a
similar
way.
Suppose
there
is
sqs
message
which
was
pulled
by
the
lambda
front-end
service.
D
We
want
to
say
that
this
was
the
sql
message,
which
was
pulled
by
lambda
front-end
service
and
now
start
processing
again,
so
we
actually
saw
this
like
this
dotted
line.
This
dotted
line
means
the
link,
and
this
solid
line
means
the
parent
one
like
there's
a
parent
relationship
and
then
dotted
line
with
the
the
like
links.
So
in
parenthesis
we
already
know
that
there's
a
parent-child
relationship,
so
we
can
actually
make
mark
this
as
a
like.
We
can
easily
guess
the
direction
and
we
can
put
the
arrow.
D
However,
in
case
of
the
links-
and
we
were
thinking
we
like,
how
can
because
link
doesn't
have
a
directions,
at
least
our
understanding
is
that
links
doesn't
have
a
direction,
so
we
are
like
how
do
we
actually
make
it
as
a
link?
So
one
way
we
were
thinking
was
because
links
will
always
be
on
the
consumer
side
like
the
one
that
who
is
consuming
and
links
are
only
attached
to
the
consumer
nodes
on
the
creation
time
on
the
to
the
span
on
the
creation
time.
D
So
so
we
are
thinking
like
if
the
link
is
attached
to
a
node,
which
kind
is
consumer,
we
will
assume
that
this
node
actually
happened
after
the
ones
that
is
linked
to.
So
that's
why
we'll
actually
mark
the
link,
the
span,
which
has
a
link
and
consumerize
the
happened
after
event,
and
that's
how
we
will
actually
draw
an
arrow
any
sorry,
any
field
like
one
thing,
maybe
before
actually
and
in
future,
I'm
like
we
are
just
worried
that
in
future
there
could
be
cases
where
our
assumption
starts
breaking
and
we
might
need
to
like.
A
In,
in
my
opinion,
that
is
definitely
a
safe
assumption
and
I
mean
links
in
open.
Telemetry
are
not
really
directed,
so
there
is
no
like
really
like
clear
definition
of
a
direction
on
links
in
open
telemetry,
and
I
think
also
for
the
currently.
Basically,
this
overhaul
semantic
conventions
that
you're
working
on
the
idea
here
is
that
for
every
link,
basically,
every
link
will
go
from
a
span
of
type
producer
to
a
span
of
type
consumer,
and
I
think
it's
exactly
as
you
laid
out
here.
A
C
D
Future,
do
you
feel
like
like,
as
of
now,
we
are
actually
it's
a
combination
of
two
things
like
consumer
kind,
like
the
span
kind
of
consumer,
and
it
has
a
links,
then
only
we
are
saying
it's
happened
after
the
links
that
it
was
connected
to.
We
like
in
future,
like
links,
could
be
attached
to
any
kind
of
like
different
span
kind.
So
we
definitely
need
to
improve
our
logic,
but
we
are
making
it
very
strict
that
we
are
recognizing
the
directions.
Only
if
the
span
kind
is
consumer.
A
Yes,
we
have
the
same
the
same
problem
on
on
open,
telemetry
side.
That
and
I
mean
there's
ideas
of
of
adding
attributes
to
links.
I
mean
open
elementary
allows
you
to
add
attributes
on
links,
and
there
is
some
very
vague
and
that's
probably
a
bit
far
in
the
future
ideas
of
kind
of
having
semantic
conventions
for
those
attributes,
so
that
you
can
specify
link
types
more
granularly,
but
yeah
that
does
not
exist
yet.
D
Yeah,
that's
good.
Actually
what
we
were
doing
internally
is
almost
the
same,
because
now
we
are
converting
these
links
into
our
the
internal
format,
x-ray
format.
So
when
we
actually
convert,
we
actually
put
a
attributes
called
aws,
dot,
x8.,
and
then
we
say
like
what
this
link
is
pointing
to.
It
is
pointing
the
parent
or
child
so
yeah.
We
actually
have
a
similar
implementation
using
the
reserved
attributes
on
the
links.
A
Yeah
next
time
so
a
question
I
have
here
so
basically
here
this,
the
link
is
from
the
sql
service
to
the
lambda
frontend
service.
How
will
this
look
when
the
lambda
worker
basically
links
to
the
the
lambda
worker,
the
last
one,
that
kind
of
processes?
The
message
will
have
a
link
to
the
lambda
worker
that
created
the
message.
D
A
I'm
just
wondering
here
because
of
this
like
these,
these
this
link
types
because
processing
here
this
processing
message
will
just
be
a
consumer
too.
In
your
case,
will
this
be
a
spam
kind
of
type
consumer.
A
F
The
processing
message
one
circle
is
the
is
in
the
in
the
customer
app
area
at
that
point
right,
so
they
have
to
create
it.
Okay,
then
I
guess
it
should
be
client
right.
A
Oh,
I
actually
see
when
you
look
again
at
this
specification
for
aws
lenses
for
sqs.
It
says
that
the
if,
if
a
lambda
function
is
triggered
by
sqs,
then
the
span
kind
for
this
lender
span
should
be
consumer.
A
So,
that's
I
guess
that's
what
the
that's,
what
the
lambda
instrumentation
probably
currently
does
it's
for
the
it's
for
the
up.
It's
it's
still
further
up.
It's
it's
here
in
this
sqs
section
and
it's
basically,
the
last
sentence
to
spend
kind
for
both
types
of
sqs
bands
must
be
consumer.
A
Which
is
interesting
here
because
then
you
have
more
or
less
like
two
consumer
spends
for
the
same
message,
the
one
in
your
kind
of
polar
and
then
there
is
another
consumer
span
in
the
basically,
when
the
message
is
processed.
A
D
A
So
maybe
it
makes
anyway
sense
if,
if
you
plan
to
kind
of
rework
this
anyway,
it
makes
sense
for
you
to
go
through
this
document
and
kind
of
yeah
make
this
consistent.
Also,
in
light
of
this
new,
like
polar
instrumentation
approach
that
you
showed
us.
E
D
One
thing
we
were
thinking
sorry
on
the
similar
topic
is
maybe
in
future.
If
customers
actually
say
I'm
opting
out
of
this
linked
traces,
because
it's
costing
me
it's
depending
upon
how
we
actually
do
the
pre-pricing.
But
if
you
actually
have
some
like
these
links,
extra
informations
could
cost
customers.
Then
we
might
actually
ask
customers
to
opt
out
of
this
managed
link,
so
they
will
have
a
links
only
from
this
side
yeah.
But
then
it
did
this.
A
D
D
D
So
whenever
we
receive
a
message
suppose
the
consumer
received
or
this
receiver
received
two
messages
or
three
messages
out
of
that,
like
only
if
one
message
is
sampled,
so
the
we
mark
the
whole
trace
the
child
on
the
child
side
on
the
receiving
side,
we
marked
out
that
sampling
decision
on
that
trace
has
sampled.
If
any
of
the
upstream
message
is
sampled.
D
Now
what
happens
is
suppose
in
this
case,
if
there
were
two
messages
settlement,
one
like
sorry,
this
one
is
process,
one
and
process
message,
one
and
process
message:
two
suppose
process
message
was
sampled,
but
process
message:
two
was
not
sampled
and
we
are
marking
this
whole
invocation
after
the
receive
as
a
sample,
because
one
of
the
message
was
simple,
so
we
are
marking
the
whole
batch
as
a
sample
so
into
the
when
process.
D
One
actually
calls
its
downstream
services
suppose
calling
the
s3
and
we
are
passing
the
trace
contacts
as
a
sample,
and
it
makes
sense
because
process
message.
M1
was
sampled,
however,
if
we
call
the
like,
if
we
process
the
m2
message
and
then
suppose
call
the
dynadb
in
that
case,
what
will
happen
is
even
m2
was
not
sampled
earlier,
but
now
after
due
to
this
batching,
it's
getting
started
sampling
into
the
into
like
downstream
service,
so
we
actually
by
default.
That's
that's
our
default
behavior
and
what
we
are
thinking
is
like.
D
A
A
Yet
so
I
don't
the
open
telemetry
specification
doesn't
specify
any
any
rules
or
any
like
conventions
or
recommendations
there
and
like
it
is
definitely
a
problematic,
especially
when
you
have
a
high
volume,
because
I
mean,
if
you
just
have
this,
as
you
said,
it's
native
sampling,
where
you
said,
okay,
just
one
item
is
sampled
and
I
said
then
I
set
the
flag
to
true
for
children
when
you
have
a
sampling
rate
of
one
percent
and
you
receive
like
100
messages
on
average
it's
received,
and
basically
one
of
them
is
is
is
is
sampled
then,
from
that
on?
C
A
That
is
definitely
definitely
a
problem,
but
we
don't
have
any
solution
or
recommendation
for
that
yet,
and
we
didn't
discuss
that
yet,
because
that
is
kind
of
that
is
a
vast
topic
that
is
not
just
related
to
messaging
in
particular,
but
to
kind
of
links
in
general
there
is,
there
is
no.
There
is
no.
A
At
least
I
don't
know
of
any
kind
of
somehow
established
solution
for
that.
Yet
to
exist,
and
it
seems
to
me
it
seems
that
what
you're
doing
is
makes
sense
that
you
say
okay
from
this
process
on,
you
make
basically
a
sampling
decision
based
on
the
distinct
message.
Did
you
say?
Okay,
if,
if
I'm
processing
this
message-
and
if
this
message
is
sampled-
I
kind
of
sample
from
here
on
and
if
it's
not
sampled,
I
kind
of
yeah
that
sample
to
force
from
this
point
on
and
that
that's.
A
That
seems
that
seems
to
make
sense
for
me
and
with
that
you
are
you
also
basically
more
or
less
stay
true
to
the
kind
of
sampling
percentage
and
keep
the
volume
kind
of
in
line
with
that
percentage.
That
was
set.
D
Yeah,
so
only
only
one
one,
one
thing
is
that
we
cannot
detect
it
automatically
like
how
customers
are
processing
it.
So,
by
default,
like
all
the
whole
invocation
will
be
sampled
and
up
from
that
point,
the
everything
will
be
sampled,
but
we
are
allowing
customers
to
do
the
customizations
in
their
code
and
on
the
consumer
side
so
that
they
can
actually
like,
like
based
on
the
message,
individual
message
based
context.
They
can
actually
adjust
the
sampling.
D
D
A
I'm
I'm
not
sure
if
that
group
is
the
ideal
audience
for
this,
because
this
is
more
like
a.
I
think
what
you
what
you're
present
here-
that's
not
really
messaging
specific
that
is
basically
or
how
you
convert
the
open
elementary
data
format
to
x-ray.
A
F
Maybe
you
can
maybe
you
can
as
a
start
point,
maybe
you
can
post
this
in
the
general
slack
channel
and
then
see
who
else,
whoever
responds
that
is
interesting.
Maybe
they
seek
for
the
language
that
you're
planning
to
use
to
implement
this,
maybe
yeah.
D
Sorry,
maybe
I
was
not
clear:
we
already
have
this
hotel
exporter,
that's
already
working.
We
actually
want
to
enhance
it
for
the
links
like
how
links
will
be
converted
into
the
x-ray
format.
So
it's
like
only
specific
to
the
links
in
this
the
same
problem
that
we
are
working
on.
So
sorry,
that's
why
I
was
asking
if
this
group
we
can
present.
A
I
mean
from
from
my
point
of
view
you
can
definitely
present
in
this
group
when
you
have
like
a
time
box
demo
that
I
mean
I
would
be
interested
to
see
this,
but
I'm
so
you
you
can
do
it
in
this
group.
I'm
just
saying
that
you
might
get
better
feedback
from
actually
by
the
group
of
people,
because
links
are
not
really
like
just
a
messaging
specific
concept,
but
it
is
more
like
a
bigger
concept.
A
A
So
I
think
rao's
point
is,
is
good
that
you,
maybe
you
you
you
put
this
forth
into
slack,
maybe
in
the
open,
telemetry
spec
channel,
I
would
propose
and
then
and
then
see
who
is
who
is
interested
in
in
that
and
and
maybe
from
that
like
from
that,
like
you
can
go
further,
and
I
mean
if
there's
no
other
interest
you
can
present
in
this
group.
I
would
say
if
you
have
like
a
time
box
presentation
that
would
be.
D
Would
be
yeah
that
definitely
makes
sense
yeah
thanks
for
the
feedbacks
that's
all
I
have
alex,
you
want
to
add
anything.
A
Okay,
thanks
you're
right.
It
was
thanks
for
sharing.
That
was
at
least
for
me
very
instructive
and
good
to
see
that
actually
what
we
come
up
with
kind
of
aligns
pretty
well
with
also
what
you
are
planning
a
planning
to
do,
so
it
was
good
to
see
and
yeah.
If
you
want
to
stay
involved
in
this
group,
please
feel
free.
We
would
be
happy
to
see
you.
B
A
A
We
were
talking
a
lot
about
this
messaging
destination
and
what
should
go
in
there
and
how
it
should
look
like-
and
I
think,
two
weeks
ago
I
said
yeah
I'll-
be
looking
to
some
existing
messaging
systems
and
see
how
those
how
what
connection
parameters
they
have
and
how
they
could
be
categorized
in
what
we
currently
have
in
the
semantic
conventions,
and
I
came
up
with
the
document
that
I
linked
here
and
yeah.
We
can
quickly
go
through
that
to
just
get
an
idea
of
of
of
what
we
are
dealing
here
with.
A
So
what
I
did
here,
I
just
have
like
a
few
different
try
to
find
the
more
popular
systems,
and
I
I
I
try
to
see
okay,
what
do
you
need
to
kind
of
connect
to
those
cues
or
topics
or
what's
the
information
that
uniquely
identifies
like
a
a
cure
topic
connection
to
in
these
messaging
systems,
and
then
I
also
try
to
categorize
in
this
huge
topic
here.
A
So
I
think
currently
the
keyword
topic
that
would
go.
That's
just
a
string,
always
it
would
go
into
the
destination,
and
then
you
also
have
basically
this
this
connection
string.
That
has
all
the
information.
So
here
you
have
basically
the
namespace
name,
and
you
also
have
the
event
hub
name
in
here.
You
even
have
like
this
access
key
secret
in
here
that
is
probably
filtered
out
before
that
gets
put
into
the
message
url,
but
I
think
how
it
would
work
with
the
current
spec
for
event
hubs.
A
So
that's
for
event
hubs,
but
basically
what
you
need
to
unique
identifies
these
two
parts.
It's
a
namespace
name
and
it's
this
q
top
or
this
event
hub
name
as
we
call
it,
and
that
would
be
are
basically
two
strings
that
uniquely
identify
at
the
endpoint
for
kafka.
A
A
So
yeah,
apparently
for
kafka
like
the
current
model,
would
work
pretty
well
because
you
have
the
url
and
then
you
have
the
destination
and
both
parts
kind
of
fit
in
there
quite
nicely
for
trim
s.
It's
not
that
clear,
because
yeah
you
can
connect
to
you
can
use
jms
to
connect
to
many
different
messaging
systems.
A
You
have
this
connection
factory.
That's
basically
then
specific
to
the
system
you're
using,
but
what
you
always
have.
You
have
the
the
destination
that
is
either
q
or
topic
name,
so
you
can
populate.
You
can
populate
messaging,
the
destination
interim
as
always,
and
the
rest
depends
on
this
connection
factory.
A
You
always
also
have
a
server
with
the
url
that
you
connect
to,
and
then
you
have
your
exchange
and
routing
key
and
both
are
kind
of
part
of
the
destination.
So
you
need
more
or
less
both
to
kind
of
uniquely
identify
the
the
destination
of
a
message.
So
basically,
in
rapid
mq,
you
have
those
three,
those
three
parts.
A
G
But
this
is
only
on
producer
spence
right
on
consumer
spends.
It
will
be
different.
G
A
A
A
Pulsar
is
also
similar.
You
have
kind
of
a
server,
that's
a
url,
and
then
you
have
a
topic.
It's
basically
the
same
as
kafka,
except
here
I
think
puzzle.
You
can
only
always
specify
one
server
in
kafka.
You
can
specify
a
list
rocket
mq.
Also
the
same.
You
have
a
server,
that's
a
url
and
you
have
a
topic
that
would
go
into
destination.
A
Then
there
is
amazon,
sqs
and
sns
good
that
we
have
a
mirror
here.
He
can
correct
me
if
there's
anything
wrong,
but
there
is
basically
three
parts
that
you
need
to
connect
to.
Sqs
you
need
to
have
a
region,
you
need
an
account
number
and
then
you
have
a
queue
name
and
that
usually
is
all
embedded
in
a
url.
A
So
you
have
the
region
and
you
have
an
account
number
and
you
have
a
queue
name,
but
it's
yeah
these
three
parts
that
uniquely
identify
the
destination
similar
for
sns
there.
You
also
have
a
region
account
number
and
a
topic
name,
and
this
is
embedded
embedded
in
a
you
know
ar,
and
that
looks
like
this.
So
basically,
you
have
region
account
number
and
topic
name
and
that
uniquely
identifies
your
destination.
A
G
Think
for
sms,
it
doesn't
have
to
be
a
topic
like
you
can
write
like
a
phone
number
or
other
terms
of
publishing
a
message,
and
I
remember
when
I
wrote
the
instrumentation.
It
was
a
bit
confusing
because
I
write
something
which
is
not
a
topic
and
I
have
to
set
the
destination
kind
to
topic,
which
is
not
the
best
experience,
but
I'm
not
sure
what
we
can
do
with
it.
A
G
So
in
sns,
I
think
you
can
send
notifications
to
a
lot
of
things.
For
example,
phone
numbers.
You
can
write
like
a
phone
number
and
then
publish
to
sns,
and
it
will,
I
guess,
send
an
sms
to
a
phone
number
and
then
the
destination
is
the
phone
number
write.
The
phone
number
in
the
destination,
but
kind
is
required,
but
it
can
only
be
topic
or
a
queue
and
it
doesn't
feel
right
because
you
have
to
write
the
topic,
but
it's
not
really
a
topic
right.
F
F
G
A
That's
interesting,
but
but
I
think
it
doesn't
really
matter
much
how
we
call
it
here,
but
it's
a
topic
name
or
if
it's
another
like
identifier,
but
it's
I
think
important,
that
there
are
three
parts
here
that
you
need
to
connect,
and
I
mean
even
if
this
is
a
phone
number,
it
basically
plays
more
or
less
the
role
of
of
of
a
topic.
From
the
messaging
point
of
view,
I
mean
it's,
it's
it's
interesting.
It's
not
really
a
topic,
because
a
phone
number
is
already
a
unique
consumer.
A
A
F
G
But
also
for
a
rabbit
like
when
you
produce
a
message
to
an
exchange
like
the
destination
kind
must
be
queue
or
topic,
but
both
are
not
correct,
because
you're
not
there
publishing
to
a
queue,
you're
publishing
to
an
exchange
which
is
sorry
to
it's
like
it's,
not
the
topic.
What
what
the
value
in
the
destination
right?
It
has
a
different
mechanism
to
distribute
messages.
A
Yes,
it
has
a
different,
actually
pretty
confusing
mechanism
to
distribute
the
messages.
So
so
so
I
think
rabbitmq
it
comes
up
again
and
again,
but
I
think
we
should
try
not
to
get
too
hung
up
on
it,
because
if
we
look
at
all
the
other
ones,
rapid
mq
is
actually
a
pretty
much
an
exception
in
in
how
they
do
things.
So
I
I
think
we
should.
We
should
not
try
to
get
too
hung
up
on
how
rabbit
and
q
does
things,
but
it's
still
good
to
point
it
out
and
trust.
A
D
D
And
then
there
is
even
more
dyno
tv
streams.
It's
like
any
updates
going
into
the
dynodb
table.
It
becomes
as
a
stream.
All
the
updates
could
become
as
a
stream.
B
A
A
Basically,
those
are
the
two
pieces
that
you
need
and
that
is
all
embedded
in
a
resource
name
that
basically
projects,
and
then
you
have
a
project
name
and
then
topics.
And
then
here
you
have
a
topic
name.
So
it's
basically,
those
two
are
the
variables
that
are
in
this
resource
name
and
that
uniquely
identified
the
the
destination.
A
Let
me
see
where
I
find
the
original
semantic
conventions
here
come
up
with
like
destination
and
then
url,
because
for
many
cases
that
actually
fits
pretty
well,
because
you
have
a
server,
that's
a
url,
and
then
you
have
like
either
a
queue
topic
or
subject.
However,
it
calls
it
and
that
goes
into
the
destination
and
then,
with
those
two
parts,
you
kind
of
uniquely
identify
your
uniquely
identify
the
the
destination,
and
I
mean
that
works
very
nice.
A
Actually,
for
kafka
for
nets
for
pulsar
for
rocket
mq,
maybe
for
my
nitromes
use
cases,
it
kind
of
gets
a
bit
more
complicated
for
those
hosted
offers
like
event,
hubs
sqs,
sns
and
google
pops
up,
because
there
you
kind
of
more
or
less
have
these
these
these
identifiers
that
are
not
really
kind
of
part
of
a
url.
A
A
I
mean
what
is
kind
of
common
to
all
of
them.
There's
always
something
that
is
either
like
a
keyword
topic.
I
mean
that
is
there
in
all.
A
In
other
cases
I
have
seen-
and
I
think
that
is
what
the
original
idea
was
to
just
put
into
destination-
it's
basically
either
this
queue
topic
or
subject
name,
and
I
think
the
original
idea
was
to
have
this.
Basically,
that
is
common
to
all
systems.
That's
why
it's
a
required
here
that
you
put
into
the
destination
and
then
the
url.
Basically
you
put
into
messaging
url.
A
If
you
have
it
and
if
you
need
any
kind
of
other
information,
then
that's
basically
messaging
system
specific
and
you
put
it
like
in
there
I
mean
the
downside
of
that
is
that
when
looking
generically
at
those
attributes-
and
you
don't
know
which
messaging
system
it
is,
you
cannot
really
say
how
you
how
to
uniquely
identify
the
destination,
because
for
some
for
some
you
might
need
a
url
for
others.
Maybe
there
is
specific
mechanism
and
you
don't
need
the
url
or
the
rabbit
in
queue
again,
it's
special.
A
So
I
think
here
the
question
for
us
to
answer
is:
do
we
want
to
have
this
unique
way
across
all
messaging
systems,
to
uniquely
identify
the
destination
or
or
do
we
kind
of
keep
up
with
the
current
solution
where
this
is
kind
of
that
is
quite
ambiguous
and
where
you
only
have
like
messaging
system
specific
way
to
uniquely
identify
this
destination?
A
Because
here,
if
we
say-
and
we
already
already
had
this
discussion-
if
you
say
okay,
we
want
to
have
a
way
independent
of
the
messaging
system.
You
need
to
identify
the
destination,
then
we
probably
have
to
come
up
with
some
like
additional
rules
of
how
to
pack
all
this
information
in
one
two
or
maybe
three
attributes
that
is
consistent
across
all
messaging
systems.
A
And
I
will
also
like
run
this
by
luke
miller
she's,
not
here
today,
but
I
know
she
has
kind
of
some
strong
opinions
on
that
and
yeah
get
her
get
her
input
on.
That
would
just
be
interested
on
your
on
your
take
on
this
I
mean
I
will
also
I
will
try
to
find
info
or
some
on
the
remaining
amazon
systems,
and
then
I
will
put.
I
will
put
this
like
as
a
comment
in
the
pr,
so
we
have
it
there
and
then
we
don't
have
it
floating
around.
A
C
I
also
just
wonder
if
we
should
also
consider
amqp
and
mqtt
as
well
in
in
this
list.
G
C
A
Yeah,
I
will
try
to
have
that
in
the
basic
in
the
pr
in
a
comment
until
next
week
and
then
maybe
also
get
some
some
input
from
luke
miller.
But
at
least
it
should
give
us
some
like
how
to
say
raw
data
to
work
with
and
to
come
up
with
like
examples.
How
might
it
look
if
we
pack
that,
in
different
ways
into
the
attributes
that
we
that
we
have
now.
F
I
know
I
think
this
is
this
looks
very
good.
It's
too
many
too
many
too
many
types
of
messaging
system
that
it's
good
to
have
like.
You
did
like
right
now,
but
you
have
this
overview,
so
I
think
this
helps
a
lot.
F
A
We
looked
at
it
and
it
didn't
really
make
sense
to
us,
but
surprisingly
yeah,
that
kind
of
that
kind
of
fits
the
bill
for
many
systems,
because
here
you
have
the
to
have
you
have
a
url
and
then
you
have
like
a
destination
that
you
use
and
you
just
then
basically
can
uniquely
identify
the
destination
by
basically
using
the
url
and
the
destination
in
kind
of
connection,
and
I
think
that
yeah
works
for
probably
most
of
the
cases
when
you
use
this
combination
of
messaging
and
url.
A
A
Yes,
I
I
do
agree
with
that
sentiment.
I
mean
it
would
and
we
started
to
go
down
that
path
anyway,
by
having
basically
the
destination
dot
attributes.
I
think
that's
definitely
a
way
we
should
go,
but
then
you
could
have
destination.name
and
you
could
have
destination.url
and
then,
in
that
way,
kind
of
your
unique,
uniquely
identify
the
destination,
and
I
mean
other
messaging.
Specific
extensions
could
exist
that,
for
example,
you
had
you
could
have
you
could
have
then.
A
For
let's
I
mean
let's
take
event
hubs,
because
this
will
know
something
about
you
could
have
like
destination,
but
name
that
fits
very
well
with
event
name
and
then
you
could
have
a
destination.namespace
for
event
hubs,
and
then
you
have
kind
of
those
two,
but
then
again
it's
kind
of
yeah.
Then
you
need
to
know
the
system
beforehand
to
know
which
kind
of
attributes
you
need
to
combine
to
get
like
the
specific,
the
the
unique
destination
name.
A
So
I
think
that
is
that
is,
I
think,
the
question
we
need
to
answer
on
how
to
go
forward.
Do
we
want
to
know
the
unique
destination
independent
of
the
system,
or
is
it
okay
that
we
that
we
basically
can
determine
the
unique
destination,
but
in
a
system
specific
way?
A
F
Yeah
like
with
that,
what
would
I
think,
like
thinking
what
what
you
said
it's
if,
if
we
have
this,
for
example,
event
hops,
there's
this
three
pieces
of
information
and
for
another
system
there's,
I
don't
know
four
other
pieces
of
information
that
can
combine
to
be
the
unique
identifier,
but
not
not
sure
if
you
should
think
as
a
spec
of
of
coming
up
with
this.
But,
for
example,
if.
C
F
Am
a
user
of
event
hubs
and
I
have
all
these
attributes
separate.
I
know
how
to
sum
up
them
together
to
to
come
up
with
the,
and
I
think
that's
that's
enough-
pretty
much
because
or
for
back
ends.
For
example,
they
want
to
have
some
special
handling
for
each
thing:
they
they
will,
they
will
construct
this.
F
They
know
how
to
do
it
and
but
for
us
as
a
spec,
I
think
just
having
the
information
properly
structured,
it's
probably
enough,
and
then
users
want
to
come
up
with
how,
because,
if
I
use
event
hubs,
I
know
that
I
have
to
come
up
with
this
connection
string
with
these
pieces
here
in
there
to
to
construct
the
uniquely
identifiable,
url
or
destination
right.
So.
A
A
You
need
to
identify
it,
but
actually,
when
I
am
an
eventhub
user
and
I
look
at
the
span
when
I
see
destination.name
and
destination.namespace,
it's
kind
of
very
clear
for
me
what
is
going
on
here,
whereas
when
I
see
like
one
destination
that
is
kind
of
an
array
with
two
elements
and
also
two
strings,
it's
not
really
very
clear
for
me
about
those
what's
the
semantic
of
those
attributes,
but
here
we
are.
A
We
are
kind
of
over
time
today,
so
yeah
for
until
next
week
I
will
try
to
or
actually
before
our
next
meeting.
A
I
will
try
to
work
on
that
this
week
to
get
that
into
pr
comment,
and
then
maybe
we
can
try
have
to
have
some
offline
discussions
on
the
pr
and
and
then
continue
discussing
this
next
week,
based
on
the
on
the
list
of
systems,
and
we
see,
we
can
then
see
what
what
works
best
and
I
I
will
also
try
to
catch
on
responding
to
comments
on
the
pr,
because
there
is
still
some
lots
of
open
comments
that
I
need
to
know.
A
Unfortunately,
not
I,
I
think
some
people
from
the
tc
they
currently
it
seems
there
is
not
very
much
urgency
regarding
this
messaging
or
semantic
convention.
Work
in
general.
There's
lots
of
other
things
that
have
high
priority,
but
yeah.
I
will
keep
keep
pinging
people
and
asking
them.
I
mean
I
don't
know
how.
A
Maybe
you
can
ask
armin
sure,
but
he
can
look
over
it
and
the
proof
I
mean
I
I
pinged
him
already
and
he
said
yeah
well,
we'll
look
over
it,
but
it
it
might
be
good
to
just
have
his
like
comments.
F
I
think
I
already
approved
it
but
yeah,
but
I
guess
but
but
I
will
ask
him:
maybe
maybe
I'll
bring
it
up
in
the
next
pc
because
I
joined
the
tc
this
week,
but
I
probably
will
join
next
week.
Then
I
can
bring
it
up
again.
C
I'll
be
away
I'll
be
away
next
week.
I
may
not
have
time
to
review
the
pr
but
I'll
try
to
when
I
get
back
the
following
week,.
A
Awesome
thanks,
dwayne
and
and
by
the
way
I
will
be
away
for
one
and
a
half
weeks
over
the
summer,
so
I
will
be
off
from
mid
july,
starting
july
19th
to
end
of
august,
so
I
think
we
maybe
can
discuss
in
one
of
the
next
sessions.
If
there's,
then
somebody
else
who
wants
to
lead
the
discussions
forward
or
whether
we
want
to
pause
or
together,
I
think
we
can.
We
can
discuss
them
and
decide.