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

["Yunkai Zhang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730516#comment-13730516 ] 

Yunkai Zhang commented on TS-2063:
----------------------------------

[~zwoop]

I'm reading this code now. 

Adding a "break" statement can't totally fix all the issue in the function.

I'll give a new patch for it.
                
> 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
>
>
> 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