[
https://issues.apache.org/jira/browse/TS-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2063:
-----------------------------
Attachment: 0001-TS-2063-LogFile-write_ascii_logbuffer3-can-silently-.patch
1) Avoid silently dropping log entries in write_ascii_logbuffer3().
2) Remove overspill logic, and try to write log to disk as much as possible.
3) Simplify the code by removing unecessary *overspill* variables.
> LogFile::write_ascii_logbuffer3() can silently drop log entries
> ---------------------------------------------------------------
>
> Key: TS-2063
> URL: https://issues.apache.org/jira/browse/TS-2063
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Labels: A
> Fix For: 3.5.0
>
> Attachments:
> 0001-TS-2063-LogFile-write_ascii_logbuffer3-can-silently-.patch
>
>
> Couple of things here.
> 1. Why do we need both LogFile::write_ascii_logbuffer() and
> LogFile::write_ascii_logbuffer3()? The former is only used by traffic_logcat,
> we ought to be able to refactor and unify this.
> 2. In LogFile::write_ascii_logbuffer3(), it's possible that writing to the
> LogBuffer has produced more entries than we can marshal and fit into an ascii
> buffer. When that happens, we'd simply drop those log entries on the floor.
> 3. It's possible this also relates to TS-777.
> As for 2, I think we should at a minimum break out of the inner loop in the
> else branch of testing if an entry fits (instead of silently dropping the
> entry). This puts weirdness in the outer loop, for the case where a single
> entry can't fit in the ascii buffer (I don't know if it can happen, but it
> might).
> A suggestion from amc is to refactor both loops into a single loop that
> iterates and checks size restrictions. This is actually similar to how
> LogFile::write_ascii_logbuffer() works as well (so fixing / unifying issue 1)
> above might be the way to resolve this as well).
> As for 3) I have no other proof that this bug is affiliated with TS-777,
> other than they both have issues in the same area. And thinking about if, if
> you increase proxy.config.log.log_buffer_size but leave
> proxy.config.log.max_line_size the same, we get much larger LogBuffers, but
> the ascii buffer is still the same size (so we're almost certain to trigger
> 2) above).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
