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
How are you seeing that it is leaking memory. It looks like this change
happened back in ATS 4.2.0:
commit 09ce8dc3434b92b00d99e0147e533a5f0bde8d7c
Author: Yunkai Zhang
Date: Mon Jan 6 23:00:14 2014 +0800
TS-2479: Don't output orphan log after failover sucessfully
Don't output orpha
Simply configure a bad log collation host. In our lab, we just changed the port
number to something bogus. So make ALL defined hosts down if you have more than
one.
-Original Message-
From: Bryan Call [mailto:bc...@apache.org]
Sent: Thursday, July 26, 2018 12:46 PM
To: dev@trafficserver
> 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
Hi all,
I’d like to mark the log collation feature as deprecated for the v8.0.0
release, such that we can remove it from v9.0.0. I have a number of reasons for
this
1) It’s generally really broken. For example, the orphaned logs files are not
handled in any reasonable way, making the feature I
Sounds good.
> 3) Perhaps most importantly, this is not a problem that ATS should solve iMO.
> There are much better systems out there, such as Kafka, Elastic Search,
> Splunk etc., all which solves this problem in a much better way.
Would we offer a recommendation along these lines during whil
> On Jul 26, 2018, at 2:05 PM, Derek Dagit wrote:
>
> Sounds good.
>
>> 3) Perhaps most importantly, this is not a problem that ATS should solve
>> iMO. There are much better systems out there, such as Kafka, Elastic Search,
>> Splunk etc., all which solves this problem in a much better way
Leif,
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. Pe
In the TS API should we remove the errbuf / errbuf_size parameters to
TSRemapInit() and TSRemapNewInstance() ? It seems better to report
any diagnostics with TSError() or TSDebug().
