Leif Hedstrom created TS-2063:
---------------------------------
Summary: 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
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
