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