trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chou, Peter" <>
Subject RE: Issue #2416 - Log Collation Memory Leak.
Date Thu, 26 Jul 2018 20:41:53 GMT

1) No problem. It is a two line change so we can carry in our custom 7.1.x if necessary.

2) Yeah this feature has issues. After fixing this memory leak, we realized that there is
ANOTHER leak if you over-run the log collation transfer capacity triggering the "send-queue
full" message. Perhaps this can be mitigated by increasing the send queue size (collation_max_send_buffers).
This second issue can be triggered by increased transaction rate and/or configuring multiple
active hosts, i.e., { host1, host2 } rather than active-standby { { host1 , host2 } }, to
over-load the log sending capacity. I will take your proposal back to discuss with my users.


-----Original Message-----
From: Leif Hedstrom [] 
Sent: Thursday, July 26, 2018 12:54 PM
To: dev <>
Subject: Re: Issue #2416 - Log Collation Memory Leak.

> On Jul 26, 2018, at 3:14 AM, Chou, Peter <> wrote:
> Hi All,
> After some additional study on how the ink_atomic_increment() and LogBuffer::destroy()
work together in the LogFile::, LogHost::, and LogHostList::preproc_and_try_delete() functions,
the following is probably a better patch to address this issue. Appreciate any second opinions
on this before I open a PR.

Nice find.

However, I have two comments on this:

1) I’d really prefer not to respin the 7.1.x release over this. Most people don’t use
this (IMO broken) feature. I hope that’s ok.

2) I’d like to restart the discussions of removing this feature from v9.0.0 again (in fact,
I kinda wish we could nuke its from 8.0.0, but a little late for that).

For #2, I feel that there are a lot better tools out there, like Kafka, Elastic Search (or
Splunk for a commercial solution).

I’ll make a separate thread on asking for the deprecation and removal of this feature :-)


— Leif

View raw message