[
https://issues.apache.org/jira/browse/TS-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716633#comment-13716633
]
Leif Hedstrom commented on TS-2063:
-----------------------------------
Oops, left out the "proof of concept" patch ( I think I agree with amc that
both loops should be refactored):
{code}
diff --git a/proxy/logging/LogFile.cc b/proxy/logging/LogFile.cc
index a47ba63..6d53047 100644
--- a/proxy/logging/LogFile.cc
+++ b/proxy/logging/LogFile.cc
@@ -683,6 +683,8 @@ LogFile::write_ascii_logbuffer3(LogBufferHeader *
buffer_header, char *alt_forma
//
if (m_file_format == ASCII_PIPE)
break;
+ } else {
+ break;
}
} while ((entry_header = iter.next()));
{code}
> 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
