►
From YouTube: 2021-08-26 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).
C
D
C
E
B
Let's
start
with
the
late
breaking
news,
so
the
good
thing
is
we
released
one
five
well
and
then
we
had
a
not
a.
B
B
It
looks
like
we
introduced
a
memory
leak
in
one
five,
if
there's
no
metrics
exporter,
because
we
are
now
capturing
a
lot
of
metrics
and
we're
also
capturing
them
with
a
lot
of
dimensions
and
I'm
not
quite
yeah.
F
D
F
B
F
Did
you
just
get
knocked
off
your
chair
by
that,
seeing
that
there.
F
Yeah,
I
think
this
is
definitely
a
problem
with
the
instrumentation
I
mean
yeah
again.
We
we
need
to
fix
the
issue
in
the
poor
sdk
as
well,
but
I
don't
know
which
is
for
they're,
both
bad
they're,
both
two
both
bad
problems.
B
B
I
had
a
question
if
you
know
where,
because
in
okay
request
metrics,
oh,
where
am
I
looking
at
http?
Maybe
if.
F
F
Question
right
now
we
don't
have
this
capability
in
views,
so
it
has
to
be
an
instrumentation.
F
F
B
F
B
Yeah,
if
I
recall
there
was
a
list
somewhere
of
the
metrics.
B
So
I
thought
that
previously,
I
feel
like
something
might
have
changed
in
one
five,
because
we
were
capturing
a
few
metrics
in
one
four,
but
I
think
it
was.
I
think
we
were
passing
specific
met,
attribute
list.
G
B
Okay,
cool
that
doesn't
sound
too
hard
to
add
back
in
some
filtering
of
those
specific
pulling.
D
B
These
specific
attributes
so
hang
pipe
for
152
coming
soon.
F
F
Or
or
maybe
highlight
some
additional
methods
we
might
want
to
put
on
the
attribute
api,
it's
like
a
filter
or
we
like
there's
a,
I
know,
there's
an
outstanding
issue.
I
did
a
big
issue
scrub
in
java
yesterday
to
provide
a
remove
method
on
attributes
or
on
attributes.
Builder.
Sorry,
on
address
builder,
which,
if
we
had
that,
then
you
could
easily
go
and
remove
items.
F
From
an
attribute,
so
you
could
say
attributes
to
builder
and
then
remove
remove,
remove
or
whatever
I
don't
know
whether
we're
going
to
want
to
have
an
allow
list
or
a
deny
list
on
these
attributes.
Allow
list
so
we'll
need
it
might
be
nice
to
have
an
api
on
attributes.
That
would
let
you
like
get
the
builder
and
then,
like
just
say,
only
keep
these
keys
or
something
I
don't
know
exactly
what
that
api
would
look
like,
but
it
definitely
seems
like
that.
H
You
could
add
a,
I
came
across
the
same
issue
and
it
was,
it
was
unwieldy
to
you
know,
filter
out
attributes
and
you
could
add,
like
a
remove.
If
that
accepts
a
predicate.
F
F
H
B
But
I
I
think
we
want
allow
list
yeah,
yeah.
F
B
F
Way,
we
don't
really
have
an
api
to
make
this
easy
at
the
moment
we
have
to
do
like
you
have
to
iterate
over
them,
create
a
new
builder
iterate
over
the
existing
ones
and
just
keep
them
only
retain
the
ones
you
want,
or
something
like
that.
So
we
don't
have
it,
but
this
use
case
will
probably
inform
a
new
api
on
the
builder,
so.
F
Yeah
this
actually,
the
prometheus
use
case
makes
me
wonder
how,
like
it's
actually
really
it's
kind
of
really
good
that
this
was
discovered,
because
it
is
definitely
an
instrumentation
issue.
Memory
link
is
bad.
I'm
just
think
trying
to
think
in
my
head
how
we
would,
I
suppose,
thinking
somewhere
else,
how
we
would
solve
this
problem.
If
you
did
have
a
prometheus
exporter
and
nothing
ever
scraped
it,
we
need
to
have
infinite
cardinality.
F
F
I
don't
know
we
might
need
some
sort
of
circuit
breaker
in
the
sdk
that
like
looks
at
the
size
of
the
attribute,
the
growing
attribute
keys
in
the
map
that
this
is
stored
in
and
if
it
gets
to
gets
beyond
some
arbitrary
size,
maybe
configurable
that
we
just
stopped
collecting
metrics
anyway.
I'd
like
yeah
josh's
josh's
opinion
would
be
super
useful
here.
H
I
kind
of
had
a
thought
out
of
left
field
about
this,
and
maybe
this
has
been
discussed
before,
but
prometheus
is
the
only
pole
based
exporter
and
is
that
is
it
really
does
it
really
need
to
be
the
only
pull-based
exporter
or
or
yeah
pole-based
exporter?
Could
you
instead,
you
know,
have
it
operate
as
a
push-based
exporter,
where
you
know
the
the
metrics
sdk
pushes
like
the
state
of
metrics
to
some
other
state
representation
that
the
prometheus
exporter
exposes.
You
should
jack.
You
should.
F
F
Well,
I
mean
the
underlying
prometheus
implementation
would
be
pulling
but
yeah
if
it
pushes
to
something
that
stores
the
state.
I
mean
you
can
remote
right
and
prometheus.
That's
one
method
of
push.
Now
I
think
jack
is
saying
that
internally
we
implemented
a
push
exporter
that
pushes
to
the
understand
gotcha.
F
Well,
you
can't
override
it
because,
with
the
timing
of
when
prometheus
pulls
it,
who
knows
what
that
is,
you
can't
like
destroy
if
prometheus
is
pulling
once
a
minute
and
you're
writing
every
five
seconds.
You
can't
destroy
that
state
for
the
the
scraper
right.
F
Yeah,
that's
what
I'm
saying
that's
what
I
was
saying
is.
I
think
we
need
to
probably
put
a
circuit
breaker
in
there
that
will
drop
data
period
if
the
cardinality
gets
too
high,
it
will
stop
collecting
for
higher
for
high
technology
or
maybe
just
turn
off
that
instrument
altogether
or
something,
but
anyway,
this
is
where
it
would
be
great
to
get
some
more
opinions
like
and
josh,
especially,
is
the
primary
implementer
on
this
stuff.
B
All
right,
hey.
B
A
good
way
to
get
feedback
is
I
introduce
a
memory
problem.
I
But
should
we
add
some
sort
of
notice
that
one
five
releases
program.
F
It's
not
going
to
be
broken
for
everybody
right.
It's
only
for
if
you're,
using
client
instrumentation
like
http
client
instrumentation
is
that
right,
which
is
I
mean,
which
is
probably
a
lot
of
people.
I'm
not
saying
that's,
that's
good,
but
there
are
use
cases
where
you
would
be
okay,
if
you're
a
kafka
consumer,
for
example,
probably
not
be
a
problem.
B
All
right,
this
is
our
favorite
topic.
Well,
one
of
the
ongoing
favorite
topics
of
messaging
semantic
convention
interpretation,
and
so
this
is
a
material
implemented
batch
receiving.
B
I
G
Nothing
like
nothing,
describes
a
scenario
like
that
in
the
spec,
so
I
have
I
had
to
be
somewhat
creative
and
I
thought
that
the
batch
processing
scenario
actually
suits
that
situation
and
a
bit
better
because
the
listener
I
mean
the
custom
user
listener,
called
whatever
it
does.
It's
still
in
closing
the
whole
batch
processing
spam
batch
process
spam
and
the
receive
message
messages
are
just
there
for
you
know
for
linking
the
trades
together
with
the
producer
spam
but
yeah.
G
To
be
honest,
it's
just
like,
as
I
wrote
in
my
comment,
it
probably
would
makes
more
sense
from
a
semantic
point
of
view,
to
have
a
single
research
span,
because
you
like
that
there's
it
is
actually
a
single,
receive
operation
and
have
also
a
single
process
spam
that
links
all
those
producers
together,
but
yeah.
It's
not
inspect
right
now,.
G
A
G
That
was
what
nikita
was
proposing
in
his
issue
when
I
think
there,
or
something
very
similar
to
that
at
least.
B
G
B
Cool
any
anybody
else
have
messaging
semantic
convention,
thoughts
or
woes.
Oh
ken.
B
What
do
you
yeah?
What
do
you,
I
know
you've
thought
actually
a
good
amount
about
the
messaging
semantic
conventions.
What's
what's
your
thoughts
for
this
specific
example,.
B
So
the
batch
receiving
this
is
so
spring
kafka.
It
receives
a
batch
of
messages
and
processes
that
batch
all
altogether.
C
I
guess
the
question
would
be
is
actually
receiving
them,
or
is
it
just
like
getting
a
back
batch
of
messages
from
kafka
and
then
processing
them
one
at
a
time,
because
that's
what
we
do
with
clarkus
and
I
treat
that
as
not
much
but
separate
because
you're,
although
you
kind
of
batch
pull
topic
messages
from
kafka,
if
you
fail
or
cease
at
any
point,
then
that
whatever
was
polled
still
gets
picked
up
by
other
consumers.
C
G
But
in
the
case
of
spring
batch
it
just
it
just
hands
the
user,
a
list
of
all
those
records.
So
it's
oh
okay,
actual
processing
project
to
the
user.
So
the
instrumentation
point
of
view
is
just
batch
processing.
You
give
the
user
a
collection,
and
that's
all
that
you
know.
A
B
B
Cool,
maybe
we
can
link,
did
that
was
that
sort
of
does
this
issue
nikita
already
talk
about
that
a
little
bit
or
should
we.
B
B
Cool
yeah
yeah
just
I
think
that
would
be
a
good
way
to
hopefully
make
sure
that
they
get
some
clarity.
There.
B
F
F
B
F
F
B
Okay,
so
we
run
it,
we've
been
trying
to
enable
this
in
the
instrumentation
repo
in
our
tests
to
make
sure
that
our
tests
aren't
leaking
context
and
we've
been
running
into
kind
of
some
sporadic
test
failures
that
it
causes,
for
example,
with
async
servlets,
where
we
have
a
scope.
B
That
is,
the
async
callback
is
doing
some
work,
and
so
we
have
a
scope
open
and
we
complete
the
async
context,
which
then
fleshes
the
response
back
to
the
client
and
so
under
load,
which
we
have
some
tests,
which
do
kind
of
heavy
concurrency.
To
make
sure
that
we
aren't
getting
context
things
mixed
up
during
under
concurrency.
B
We've
seen
we
can
see
the
client
getting
the
response
back
before
the
server
scope
is
closed,
and
so
then
this
context
check
sporadically
fails.
So
there
were
a
couple
of
laurie
has
done
most
of
the
work
here
and
kind
of
proposed
a
couple
different
options,
one
maybe
lori.
If
you
want
to
describe
sort
of
the
options
here.
I
I
think
the
easiest
option
would
be
if
the
check.
Basically,
if
it
followed
the
leaked
context,
then
it
would
retry
like
sleep
a
bit
and
retry
and
if
the
leaked
context
doesn't
go
away
after
some
like
10
seconds,
then
then
it
probably
really
leaked.
I
I
Perhaps
because
all
tests
are
basically
a
load
generator,
it
fails
easier
in
the
ci,
but
it
almost
like
never
fails
when
you
just
run
a
single
test,
so
the
only
way
to
reproduce
is
to
basically
place
some
breakpoints
in
some
clever
way.
I
I
tried
to
make
it
a
bit
more
reproducible
by
adding
a
sleep
before
the
scope
close
with
this.
I
can
make
some
tests
reliably
fail,
but
with
some
other
tests
it
seems
that,
if
I
add
sleep
to
like
sleep
before
all
the
scope
closes,
then
it
kind
of
costs
itself
out.
B
Yeah
I
do
like
this,
so
the
we
had
we've
tried
a
couple.
Other
solutions
like
waiting
having
the
tests
wait
to
clean
up
until
after
checking
like
the
doing
a
thread
dump
checking
if
there's
certain
stack
element,
certain
classes
still
being
called
such
as
these
async
context.
Runnables.
B
Cool
so
we'll
follow
up
john
we'll
follow
up
with
honorag,
but
this
would
be
something
that
we
would
need
to
put
into
the
sdk
update.
The
context
check,
I
think
lori
is:
is
that
correct,
or
can
we
do?
Can
we
do
this
as
a
consumer
user
of
the
strict
context
check.
F
I
mean
the
the.
If
you
take
a
look,
I
don't
know
if
you
want
to
just
jump
over
to
java
and
take
a
look
at
the
strict
context-
storage
implementation,
it's
just
code
so
of
it.
So
it's
obviously
possible
to
copy
this
code
over
and
hack
on
it.
It's
just
good,
but
you
can
see
down
on
line
68.
We
capture.
We
are
capturing
the
stack
trace
for
every
every
time.
The
context
gets
attached
at
the
moment.
F
This
definitely
works
by
you,
looking
like
doing
garbage
collecting
on
like
looking
for
garbage,
collect
collection
or
things
that
get
respected
without
having
to
be
closed.
F
F
F
F
B
So
that
this
might
be
a
good
first
step,
at
least
to
help
us
validate
that
it
works.
The
approach
works.
J
I
I
was
just
looking
at
the
metrics
exporter
and
taking
a
look
at
it.
So
basically,
what
sucks
here
is?
You
can
only
fix
this
in
autocomp.
The
way
honorable
proposes,
hopefully
the
new
sdk
specification.
J
I
onorag's
fix
for
that
leak
is,
is
fine
for
autoconf,
it's
still
possible
that
users
can
do
this
to
themselves
if
they
instantiate
the
sdk
with
no
actual
pull-based
exporter
or
if
their
pool
base
exporter's
pool
cycle.
F
Is
too
long
or
if
it's
just
nothing,
nothing
like
nothing
scrapes
from
meteos?
My
idea,
josh
was
that
we
could
in
that
code
that
in
the
the
metrics
storage,
wherever
the
issue
is,
is
we
could
detect
the
size
of
that
map
and
if
it
gets
too
big,
we
could
stop.
We
could
turn
off
that
instrument.
F
J
Yeah
I
like
that,
so
that,
unfortunately,
that
code
is
really
super
gross
right
now.
I
think
I
think
that's
instrument,
processor,
so
yeah,
that's
actually
a
good
idea
too.
We
can.
If
an
instrument
processor
grows
too
large,
we
could
actually
impose
a
hard
limit,
config
parameter.
J
F
J
Yes,
yes,
that
is
again
okay,
to
the
extent
that
synchronous
message,
storage
is
just
the
instrument,
processor,
sure
sure
sure
yeah.
J
I
B
Josh,
it's
definitely.
The
bigger
problem
is
the
instrumentation
side
that
we're
we're
putting
in
the
full
all
the
span
attributes
current
right
now,
which
includes
http
url.
J
My
hope
is
that
you
give
us
every
freaking
thing,
because
in
in
the
far
distant
future,
when,
when
you
know,
we've
we've
achieved
world
peace
and
covet
is
destroyed
and
we
have
a
full
metric
metric
back
ends
won't
have
an
issue
with
cardinality.
J
In
the
meantime,
the
reason
we
expose
views
and
I'd
love
it
if
this
were
a
default
view
is
so
that
when
you
instrument
you
provide
rich
retro
signals
and
then
we
can
actually
have
a
default
view
like
ideally
and
again,
this
the
spec
sig
isn't
quite
here
yet,
but
you
should
have
a
default
view
in
addition
to
your
instrumentation.
That
says
here
is
the
set
of
attributes
we
think
are
actually
useful,
but
they're
all
there.
J
So
if
the
user
overrides
that
default
view,
they
can,
they
can
get
access
at
the
other
labels
that
you've
used,
but
by
default
we'll
aggregate
a
bunch
of
way.
This
is
the
this
is
the
goal
of
the
hint
the
hint
api
that
hasn't
been
done,
yeah
yeah.
So
I
guess
the
real
question
is
what
practically,
because
this
is
currently
an
issue.
What
do
we
do
right
now
in
java
instrumentation?
F
I
don't
know
if
you
have
a,
I
mean
we
have.
We
have
to
put
out
a
patch
right
now,
so
I
think
filtering
filtering
it
in
the
instrumentation
level.
Is
the
simplest
patch
for
right
now
and
meanwhile,
when
we
as
we
build
out
views
because
we
don't
even
have
the
ability
in
views
right
now
to
limit
attributes
right
yeah
we
do
do
we.
F
J
B
Yeah
and
it's
a
pretty
centralized
spot,
I
don't
think
it's
a
it's
just
here
where
we're
taking
all
the
all
the
span
attributes
and
we're
just
shoving
them
over
into
the
metrics.
So
we
can
filter
that
down
for
now,
another.
B
B
Yeah
I
was
just
assuming
that
we
would
filter
it
for
now
and
then,
as
soon
as
the
the
sdk
views
default
views
are
in
place,
then
we
would
remove
that
filtering.
J
B
And
I
think,
that's
probably
what
honorable
thinking
of
that
that,
as
far
as
passing,
everything
on
so
all
right,
cool.
H
J
Yeah,
I
have
a
pen
in
pr
for
that.
I
don't
I
don't
know
if
you've
looked
at
the
metrics
sdk
to
do
tasks.
Oh
sorry,
about
that
sorry,
I
have
a
pending
branch
for
that.
So
right
now,
if
you
look
at,
if
you
look
under
issues,
you
can
see
there's
a
sdk
prototype
issue,
yep
yeah,
so
update
metrics
to
latest
specification.
J
Processor
yeah
yeah
re-workly,
so
it's
not
just
that
it
has
to
be
renamed.
The
label
processor
doesn't
allow
access
to
baggage,
and
so
we
we
have
to
actually
rename
it
and
rework
it.
At
the
same
time.
There's
a
there's
a
component
of
this,
where,
if
you
have
a
label
processor
that
touch
touches
baggage,
it
breaks
bound
instruments.
Today,
it's
actually
completely
broken,
so
that
needs
to
get
fixed.
I
have
all
the
code
written
it's
on
a
branch.
I
just
need
to
work
it
in
right
now.
J
What
I'm
doing
is
the
moving
the
aggregator
package
to
internal.
I
have
a
pr,
that's
almost
done
that
hides
aggregator
from
the
public
api
and
just
exposes
what
the
sdk
has
specified
as
the
config
parameters,
so
that
that's
going
to
hit
first
and
then
the
labels,
processors,
probably
next
and
then
error
messages
are
probably
the
last
thing
to
to
go.
Get
cleaned
up.
So,
unfortunately,
there's
a
a
lot
of
this
is
kind
of
all
tangled
together,
such
that
it's
serial
work
instead
of
parallel.
H
J
B
Quick
update,
it's
been
making
we're,
making
some
good
continued
progress
on
the
instrument
or
api
conversion.
Look
at
that
over
halfway
done.
Thank
you,
laurie
for
a
bunch
of
these
in
the
last
recently,
it's
still
a
great
place
if
you're
interested
in
writing,
making
some
prs
learning
the
all
the
instrumentation
guts,
picking
up
something
here,
hey
lowry,
are
you
gonna
pick
up
servlet
next.
B
Well,
no,
because
yeah
I
mean
we
talked
about
this,
you
already,
you
already
got
your
name
here.
Well
yeah.
I
picked
up
jetty
and
not
realizing
just
how
far
ingrained
into
servlet.
It
is.
F
B
B
And
jetty
was
not
it
do
we
does
it
make
sense
to
do
servlet
first.
Do
you
think.
B
Well,
honest,
honestly,
you
could
take
my
name
off
jetty
sure
yeah.
I
would
I
would
recommend,
like
you
know,
one
of
the
other.
Oh
this,
here's
a
good
here's,
a
good
one.
C
J
B
We
do
have,
we
do
have
some
something
under
the
executor.
B
D
D
J
The
when
I
was
on
the
standard
committee
for
the
scala
library
back
in
the
day,
I'll
tell
you
over
a
beer
how
they
cut
the
ability
for
tracing
to
work
with
futures.
E
Cool
is
it
possible
to
elaborate
like
really
shortly,
for
the
new
guys
like
what
is
the?
What
is
this
conversion
from
the
instrumentation
to
the
instrumentation
to
the
new
instrumenter?
Okay,.
B
Yeah
so
there's
I'd,
say,
there's
kind
of
two,
so
this
is
the
api
that
our
instrumentation
primarily
uses.
We
used
to
call
these
things
called
tracers.
This
tracer
object,
which
would
encompass
a
bunch
of
the
instrumentation
logic
and
then
so.
B
The
hooks
the
bytecode
instrumentation
hooks
like
before
and
after
calls
would
delegate
a
lot
of
the
work
to
these
like
tracer
or
apache,
http,
client,
tracer,
and
so,
but
as
we
go
forward
and
do
metrics
also,
we
realize
that
tracer
is
for
one
thing,
not
the
right
name,
because
we
want
to
call
from
the
bytecode
instrumentation
hooks.
B
We
want
to
call
hey,
there's
an
instrumenter,
I
call
start
and
I
call
end
and
the
instrumenter
is
responsible
for
both
creating
the
span
and
creating
the
metrics,
since
a
lot
of
the
things
are
shared
between
those
attributes,
timings
and
so
in.
That
was
maybe
the
primary
motivation,
but
also
the
we
wanted
to
and
did
rework
a
lot
of
how
simplifying
the
api
down
to
the
instrumenter
is
kind
of.
Has
three
primary
methods.
B
Should
I
start
a
span,
or
should
I
start
start
and
end,
and
so,
whereas
our
old
tracers
had
a
lot
of
different
varying
methods
in
them,
so
it's
sort
of
consolidating
that
down
and
simplifying
it.
So
it's
certainly
a
converting
them
is
more
involved
than
just
like
renaming
to
instrument
from
tracer
to
instrumenter.
It's
kind
of
a
whole
new
api
that
honorable
and
matej,
designed
and
drove
so
and.
B
Some
of
the
existing
instrumentation,
like
I
mean
we
were
joking
about
that
jetty,
servlet
tracer,
if
you,
if,
if
you
just
look
at
that
thing
and
try
and
dive
through
the
class
hierarchy,
I
think
you'll
understand
pretty
quickly
why
we
want
to
make
this
change
because
it's
it's
gnarly
and
there
are
calls
that
go
down
that
come
back
up
that
go
back
down
and
it's
really
hard
to
follow.
So
the
new
api
is
much
more
modular,
very.
G
G
E
Yeah,
so
basic,
so
basically
it's
just
transferring
those
implementation
to
implement
a
new
interface
like
the
instrumenter
and
then
try
to
adapt
the
behavior
to
fit
that.
I
guess.
B
Yep
and
the
great
thing
is
the
tests?
Don't
change,
so
you
can
basically
verify
that
you've
done
everything
right
through
the
tests,
so
they're
all
sort.
E
B
Yeah,
so
this
link
here
this
will
take
you
over
to
this
issue
right
and
anybody
who
want
anybody
new
who
wants
to
pick
up
one
of
these
ping
ping
us
on
slack
either
dm
or
on
the
slack
channel,
ask
for
a
recommendation
on
and
we
can.
B
Yeah
yeah,
we
would
love
help
there's,
as
you
can
see,
there's
a
lot
of
we've
been
doing
this
for
a
couple
months
now
and
we're
about
halfway
through
so
still
a
ways
to
go,
and
this
is
the
this
is
on
the
critical
path
to
declaring
our
the
instrument
or
api
stable,
which
will
be
amazing.
B
B
Oh
yes,
I
wanted
to
call
out
these
two.
This
is
a
this
bridging
the
span
keys.
This
was
a
something
a
long
time
coming
so
great,
now,
a
much
better
story
between
manual
library,
instrumentation
and
agent,
auto
instrumentation,
interrupt
and
dropping
well,
and
then
this
one
I
wanted
to
call
out
because
it's
absolute
pure
magic
glory.
B
I
I
kept.
I
can't
believe
I
hadn't
seen
this
before.
I
totally
have
needed
this
before
it.
Basically
in
our
agent
now
we
instrument
the
reflection,
apis
and
there's
some
internal
reflection,
hooks
that
allow
you
to
filter
out
your
fields
so
because
we
inject
our
own
fields
into
classes
that
was
causing
problems
with
some
very
reflective
libraries
that
want
to
do
things
with
all
of
those
fields,
and
so
we're
now
able
to
hide
those
from
that
type
of
library,
which
is
really
amazing.
B
It's
like
reflection
within
reflection
within
reflection.
What
was
this
causing
problems
with
I've
seen
it
cause
problems
with
various
libraries
before
I've
had
to
I've
worked
around
this
issue
before
in
glory
for
specific
pieces,
but
never
had
this
general
approach,
cool
yeah.
B
And
yeah,
we
are
right
at
our
five
minute
cut
off
any
other
topics,
thoughts,
comments.
B
All
right
well
watch
out
for
152
release,
hopefully
try
to
get
that
out
tomorrow
and
have
a
good
one.