You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Alan M. Carroll (Created) (JIRA)" <ji...@apache.org> on 2011/11/15 00:03:52 UTC
[jira] [Created] (TS-1021) traffic_logstats fails on zwoop's
machine
traffic_logstats fails on zwoop's machine
-----------------------------------------
Key: TS-1021
URL: https://issues.apache.org/jira/browse/TS-1021
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.0
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Fix For: 3.1.1
As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpful appends a newline to the binary day. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1021) traffic_logstats fails on zwoop's
machine
Posted by "Alan M. Carroll (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan M. Carroll updated TS-1021:
--------------------------------
Attachment: ts-1021.diff
> traffic_logstats fails on zwoop's machine
> -----------------------------------------
>
> Key: TS-1021
> URL: https://issues.apache.org/jira/browse/TS-1021
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.1.0
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Fix For: 3.1.2
>
> Attachments: ts-1021.diff
>
>
> As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpful appends a newline to the binary day. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
> There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1021) traffic_logstats fails on zwoop's
machine
Posted by "Alan M. Carroll (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan M. Carroll updated TS-1021:
--------------------------------
Description:
As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpfully appends a newline to the binary data. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
was:
As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpful appends a newline to the binary day. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
Labels: logging serialization (was: )
> traffic_logstats fails on zwoop's machine
> -----------------------------------------
>
> Key: TS-1021
> URL: https://issues.apache.org/jira/browse/TS-1021
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.1.0
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Labels: logging, serialization
> Fix For: 3.1.2
>
> Attachments: ts-1021.diff
>
>
> As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpfully appends a newline to the binary data. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
> There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1021) traffic_logstats fails on zwoop's
machine
Posted by "Alan M. Carroll (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan M. Carroll updated TS-1021:
--------------------------------
Fix Version/s: (was: 3.1.1)
3.1.2
> traffic_logstats fails on zwoop's machine
> -----------------------------------------
>
> Key: TS-1021
> URL: https://issues.apache.org/jira/browse/TS-1021
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.1.0
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Fix For: 3.1.2
>
>
> As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpful appends a newline to the binary day. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
> There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1021) traffic_logstats fails on zwoop's
machine
Posted by "Alan M. Carroll (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan M. Carroll updated TS-1021:
--------------------------------
Attachment: (was: ts-1021.diff)
> traffic_logstats fails on zwoop's machine
> -----------------------------------------
>
> Key: TS-1021
> URL: https://issues.apache.org/jira/browse/TS-1021
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.1.0
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Labels: logging, serialization
> Fix For: 3.1.2
>
> Attachments: ts-1021.diff
>
>
> As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpfully appends a newline to the binary data. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
> There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1021) traffic_logstats fails on zwoop's
machine
Posted by "Alan M. Carroll (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan M. Carroll updated TS-1021:
--------------------------------
Attachment: ts-1021.diff
> traffic_logstats fails on zwoop's machine
> -----------------------------------------
>
> Key: TS-1021
> URL: https://issues.apache.org/jira/browse/TS-1021
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.1.0
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Labels: logging, serialization
> Fix For: 3.1.2
>
> Attachments: ts-1021.diff
>
>
> As best I can track this down, the problem arises during log creation. For reasons I would prefer to not know, log buffers are written to binary files using the LogFile.cc:writeln which helpfully appends a newline to the binary data. Unless the binary data already ends with a newline, in which case it doesn't. logstats, when reading the file, always add an extra byte to read to skip over this newline, which can be problematic in the latter case. Whether this happens seems to depend on the client brower because the last field in the standard log format is XID, a MIME field. LogAccessHttp::marshal_client_accelerator_id pulls the XID out of the MIME fields and then adds one to the returned length, to account for the possibly non-existent terminating nul (it being a MIME field). That extra byte gets carried along and written out as part of the XID. If it turns out to be a newline, then there is a problem.
> There's so much wrongness here I don't even know where to start. There's even expensive code in both logcat to detect small shifts (such as being off by one due to a missing newline) and re-synchronize. logstats has similar code but it only used when starting at an offset in to the log file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira