...
Attendees:
JV, Enrico, Sijie, Yiming
Minutes:
JV: we have some a leak on on the reader
from Slack:
we
ran
into
fullGC
and
zktimeouts
over
a
long
run
and
the
GC
shows
like
this359752
3:
1650087
79204176
java.util.HashMap
359753
4:
718190
74691760
org.apache.bookkeeper.client.PendingReadOp
359754
5:
823944
59323968
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
Pointing
to
PendingReadOp
protected
void
cancelSpeculativeTask(boolean
mayInterruptIfRunning)
{
if
(speculativeTask
!=
null)
{
speculativeTask.cancel(mayInterruptIfRunning);
speculativeTask
=
null;
}
}
But
we
never
assign
anything
to
speculativeTask
so
we
never
cancel
them
That
appears
to
be
one
issue
for
sure
do
you
guys
see
any
other
issues?
or
have
run
into
similar
problem?
Yiming reports that at Twitter they saw something similar, but it was due to the bookie which was throttling the clients, which in turn they were queuing up the requests
Sijie: The problem should be around the fact we are not cancelling the PendingReadOp
JV has a quick fix
Sijie: about the 128bit ledger id. switching to 128bit should not have impact on performances. It will need some engineering work for the implementation.
JV: Sijie's proposal is fine, but how can we start wokring on this, it is a bug change
Sijie: We can split the work in smaller tasks, it is important to stay always backward compatible.
Enrico: we have to decide a name for 'scope' soon
JV and Sijie: oky for "scope", it sounds like a "workaround", but it is fine, let's start this thing soon.