[jira] [Created] (TS-2063) LogFile::write_ascii_logbuffer3() can silently drop log entries

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

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