►
From YouTube: 2022 07 29 Git Cache Maintenance
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
B
Doing
good,
I
do
my
exams
so
yeah
before
we
get
started.
You
know,
let
you
know
that
next
week
I
wouldn't
be
able
to
attend
the
meeting.
Okay,
okay
and
then
the
next
meet
I
checked
is
on
10th
of
august.
We
can
schedule
that
again
to
a
friday,
so.
C
A
Okay,
so
let's,
let's
let
me
make
that
correction
that
way,
it'll
be
very
clear
to
all
of
us,
so
mond
or
tues.
Let's
see
wednesday
august
3rd,
we'll
cancel
right
because
that's
your
examinations,
okay,
so
deleting
that
one
exam
week
and
all
the
best
on
your
exams,
that's
that's
great
and
then
on
the
week
of
august
10.
It
would
be
better
if
we
made
it
august
12..
Is
that
correct,
yeah?
Okay?
So
I'm
going
to
move
that
to
august
12.
A
Okay,
so
schedule
has
been
adjusted,
then
the
the
next
week
that
week
of
august
17th
it's
okay
to
go
back
to
the
17th
to
the
wednesday
yeah,
okay,
great
all,
right,
excellent,
okay,
so
rishabh
welcome.
We
just
adjusted
schedules.
We
won't
meet
next
week
because
russia
cash
is
had
in
exams
next
week
and
the
following
week
we
will
meet
on
the
12th
of
august
instead
of
meeting
on
the
10th
of
august.
C
C
Hi
hi
congrats
on
your
presentation.
It
was
really
great.
C
B
That
was
absolutely
awesome
yeah.
I
did
you
know
myself
the
presentation.
You
know
the
demonstration.
B
A
If
you
have
not
failed
in
at
least
one
live
demonstration,
you've
clearly
not
done
enough
demonstrations,
that's
simply
the
nature
of
demonstrations
right,
it's
it.
If
you,
you
clearly
need
more,
you
need
to
do
more
demonstrations
if
you've
never
failed,
because
I
don't
know
anybody
who
will
tell
you.
Oh
yes,
my
demonstrations
always
work
unless
their
technique
for
demonstrations
is
because
I
always
record
them
on
video
before
and
I
make
sure
they
pass.
When
I
do
the
recorded
video,
it's
like
that's,
not
a
demonstration.
That's
totally
cheating.
A
B
I
wanted
to
discuss.
You
know
the
agenda
of
you
know:
phase
2
of
gsoc
like
what
are
we
going
to.
B
There
are
a
few
doubts
like
regarding
ui,
okay,
how
would
we
redefine
the
ui
to
make
it
user
friendly,
okay
and
then
yeah?
There
are
a
few
points
which
I
have
like,
which
we
can
discuss
the
first
being
regarding
the
caches
okay,
so
we
decided
to
display-
or
you
know,
data
regarding
how
the
you
know
how
frequently
the
maintenance
tasks
has
been
run
on
which
caches
have
been
known
in
a
table
format
right.
So
how
do
we
proceed
with
that?
That
is
one
thing,
and
the
other
thing
was
the
we
are
using.
B
Cash
entries,
okay,
we
don't
have
the
name
of
the
get
repository
which
we
are
running
on.
So
how
would
we
show
the
administrator
which
which
a
repository
is
taking,
how
much
space
and
how
much
execution.
A
So
so
the
administrator
only
knows
the
repository.
If
they
know
about
it
at
all,
they
only
know
it
by
its
cash
directory
name
right
so
to
the
administrator.
They
don't
know
which
repository
it.
It
is
a
cache,
it
is
caching,
and
so
it
seems
like
to
the
administrator.
We
need
to
show
the
cache
directory
name,
but
if
we
could
using
a
get
call
or
a
j,
get
call
determine
the
repository
that
that
that
is
caching
that
will
help
them.
At
least
it
would
help
me
because
when
I
see
a
two
gigabyte
repository,
I
won't
panic.
A
If
I
see
right
next
to
it,
that
it's
stable,
dash
linux,
dot,
git
right,
I
say:
oh
yeah,
I
know
that's
a
monster
and,
and
it's
always
going
to
be
a
monster,
it
is
unavoidably
large
or
if
I
see
git
plug-in
and
it's
400
megabytes.
It's
oh
something's
wrong
there,
because
that
repository
should
not
be
400
megabytes
large.
A
B
A
And
for
me,
the
if
the
table,
if
the
table
said
here's
the
cache
directory
name,
and
that
is
a
unique
name
right-
every
directory
is
uniquely
named
and
then
on
the
same
row.
It
says,
and
here
is
the
repository
it
is
caching,
and
so
they
may
then,
and
even
better,
if
we
then
allow
them
to
do
things
like
sort
the
list
of
of
cached
repository
names,
they
may
say:
oh
that's
funny.
Why
am
I
caching
a
copy
of
this
with
git
protocol
and
a
copy
of
it
with
https
protocol
that
seems
wasteful?
A
B
Yeah
that
does-
and
I
have
another
doubt
regarding
the
data:
where
are
we
going
to
store
it
like?
Are
we
storing
it
in
a
file
in
sentence?
Do
I
have
to
create
a
file,
or
is
there
something
already
and
jenkins,
which
helps
me
write
all
the
data
which
I
need
into
that
file
and
then
read
it
again,
and
you
know
the
maintenance
ui
so
that
I
can
display.
A
That
seems
like
that's
good
enough
if
we
did
a
commit
graph
and
updated
the
data.
That
seems
good
enough
to
me
now
during
the
run
of
that
gc
operation.
While
it's
process
iterating
through
each
of
the
caches,
the
data
will
be
out
of
date.
But
for
me
I
think
I
think
that's
okay,
if
if
it
were,
if
we
said
oh
no,
we
want
to
be
even
better.
You
might
say
at
each
subtask
in
the
gc.
C
C
Mean
to
do
it
after
the
whole
maintenance
process
has
been
over,
seems
much
more
and
the
incentive
that
you
do
it
after
each
particular
repository
seems
so
what
would
be
the
benefit
would
be?
The
user
would
be
able
to
see
the
data
at
that
time
right,
but
yeah
I
mean
it
doesn't
seem
that
much
of
a
big
of
a
benefit
as
compared
to
seeing
it
at
the
end
of
the
whole
execution.
B
Because
if
we
are
going
to
do
it
like,
after
all,
the
after
all
the
after
the
task
is
completed,
then
we
have
to
store
it
right.
We
have
to
remember
the
state
of
each
cache.
What
was
it
did
it
execute
or
not?
How?
What
was
the
execution
time
for
each
maintenance
task
and
then
write
it?
B
A
But
at
least
that's
what
I
was
assuming
is:
is
you
want,
but
but
we've
already
got,
we've
already
got
well,
no,
do
we
I
yeah?
Yes,
I
would
think
you
want
some
data
structure.
That
says
here
is
here's
a
cache
directory
name
and
here
is
the
here
is
the
matching
repository
for
it
and
then
the
run
the
runtime
information
for
the
various
things.
Now
I
guess
it's
a
valid
question.
A
A
C
And
I
was
thinking
so
there's
a
listing
on
the
trade-off
right
I
mean
either
you
have
a
an
increasing
size
of
let's
say
so
you're
when
you're
storing
it
in
memory
that
versus
this
would
be
an
I
o
operation
each
time
right.
So
so
frequency
of
I
o
operation
would,
I
would
say,
have
more
effect
on
performance
as
compared
to
as
far
as
I
can
understand,
having
a
growing
in
memory
right,
yeah.
C
A
You're
you're,
if
now
there
are
plenty
of
things
in
jenkins
that
write
small
files
right.
There
are
many
many
things
that
do
that,
and
so
we
would
not
be
alone
if
we
were
writing
small.
If
we
wrote
wrote
every
time
so
or
if
we
said
hey,
we're
not
going
to
keep
it
in
memory,
we'll
always
read
it
from
disc.
A
C
Yes,
I
mean
he
is
creating
threads,
but
if,
if
the
the
program
is
single,
I
mean
he
would
essentially
let's
say
after
the
execution
task
has
been
done,
he
would
make
an
I
o
call,
so
that
thread
would
then,
whichever
thread
has
done?
The
execution
would
go
for
that
one,
and
I
don't
know
if
that
is
then
so.
C
Essentially
what
my
point
is
that
if
we
could
separate
out
certain
threads
from
the
pool
to
do
this
job,
while
majority
of
the
chunk
is
forming
the
main
execution
of
the
program,
then
knowing
that
I
o,
could
you
know
it
should
not
affect
the
user's
performance
and
it
should
not
take
resources
from
the
main
task
that
is
present
here,
and
that
is
why
we
would
have
an
asynchronous
process
right
so
launch
a
thread
that
is
not
time
bound
in
terms
of
we,
it's
not
necessary
for
us
to
refresh
that
file
or
the
status
at
the
exact
same
time
when
the
task
has
been
done,
but
let's
say
loosely,
it
takes
some
time
and
you
know,
does
it
and
gives
us
the
result.
C
If
that
is
possible,
I
mean
I
haven't
seen
asynchronous
threads.
I
mean
I
mean
jenkins,
I
don't
know
how
that
works.
A
I
mean
jenkins
certainly
has
lots
of
cues
right,
there's
a
job
queue
that
runs
runs
its
queues.
So
if
we
were,
if
we
were
really
concerned,
oh,
this
may
be
just
too
much
data.
We
could
instead
say
hey,
let's
drop
it
onto
a
cube,
we
won't.
We
won't
write
it
to
the.
We
won't
write
it
to
the
final
data
structure,
we'll
just
drop
it
onto
a
queue
and
let,
as
you
suggested
something
process
it
later,
if
it,
if
it's,
if
processing,
is
expensive.
A
Now,
I'm
I'm
not
seeing
a
case
where
I
would
expect
this
result:
data
to
be
expensive
to
process
right
because
rooster
cash.
The
things
I
think
I
thought
you
were
describing
was
repository
directory,
name
url
of
the
repository
and
probably
time
to
execute
each
of
the
tasks
in
the
list.
So
so,
if
it
took
50
milliseconds
to
execute
this
task-
or
it
took
500
seconds
to
execute
this
task,
that
will
be
visible
to
the
user.
So
they
know.
Oh
here's,
where
you're
spending
time
on
these
cash
maintenance
efforts.
C
I
mean
not
that
the
the
amount
of
whatever
you
want
to
store
in
the
file
is
and
the
processing
associated
processing
time.
That
is
going.
Let's
say,
even
if
it's
minor,
I
think
the
whole
point
is
we
were
discussing,
was
that
I
o
execution
takes
more.
I
mean
it's,
it's
a
heavier.
I
mean
in
terms
of
time
right
so
to
separate
that
out
and
since
that
being
a
back-end
process
is
not
something
that
the
user
has
to
be
concerned.
C
B
And
do
I
have
to
create
like
my
own
file
or
is
there
something
already
in
gentlemen's,
which
you
know
helps
me?
Do
that
you
know
which
helps
me
store
all
this
data,
and
then
I
read
it
into
the
ui.
A
I
think
there
are
facilities
in
jenkins
that
will
store
data
data
like
that,
so
the
the
example
I
think
you've
actually
already
used
it
is
that
there's
an
xml
file.
That's
created
that
tracks
the
configuration
of
a
of
a
task
right.
When
is
when
does
it
execute
and
there
what?
What
that's
doing
is
storing
data
for
you
now
now,
I'm
I'm
thinking
now.
Where
would
we
point
you
to
find
an
example
of
something?
That's
storing
data?
A
I
wonder
maybe
we
should
have
you
look
at
the
metrics
plug-in
because
it
certainly
stores
data
about
things
like
well.
Let's
see
I'm
going
to
bring
I'm
going
to
bring
it
up
to
show,
because
this
this
is
a
hint,
maybe
where
we
should
have
you
look
okay.
So
if
I
look
at
this
thing,
you,
okay,
if
I
share
my
screen.
A
Share
screen
we're
going
to
share
this
screen.
Okay,
so
on
this
screen,
what
you
see
is
the
the
ci
server
that
we've
used
for
past
experiments
right.
So
it's
got
quite
a
collection
of
agents,
some
online,
some
offline,
etc,
and
one
of
the
things
that
I
can
do
is
look
at
one
of
the
windows
agents
and
if
I
then
look
at
this
label
amd
64
windows
and
click,
this
load
statistics,
it's
going
to
show
me
load
statistics
for
the
windows,
the
all
the
nodes
that
have
this
label,
and
so
what
you
see
here
is
okay.
A
What
you
see
is
there
were
three
agents
available
here
for
quite
a
period
and
then
we
grew
to
have
11
executors
available,
and
this
shows
when
they're
busy
and
the
busy
the
red
line-
and
this
is
time
over.
So
something
is
keeping
this
data
right.
Someplace
this
data
is
being
stored
and-
and
so
this
metrics
thing
might
be
a
place
for
you
to
look
to
see.
How
does
how
should
we
do?
Data
storage.
A
A
Right
exactly
this
is
this
is
now
in
phase
two
we're
saying:
oh
guess
what
fushakesh
it's
time
to
do
some
research,
this
won't
be
code.
This
will
be
fine
to
find
the
technique
that
jenkins
uses
to
do
this
and
and
use
that
technique.
It's
it.
Unfortunately,
it's
the
same
pattern
that
we
applied
for
rashab
a
few
years
ago,
where,
halfway
into
the
project
we
realized.
There
were
things
we
just
hadn't
known
at
the
start
of
the
project.
We
simply
were
ignorant
of
them
and
it
meant
oh
we've
got
to
go.
A
Do
this
rashab
has
to
go.
Do
this
research?
It's
not.
We
in
this
case
mark
certainly
didn't.
Do
the
research
so
same
thing
I
think,
for
you
is.
This
is
a
topic
that
I
don't
have
an
answer,
for
we
see
examples
that
there
are
things
that
do
give
answers
to
this,
but
I
don't
exactly
know
how
it
does
it.
A
Figure
overview
yeah,
I
think.
Well,
let
me
show
you
the
other
place
where
you
can
see
that
same
kind
of
data.
That
way,
you
know
and
don't
look
at
the
number
of
plug-ins
I
haven't
updated,
yet
I've
still
got
them
on
my
plug-in
updates.
I
haven't
restarted
this
in
several
days.
Okay,
we
need
the
thing
that
is.
A
Of
jenkins,
oh
load
statistics
here:
this
is
the
top
level
load
statistics
for
the
entire
system.
So
what
we
see
here
is
there
was
a.
There
was
a
period
where
I
had
a
hundred
available,
executors
and
or
a
hundred
yeah.
Oh
no!
No!
This
is
a
q
length.
I
had
a
q
length
of
100
and
it
finally
tapered
down,
because
my
executors
were
here
to
do
the
work.
A
B
And
there
was
another
thing
regarding
like
we
discussed
initially
regarding
repository
exclusion
like
currently,
we
are
running,
make
a
new
starts
on
all
the
caches.
B
So
do
we,
so
we
want
to
be
planned
of
adding
a
way
to
exclude
repositories
from
you
know:
maintenance,
okay,
so
and
then
we
thought
we'll
do
it
based
on
regular
expressions
or
you
know,
based
on
the
size
of
the
cache.
B
So
the
thing
about
regular
expressions
is
as
usual,
we
don't
have
the
you
know.
The
repository
like
the
repository
name
and
I
wanted
to
know
like.
Are
there
any
other
way
or
do
we
want
other
ways
of
excluding
deposit
rings
from
get
maintenance.
A
So,
for
me,
repository
url
already
covers
more
more
cases
than
I
would
initially
expect.
I
I'm
not
even
sure
we
have
to
allow
that
people
can
exclude
cash
maintenance
right
it's.
This
is
this
is
for
the
health
of
their
system,
and
we
trust
that
command
line
get
knows
what
it's
doing
when
it
optimizes
a
repository.
A
I
I
I
would
not
object
if
we
didn't
do
exclusions,
but
if
you
can
find
a
way
to
do
exclusions,
I'm
sure
there
will
be
users
that
will
be
pleased
users
who
say
look.
I
know
that
I
want
to
garbage
collect.
I
want
the
garbage
collect
everything
except
this
one
monster
repository
that
I
maintain
myself.
A
C
A
B
Because
I
want
to
get
my
tools
clear
like
what
exactly
do
I
do?
You
know
what
are
the
main
things
I
need
to
focus
on,
so
I
thought
this
was
a
part
of
it,
but
so
right
now
I
think
the
main
thing
would
be
to
display
or
the
execution
data.
B
C
So
I
was
looking
through
the
code,
and
this
is
particularly
related
to
task
executed.
I
I
think,
there's
there's
a
piece
there,
where
you're,
locking
you're
initiating
a
lock
and
then
the
bulk
of
the
operation
that
is
performed
by
git,
is
being
locked
and
then
unlocked.
So
what
so?
First
thing
that
I
was
thinking.
I
don't
know
if
it's
it's
an
exercise
worth
having
or
not,
but
we
should.
C
We
should
do
an
analysis
of
the
threads
or
the
state
of
the
threads
by
taking
a
thread
dump
on
the
jvm
to
see
what
is
the
state
of
what
are
the
threats
that
we're
using
and
the
threats
that
we're
not
using
what
what
is
happening
to
them.
While,
while
the
bulk
of
the
operations
say
you
know,
five
tasks
are
configured
for
a
good
amount
of
repositories.
C
What
is
happening
internally,
because
my
what
so,
what
I
but
my
concern
is
that
when
we
are
applying
a
log
to
the
whole
operation,
how
do
we
define
the
behavior
or
the
rest
of
the
threads
that
come
to
that
operation?
Point
I
mean
what
happens
to
them?
Are
they
waiting
until
the
lock
is
released,
or
should
they
ignore
if
the
lock
is
already
acquired
by
someone?
C
Do
you
come
to
that
point?
You
ignore
it.
You
move
forward,
because
my
please
correct
me
if
I'm
wrong,
if
my
understanding
here
is
incorrect,
but
what
I
understood
from
the
code
was
that
if
I
launch
multiple
tasks,
there
will
be
threads.
That
will
be
waiting
at
that
point
to
acquire
the
locket,
since
it
has
been
acquired
by
someone
who
is
doing
the
gate
operation,
and
so
this
exposes
not
exposes,
but
this
is
so.
C
This
is
a
direct
relationship
between
the
amount
of
time
that
an
execution
of
git
is
taking
with
the
amount
of
time
you're
going
to
lock
a
resource,
and
if
a
resource
is
long,
the
other
threads
won't
be
able
to.
I
mean
we
haven't
defined
a
behavior
that
would
let
them
wait
for
a
certain
time
or
not
wait
at
all
and
move
forward.
C
C
If
you,
if
you
know
the
answer
to
it,
it's
great,
if
you
don't,
then
just
a
simple
thread
and
I'll
drop
dump
of
the
jbm
violated
while
it
is
working
through.
All
of
this
would
be
enough
to
answer
these
questions,
and
if
we
don't
have
blog
threads,
increasing
block
test
the
threads
over
time
for
the
git
operation
or
waiting
threats,
then
I
think
we
have
nothing
to
worry
about.
C
But
if
that
is
the
case,
then
we
should
define
the
behavior
during
that,
because
that
ic
is
the
critical
piece
of
the
whole
operation
that
we're
trying
to
do
so.
Yeah
I
mean
this
is
more
related
to
performance,
I
would
say,
but
yeah
if
it's
something
that
we
could
attempt
do
you
think
mark.
That
is
something
that
we
should
keep
within
the
goals
or
something
more
of
a
good
to
have.
If
we
have
time,
we
should
approach
this
activity.
A
I
I
think
it's
a
good.
I
think
you've
got
a
good
point
to
consider
it.
Let's
do
let's,
if
it's
at
all
possible
for
hiroshikesh
to
fit
it
in.
Let's
do
it.
I
think
it's
just
a
safety
check,
particularly
prushikesh.
I
am
not
a
a
skilled
thread
programmer
and
therefore
there
is
every
risk
that
will
make
some
mistake
and
I
will
fail
to
detect
it
and
so
technique.
A
Likes
techniques
like
what
rishabh
is
suggesting
are
very
healthy
for
us,
because
it's
admitting
mark
weight
thinks
single
threaded
and
he
has
a
very
simple
way
of
thinking
about
things
and
and
the
danger
is
when,
when,
when
we're
wrong
about
those
simple
ways
of
thinking
about
things,
we
could
risk
taking
down
the
controller
right.
We
could
risk
bringing
it
down
for
just
threat
overload.
So
I
think
it's
a
good.
It's
a
good
good
question
to
ask
rashad.
C
C
B
You
know
other,
don't
we
need,
you
know
some
other
threads
which
access
this
good
catches.
At
the
same
time
as
I
am
running,
the
maintenance
task,
you
know
to
know
whether
any
threads
are
waiting
on
them.
C
So
this
is
the
part
where
I
I
think
I
need
to
look
at
the
code
more
but
rishikesh.
My
assumption
is
when
you
have
multiple
tasks.
C
Sorry,
multiple
tasks
when
I
say
task
a
maintenance
start
when
a
user
is
going
to
assign
multiple
metering
tasks.
Is
it
is
a
single
thread
going
to
do
all
of
this,
or
am
I
going
to
launch
multiple
threads
with
each
new
task.
B
A
single
thread
is
going
to
run
all
of
these
tasks,
so
I'm
adding
all
these
tasks
into
a
maintenance
queue,
and
then
I
dequeue
each
task
and
one
or
one
thread
is
created.
It
runs
the
maintenance
task,
it
gets
terminated.
Then
a
new
thread
is
created,
which
runs
the
next
maintenance
task.
If
it
is
present
in
the
queue
and
then
it
get,
it
executes
all
the
maintenance
tasks
and
then
it
gets
dominate.
It
runs
the
maintenance
tasks
from
all
the
caches,
and
then
it
gets
done.
C
B
Yes
and
the
only
only
case
where
threats
would
be,
doctors
assume
any
other
plug-in
which
wants
to
access
this
cash.
Okay,
which
wants
to
do
some
operation.
Those
threads
would
be
waiting,
so
I
am
not
sure
about
what
like
they
would
be
blocked
right.
So
I'm
not
sure.
How
would
that
impact
the
performance.
B
Because
assume
a
gc
running
for
15
minutes,
and
then
there
is
some
jenkins
job
configured
to
run
on
that
dash,
but
it
it
can't
or
it
couldn't
run
it
because
there
is
a
lock
and
the
did
cash
at
the
update
maintenance
task
is
being
done
so
would
that
be
postponed
or
how
would
that?
What
would
that?
C
So
do
we
do
we
classify
the
kinds
of
so
so
the
now
you're
talking
about?
So
I
was
talking
about
the
lock
that
you
have
created
for
people
execution,
but
I
think
the
log
that
you
are
talking
about
is
for
the
cash
directory
that
you
acquire
right
when
you
want
to
get
the
cash
in
yeah.
A
Yes,
yes,
isn't
that
isn't
the
lock
you're
talking
about
actually
a
lock
that
is
acquired
by
command
line
git,
while
it's
running,
for
instance
the
gc?
It
applies
a.
It
applies
a
lock
on
that
repository
that
that
locks
all
command
line,
git
operations
for
the
duration
of
the
gc.
Now
I
don't
know
that
that
happens
for
anything
except
gc,
but
I
thought
that
if
you've
got
a
gc
running,
you
can't
do
other
operations
in
that
repository
concurrently.
B
But
actually
here
there
are
two
locks,
if
you
think
about
it.
Technically,
one
lock
is
done
automatically
by
the
get
tool
by
the
get
software
and
we
have
another
lock
internally
injections,
okay,
so
the
the
lock
done
by
the
get
to
the
software
that
lock
is
added
to
prevent
other
maintenance
tasks
to
run
on
it,
I'm
not
sure
if
it
prevents
other
git
commands.
But
I,
when
I
read
about
it,
it
was
to
prevent
other
maintenance
tasks.
So
that
is
one
law.
B
I
don't
think
that
log
should
be
of
any
concern,
because
that
is
internally
done
by
it.
The
other
lock,
which
we
have
in
jenkins,
I'm
worried
about
that
lock,
because
if
we
are
using,
if
we
are
running
maintenance
tasks
and
if
any
other
plugin
tries
to
access
that
directory,
what
would
happen
to
them?
Would
they
be
in
a
waiting
state
or
like
they
would
be
in
a
victim
state?
So.
C
No
so
rishikesh
have
so.
This
is
the
log
that
is
implemented
by
the
abstract
gate,
scm
right.
Yes,
where
the
caches
are
so
I
think
what
we
should
understand
is.
I
think
I
believe
that
the
nature
of
the
log
is
it
is.
C
So
there
are
ways
for
us
to
have
locks
where
read
access
to
the
log,
even
if,
if
a
lock
is
required
to
a
resource,
threads
can
read
it
and
they
don't
have
to
wait
to
read
on
the
resource.
But
if
they
want
to
perform
a
right,
then
they
have
to
wait
to
do
anything
on
the
resource.
So
I
I
think
we
should
look
into
that.
What
is
exactly
happening
there
and
rishikesh?
You
are
performing
a
purely
a
read
operation
on
the
caches.
C
No,
but
that
is
when
you're
looking
at
the
cache
when
you
take
the
cache
log
and
you
so
no
okay,
so
that
is
the
right
operation.
There
is
a
we
can
write
both.
So
we
can't
yeah.
B
And
then,
even
though
another
plugin
tries
to
access
this
cache,
we
are
not
like
how
do
we
differentiate
it's?
A
a
read
operation
or
a
write
operation,
because
assume
of
this
status
command
could
be
a
read
operation.
But
then,
when
I
do
a
get
commit
operation,
it
could
be
a
right
operation.
So.
C
C
C
This
is
the
only
way
that
I
have
seen.
I
mean:
how
do
you
ensure
that
a
single
thread
does
not
take
more
time?
C
That
would
create
a
situation
where
you
have,
let's
say,
a
huge
number
of
block
threads.
That
would
concern
you
is
that
you,
so
you
define
a
waiting
behavior
for
for
the
threads
that
have
to
wait
on
a
lock,
but
I
believe
that
we
have.
We
would
have
to
change
the
very
nature
of
how
logs
are
acquired
for
each
individual
cache
at
abstract,
git
scm
level,
and
that
is
something
that
we
should
be
very
careful
about,
since
that
is
used
by
abstractgatescm
is
a
contract
that
is
inferred
by
a
lot
of
plugins.
C
But
I
guess
a
thread
dumped
in
that
sense.
Rishikesh
could
help
you
to
understand
to
analyze
what
is
exactly
going
on
in
your
in
the
jvm
that
is
initiated
the
jenkins
you
would.
You
would
be
able
to
see
for
an
example.
If
you
are
on
mark's
machine-
and
you
know
I
guess
this-
this
scenario
could
be
replicated
where
your
maintenance
task
is
running.
Unless
your
multi-branch
project
is
also
simultaneously
running,
then
you
could
look.
You
could
analyze
the
thread
down
over
time
and
see
what
is
happening.
Is
there
a
concern.
A
Well,
and-
and
I
I
promise
you
that
machine
has
it,
if
you
want
to
tell
me
when
you're
interested
in
doing
that
analysis,
I
can
exercise
it
because
there
is.
There
is
a
repository
on
that
machine.
That's
used
for
multi-branch,
that
is
a
160
or
more
megabytes,
with
50
or
60
branches
and
commits
that
are
arriving
on
many
of
those
branches
simultaneously
and
jobs
that
are
defined
to
use
that
cash
through
five
or
six
multi-branch
pipelines.
A
So
so
it's
it's
horrible
and
embarrassing
what
I've
done
there,
but
it's
a
good
stress
test,
so
so
yeah,
it's!
It's
called
the
jenkins-bugs
repository
in
case
you're
interested
which
one
it
is.
If
you
ever
see
that
one
in
any
of
my
diagnostic
stuff,
that's
a
an
enormous
repository.
That's
just
filled
with
with
data.
That's
used
to
help
me
validate
certain
jenkins,
bugs
are
still
bugs
or
are
no
longer
bugs.
C
So
there's
this
tool
called
jstack
which
comes
within
the
mandatory
pack,
so
you
can
you
can
take
a
look
at
this
rishikesh.
I
even
have
the
command,
so
you
need
to
know
the
process
id.
If
you
know
that
you
just
need
to
lj
stack
that
and
then
it
would
basically
do
the
analysis,
do
the
dump
and
store
it
in
it.
Some
text
file
that
you
can
then
add
an
animates.
B
Also,
there
was
one
thing
regarding
security.
I
am
not
sure
if
I
feel
it's
a
security
issue
like
we
have
a
hash
set
right,
so
we
have
a
hashtag
where
we
are
storing
all
the
cash
entries
and
assume
any
class.
B
There's
a
you
know,
inheriting
or
this
abstract
bit
scm
and
if
they,
if
they
iterate
through
that
hashtag,
they
can
get
the
lock
of
that
or
you
know
of
that,
get
repository
and
then
and
then
think
of
a
case
where
they
don't
set
that
law
or
they
use
that
log
in
or
you
know,
an
appropriate
way.
I
think
that
would
cause.
B
Because
our
we
have
a
hash
hash
map,
concurrent
hashmap,
which
takes
a
cache
entry
as
its
key
and
a
lock
as
its
value,
and
we
have
a
hash
set.
B
You
know
we
have
a
heart
set
of
all
the
cash
entries.
So
if
anyone
iterates
over
it-
and
you
know
law-
you
know
passes
it
to
the
concurrent
hashmap,
they
can
get
the
law
and
they
can
lock
that
repositories.
I'm
not
sure
if
this
is
a
security
issue,
but
I
wanted
to
discuss
it.
C
B
C
C
Is
that
they
are
able
to
somehow
access
the
internally,
the
git
plug-in
apis,
and
if
that
is
the
case,
then
I
mean
how
would
be
able
to
stop
if
they
can
access
our
hash
map,
then
they
probably
can
access
ready,
caches.
A
Once
you're,
once
you're
inside
the
jenkins
controller's
java
process,
all
bets
are
off
right.
Yes,
yes,
there
are
some
things
we
can
do
to
defend,
but
I
can
do
acl
dot
as
and
become
become
an
administrator
right.
So
I
I
don't
yeah,
I
I
don't
think
there's.
I
don't
think
that
defense
is
one
we
need
to
worry
about,
but
I
I
was
interpreting
hrishikesh's
concern
as
an
api
level
threat
that
there
was
someone
who
inherits
from
abstract
get
get
scm
project
gets
access
to
data
that
we
would
prefer.
A
They
didn't
have
didn't,
have
available
yeah,
and
I
don't
know
how
to
solve
that
one.
You
might
want
to
look
at
joshua,
block's
material
called
effective
java
he's
got
a
he's
got
he's
he's
got
some
of
the
things
about
things
like
that
and
and
inheritance
design
patterns.
I
I
am
not
nearly
well
enough.
First
to
be
be
a
good
coach
on
that.
B
So
basically,
right
now
assume
some
a
plugin
is,
you
know,
running
on
some
command
on
a
git
cache
and
at
the
same
time
or
the
kit
maintenance
task
wants
to
run.
You
know
the
maintenance
tasks
from
that
cash.
Do
we
want
to
skip
the
maintenance
task
if
it's
being
executed
by
some
other
plug-in,
or
do
we
wait
for
that
plug-in
to
release
the
lock,
and
then
we
execute
the
maintenance
task.
A
Okay,
good
algorithmic
question,
so
if
we
skip
there's
a
risk
that
we
will
never
get
a
chance
to
do
any
the
maintenance
on
that
repository,
but
if
we
don't
skip
there's
a
risk,
we
won't
do
the
maintenance
on
any
repository,
because
we're
blocked
for
a
very
long
time
on
that
repository
right
now,
I'm
not
entirely
sure.
I'm
really
confident
which
of
those
two
is
is
healthier,
which
is
not
right,
because
I
guess
sacrificing
one
repository
for
the
good
of
the
many
is
probably
the
better
choice.
A
Think
of
mr
spock-
and
maybe
maybe
that's
what
we
need
is
to
admit
admit
that
the
good
of
the
many
outweigh
the
good
of
the
few.
In
this
case
maybe
but
but
that
may
mean
some
large
repository
never
gets
garbage
collected,
because
if
it's,
if
it's
large
and
also
very
active
and
the
linux
kernel
is
a
is
a
an
excellent
example
of
that
right
for
15
or
more
years,
it's
had
an
awe-inspiring
rate
of
commits
arriving
in
that
repository
and
they
are
small,
very
well
vetted
thoroughly
thought
through
commits.
A
B
Also,
if
you
think
about
it,
no,
if
you
know
gc,
will
be
scheduled
once
in
two
weeks
or
once
in
a
week
also,
once
in
two
weeks
or
something
it
unlike
the
previous
week,
it
would
have
been
scheduled
and
maintained
right,
so
it
wouldn't
be
as
worse
as
it
was
right,
yeah
and
if
you
know,
if
you
skip
a
week
and
then
do
it
the
next
week,
it
would
be
fine.
So.
A
Well
and-
and
I
think,
those
kinds
of
risks,
if,
if
the
ui
can
help
people
see
those
kinds
of
risks,
they
may
thank
us
very
much
right
if
you
show
them
hey
here's
a
table
of
when
we
last
ran
this
this
task
and
they
sort
it
by
date
and
say
whoa
the
last
time
my
garbage
collected
this
repository
was
eight
weeks
ago.
Why
is
that
and
that
that
may
be
a
very
helpful
thing
for
that
administrator
to
oh?
Why
is
my
garbage?
Why
is
my?
C
So
I
think
there
has
to
be
a
consist.
So
if
right
now,
a
multi-branch
pipeline
is
running
and
I
go
to
the
machine
and
I
run
the
git
gc
command,
it
won't
stop
that
multi
branch
job
right
and,
let's
say
let's
say
the
g.
I
started
the
gc
before
the
multi-crunch
operation
and
then
the
multi-branch
project
or
the
job
started
executing
it
won't
stop
it
from
happening.
C
But
I
mean
so
with
my
what
I
what
I'm
trying
to
arrive
at
as
that
there
should
be.
I
mean,
if
get
g,
if
I
manually
run
these
operations
without
using
jenkins.
I
mean
this
is
just
a
manual
git
operation
that
I'm
trying
to
run,
and
I,
when
I
do
that,
I
don't
have
to
acquire
cash
locks.
I
mean
myself
right,
I'm
just
I'm
asking
git
to
do
whatever
it
has
to
do
right.
C
C
The
consistency
that
we
should
aim
for
when
we
are
doing
this
via
git
plugin,
whatever
logs
that
we
acquire
or,
however
we
do
it,
it
doesn't
matter,
but
for
the
user
it
should
appear
the
same,
and
that
should
it
shouldn't
happen
that
do
run
the
maintenance
tasks,
because
we
have
additional
logs
or
let's
say
we,
you
know
we
block
the
cache.
We
can't.
I
can't
even
run
my
project
because
of
that.
A
And
that's
one
I
think,
we'll
need
to
check,
particularly
with
one
of
these
very
large
repositories
right.
We
may
want
to
do
an
explicit
test
start
the
garbage
collection
on
the
linux
kernel
and
then
launch
a
multi-branch
pipeline
job
indexing
that
do
they
do
they
does
it
complete
and
does
it
complete
promptly
or
is
it
in
fact
blocked
waiting
for
the
lock
on
the
cache.
B
Okay,
so
let
me
get
this
clear
so
regarding
the
execution
of
maintenance,
a
task
like
if
the
lock
has
been
blocked
by
some
other
plugin.
So
do
I
skip
it
or.
B
B
There
was
one
last
one
regarding
you
know
getting
the
bit
version
on
in
the
bit
plug-in.
Okay,
when
I
was
reading
the
code
when
I
implemented
it,
we
are
going.
We
are
calling
the
native,
you
know,
git
cli
tools
and
you
know
on
the
computer,
but
then
jenkins
has
various
ways
of
getting
different.
You
can
bet
you
can
configure
different
versions
of
the
get
off.
You
know
to
get
software
like
the
get
tool.
B
So
how
how
do
I
know
that
the
get
version
which
I
am
getting
is
the
same
as
the
one
considered
in
jenkins?
Is
it
always
the
same
or
imagine
like
think
of
a
case
like
normally,
you
know
there
is
always
one
particular
version
set
on
the
computer
right.
So
am
I
getting
only
that
version?
A
A
A
C
Yes,
that
is
what
we
we
did
for
the
git
tool,
chooser
class,
that
we
have
so
there
was
so.
What
we
did
was
that
we
would.
We
took
the
default
installation
and
then
we
checked
if
it
was.
What
was
the
kind
of
instance
that
is
it
a
jet
or
a
cli
implementation,
and
then
we
would
check
the
compatibility
per
node
is?
Is
this
compatible
for
this
load
or
not?
B
What
forward
is
compatible
here?
Because
when
I've
seen
the
get
client
plug-in,
there
is
no
way
of
getting
the
version
of
the
you
know
get
you
know
the
underlying
git
tool
which
has
been
used
so.
C
C
B
Use
so
so,
basically,
as
default,
the
one
which
is
already
installed
on
the
computer
electron
on
my
computer
or
is
it
something
which
is
configured
in
jenkins,
but
is
not
you
know
like
by
passing
some
other
path
to
the
bit
one
to
the
you
know,
kit
tool
which
is
installed,
but
when
I
run
a
git
command
on
my
computer,
it
is
not
the
same
as
the
default
presence.
B
C
B
If
it
is
the
default,
one
is
the
same
as
the
one
in
the
system.
Then
we
have
nothing
to
worry
about,
but
if
it
doesn't,
then
you
know
there
would
be
like
some
variations
because
assume
the
system.
One
has
a
two
dot,
18
a
bit
more
kit
version
and
he
the
same
system
even
has
2.2.30.
But
it's
configured
on
jenkins.
B
C
C
A
It
is,
as
far
as
I
understand
it
now.
I
thought
that,
and
I
haven't
proven
that
I
thought
that
the
controller
would
consistently
select
the
first
get
tool
that
was
listed,
that
it
would
so
it
would
in
the
in
the
configure
global
tools,
page
there's
a
get
section,
and
that
includes
an
ordered
list
of
tools
and
as
far
as
I
understood
it,
it
takes
the
top
of
that
list
for
the
controller,
and
I
don't
think
it
now.
A
C
A
C
A
Right,
if,
if
you,
if
the
yeah,
if
the
administrator
wants
to
use
a
different
git
implementation,
they
must
put
it
at
the
top
of
the
list
for
the
controller,
at
least
that's
that's.
What
I've
observed
on
ci.jenkins.io
that
that's
where
we
intentionally
put
jkit
at
the
top
of
the
list,
and
we
see
that
it
is
used.
C
A
Well,
and-
and
that
may
be
okay
at
minimum,
if
we
detect
that
condition,
can
we
log
it
and
tell
the
administrator
warning
you
have
you
have
this
invalid
configure?
You
have
this
sub-optimal
configuration
it's
not
even
particularly
invalid
right.
It's
what
you've
described
to
shikesh's
they're
running.
We
they've
somehow
chosen
to
run
1.8,
but
on
that
same
node
on
that
same
controller,
here's
2.37
that
we
could
have
used
and
it
would
have
been
much
better
than
that
ancient
1.8
version
that
they
have.
A
Although
maybe
we
could
do
them
a
favor
by
telling
them
how
old
their
git
version
is
and
that's
all
we
do,
and
we
always
tell
them
at
startup,
your
git
version
is
lacks
the
following
capabilities,
because
rishabh
your
capabilities
checks
were
exactly
that
right.
It
was.
I
don't
want
to
ask.
I
don't
want
to
do
this.
If
I
know
the
command
line
get
lacks
these
capabilities
and
trusha
cash.
A
B
A
A
I've
just
been
through
a
terrible
experience
with
a
bun,
a
number
of
jenkins
users
on
centos
7
telling
me
that
we
broke
them
with
a
security
fix.
We
just
released
because
centos
7
runs
an
ancient
version
of
ssh
that
we
had
missed
testing
so
so
this
is
sort
of
hot
on
my
list
at
the
moment
I
apologize
for
banging
on
something
like
this.