[
https://issues.apache.org/jira/browse/TS-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2063:
------------------------------
Fix Version/s: 3.5.0
> 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
> Fix For: 3.5.0
>
>
> 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.
--
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
