[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811012#comment-13811012 ] William Bardwell commented on TS-1776: -- Not sure if it would be the same or not...Like I said the fix for TS-1574 looked like it fixed most of the issues that I saw for (just wasn't ported back to 3.2.X) But I would be happy to look at the change and see if it helps at all... > Range requests not working right in 3.2.4 > - > > Key: TS-1776 > URL: https://issues.apache.org/jira/browse/TS-1776 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.4 >Reporter: William Bardwell >Assignee: Alan M. Carroll >Priority: Blocker > Fix For: 3.2.6 > > > With the patch in 3.2.4 for TS-1575 that tries to turn off the new range > code, range requests aren't work right for me. The responses have all of the > multi-part header markings, but the Content-Length and Content-Range headers > should be used for single range requests. Also when I do a range that starts > > 0, the content is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1955) read_while_writer sends wrong response for range request.
[ https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811005#comment-13811005 ] Leif Hedstrom commented on TS-1955: --- I have a patch for problem 2) above. That will at least make the requests function as they should, albeit "slow". With some more testing, I think we should focus this bug on that problem, and file an RFE for a new overridable configuration to solve problem 1). Thoughts? > read_while_writer sends wrong response for range request. > - > > Key: TS-1955 > URL: https://issues.apache.org/jira/browse/TS-1955 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.2.4 >Reporter: jaekyung oh >Assignee: Leif Hedstrom > Labels: range > Fix For: 4.1.0 > > > Basically read_while_writer works fine when ATS handles normal file. > In progressive download and playback of mp4 in which moov atom is placed at > the end of the file, ATS makes and returns wrong response for range request > from unfulfilled cache when read_while_writer is 1. > In origin, apache has h264 streaming module. Everything is ok whether the > moov atom is placed at the beginning of the file or not in origin except a > range request happens with read_while_writer. > Mostly our customer’s contents placed moov atom at the end of the file and in > the case movie player stops playing when it seek somewhere in the movie. > to check if read_while_writer works fine, > 1. prepare a mp4 file whose moov atom is placed at the end of the file. > 2. curl --range - http://www.test.com/mp4/test.mp4 1> > no_cache_from_origin > 3. wget http://www.test.com/mp4/test.mp4 > 4. right after wget, execute “curl --range - > http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal > (the point is sending range request while ATS is still downloading) > 5. after wget gets done, curl --range - > http://www.test.com/mp4/test.mp4 1> from_cache > 6. you can check compare those files by bindiff. > The response from origin(no_cache_from_origin) for the range request is > exactly same to from_cache resulted from #5's range request. but > from_read_while_writer from #4 is totally different from others. > i think a range request should be forwarded to origin server if it can’t find > the content with the offset in cache even if the read_while_writer is on, > instead ATS makes(from where?) and sends wrong response. (In squid.log it > indicates TCP_HIT) > That’s why a movie player stops when it seeks right after the movie starts. > Well. we turned off read_while_writer and movie play is ok but the problems > is read_while_writer is global options. we can’t set it differently for each > remap entry by conf_remap. > So the downloading of Big file(not mp4 file) gives overhead to origin server > because read_while_writer is off. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-1955) read_while_writer sends wrong response for range request.
[ https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1955: -- Fix Version/s: (was: 4.2.0) 4.1.0 > read_while_writer sends wrong response for range request. > - > > Key: TS-1955 > URL: https://issues.apache.org/jira/browse/TS-1955 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.2.4 >Reporter: jaekyung oh >Assignee: Leif Hedstrom > Labels: range > Fix For: 4.1.0 > > > Basically read_while_writer works fine when ATS handles normal file. > In progressive download and playback of mp4 in which moov atom is placed at > the end of the file, ATS makes and returns wrong response for range request > from unfulfilled cache when read_while_writer is 1. > In origin, apache has h264 streaming module. Everything is ok whether the > moov atom is placed at the beginning of the file or not in origin except a > range request happens with read_while_writer. > Mostly our customer’s contents placed moov atom at the end of the file and in > the case movie player stops playing when it seek somewhere in the movie. > to check if read_while_writer works fine, > 1. prepare a mp4 file whose moov atom is placed at the end of the file. > 2. curl --range - http://www.test.com/mp4/test.mp4 1> > no_cache_from_origin > 3. wget http://www.test.com/mp4/test.mp4 > 4. right after wget, execute “curl --range - > http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal > (the point is sending range request while ATS is still downloading) > 5. after wget gets done, curl --range - > http://www.test.com/mp4/test.mp4 1> from_cache > 6. you can check compare those files by bindiff. > The response from origin(no_cache_from_origin) for the range request is > exactly same to from_cache resulted from #5's range request. but > from_read_while_writer from #4 is totally different from others. > i think a range request should be forwarded to origin server if it can’t find > the content with the offset in cache even if the read_while_writer is on, > instead ATS makes(from where?) and sends wrong response. (In squid.log it > indicates TCP_HIT) > That’s why a movie player stops when it seeks right after the movie starts. > Well. we turned off read_while_writer and movie play is ok but the problems > is read_while_writer is global options. we can’t set it differently for each > remap entry by conf_remap. > So the downloading of Big file(not mp4 file) gives overhead to origin server > because read_while_writer is off. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811003#comment-13811003 ] Leif Hedstrom commented on TS-1776: --- I wonder if this is related to TS-1955 as well ? I have a fix for that, which might apply to v3.2.x as well. William, care to try ? > Range requests not working right in 3.2.4 > - > > Key: TS-1776 > URL: https://issues.apache.org/jira/browse/TS-1776 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.4 >Reporter: William Bardwell >Assignee: Alan M. Carroll >Priority: Blocker > Fix For: 3.2.6 > > > With the patch in 3.2.4 for TS-1575 that tries to turn off the new range > code, range requests aren't work right for me. The responses have all of the > multi-part header markings, but the Content-Length and Content-Range headers > should be used for single range requests. Also when I do a range that starts > > 0, the content is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TS-1955) read_while_writer sends wrong response for range request.
[ https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1955: - Assignee: Leif Hedstrom (was: Alan M. Carroll) > read_while_writer sends wrong response for range request. > - > > Key: TS-1955 > URL: https://issues.apache.org/jira/browse/TS-1955 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.2.4 >Reporter: jaekyung oh >Assignee: Leif Hedstrom > Labels: range > Fix For: 4.2.0 > > > Basically read_while_writer works fine when ATS handles normal file. > In progressive download and playback of mp4 in which moov atom is placed at > the end of the file, ATS makes and returns wrong response for range request > from unfulfilled cache when read_while_writer is 1. > In origin, apache has h264 streaming module. Everything is ok whether the > moov atom is placed at the beginning of the file or not in origin except a > range request happens with read_while_writer. > Mostly our customer’s contents placed moov atom at the end of the file and in > the case movie player stops playing when it seek somewhere in the movie. > to check if read_while_writer works fine, > 1. prepare a mp4 file whose moov atom is placed at the end of the file. > 2. curl --range - http://www.test.com/mp4/test.mp4 1> > no_cache_from_origin > 3. wget http://www.test.com/mp4/test.mp4 > 4. right after wget, execute “curl --range - > http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal > (the point is sending range request while ATS is still downloading) > 5. after wget gets done, curl --range - > http://www.test.com/mp4/test.mp4 1> from_cache > 6. you can check compare those files by bindiff. > The response from origin(no_cache_from_origin) for the range request is > exactly same to from_cache resulted from #5's range request. but > from_read_while_writer from #4 is totally different from others. > i think a range request should be forwarded to origin server if it can’t find > the content with the offset in cache even if the read_while_writer is on, > instead ATS makes(from where?) and sends wrong response. (In squid.log it > indicates TCP_HIT) > That’s why a movie player stops when it seeks right after the movie starts. > Well. we turned off read_while_writer and movie play is ok but the problems > is read_while_writer is global options. we can’t set it differently for each > remap entry by conf_remap. > So the downloading of Big file(not mp4 file) gives overhead to origin server > because read_while_writer is off. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2312) API stable: move TS_HRTIME_* from experimental.h to ts.h
[ https://issues.apache.org/jira/browse/TS-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-2312: -- Affects Version/s: 4.1.0 Fix Version/s: 5.0.0 > API stable: move TS_HRTIME_* from experimental.h to ts.h > > > Key: TS-2312 > URL: https://issues.apache.org/jira/browse/TS-2312 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Affects Versions: 4.1.0 >Reporter: Zhao Yongming > Fix For: 5.0.0 > > > as wished from TS-2200 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2312) API stable: move TS_HRTIME_* from experimental.h to ts.h
Zhao Yongming created TS-2312: - Summary: API stable: move TS_HRTIME_* from experimental.h to ts.h Key: TS-2312 URL: https://issues.apache.org/jira/browse/TS-2312 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Zhao Yongming as wished from TS-2200 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungwoo Lee updated TS-2307: Description: 1. Precondition - Upload file such as video or music file on Origin server - On Chrome, access to the content file - Repeat followings -- Delete the cache of Chrome -- Refresh( press F5 ) 2. Result - Chrome does not play the content. 3. Cause - When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) -- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) -- The if_value points the string of value of If-Range 4. Expected Behaviour - Video and music file will be played in all the time on all case. -- When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. was: 1. Precondition - Upload file such as video or music file on Origin server - On Chrome, access to the content file - Repeat followings -- Delete the cache of Chrome -- Refresh( press F5 ) 2. Result - Chrome does not play the content. 3. Cause - When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour - Video and music file will be played in all the time on all case. - When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > Labels: A > Fix For: 4.2.0 > > > 1. Precondition > - Upload file such as video or music file on Origin server > - On Chrome, access to the content file > - Repeat followings > -- Delete the cache of Chrome > -- Refresh( press F5 ) > 2. Result > - Chrome does not play the content. > 3. Cause > - When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the value of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >-- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >-- The if_value points the string of value of If-Range > 4. Expected Behaviour > - Video and music file will be played in all the time on all case. > -- When the value of If-Range is ETAG and is matched with ETAG of header of > cached content , response should include the header related with range > request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungwoo Lee updated TS-2307: Description: 1. Precondition - Upload file such as video or music file on Origin server - On Chrome, access to the content file - Repeat followings -- Delete the cache of Chrome -- Refresh( press F5 ) 2. Result - Chrome does not play the content. 3. Cause - When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour - Video and music file will be played in all the time on all case. - When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. was: 1. Precondition - Upload file such as video or music file on Origin server - On Chrome, access to the content file - Repeat followings - Delete the cache of Chrome - Refresh( press F5 ) 2. Result - Chrome does not play the content. 3. Cause - When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour - Video and music file will be played in all the time on all case. - When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > Labels: A > Fix For: 4.2.0 > > > 1. Precondition > - Upload file such as video or music file on Origin server > - On Chrome, access to the content file > - Repeat followings > -- Delete the cache of Chrome > -- Refresh( press F5 ) > 2. Result > - Chrome does not play the content. > 3. Cause > - When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the value of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >- The if_value points the string of value of If-Range > 4. Expected Behaviour > - Video and music file will be played in all the time on all case. > - When the value of If-Range is ETAG and is matched with ETAG of header of > cached content , response should include the header related with range > request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungwoo Lee updated TS-2307: Description: 1. Precondition - Upload file such as video or music file on Origin server - On Chrome, access to the content file - Repeat followings - Delete the cache of Chrome - Refresh( press F5 ) 2. Result - Chrome does not play the content. 3. Cause - When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour - Video and music file will be played in all the time on all case. - When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. was: 1. Precondition – Upload file such as video or music file on Origin server – On Chrome, access to the content file – Repeat followings – Delete the cache of Chrome – Refresh( press F5 ) 2. Result – Chrome does not play the content. 3. Cause – When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour – Video and music file will be played in all the time on all case. – When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > Labels: A > Fix For: 4.2.0 > > > 1. Precondition > - Upload file such as video or music file on Origin server > - On Chrome, access to the content file > - Repeat followings >- Delete the cache of Chrome >- Refresh( press F5 ) > 2. Result > - Chrome does not play the content. > 3. Cause > - When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the value of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >- The if_value points the string of value of If-Range > 4. Expected Behaviour > - Video and music file will be played in all the time on all case. > - When the value of If-Range is ETAG and is matched with ETAG of header of > cached content , response should include the header related with range > request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TS-2311) ESI plugin: Support responses that are of other text content type as well as non-200 status response
[ https://issues.apache.org/jira/browse/TS-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-2311: - Assignee: Yu Qing > ESI plugin: Support responses that are of other text content type as well as > non-200 status response > > > Key: TS-2311 > URL: https://issues.apache.org/jira/browse/TS-2311 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Kit Chan >Assignee: Yu Qing > Attachments: 2311_patch.diff > > > We want to enhance the ESI plugin so that we can support transformation for > other text content-type such as javascript. We also want to enable ESI > transformation for non-200 response (e.g. 404) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2115) buffer_upload hard-codes "nobody" user/group
[ https://issues.apache.org/jira/browse/TS-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810842#comment-13810842 ] ASF subversion and git services commented on TS-2115: - Commit ebb5e305b15d171d24dfa172eb1eaf73c09e948f in branch refs/heads/master from [~kichan] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ebb5e30 ] TS-2115 buffer_upload hard-codes "nobody" user/group. > buffer_upload hard-codes "nobody" user/group > > > Key: TS-2115 > URL: https://issues.apache.org/jira/browse/TS-2115 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Igor Galić >Assignee: Leif Hedstrom > Fix For: 4.1.0 > > Attachments: 2115_patch.diff > > > When creating a directory on disk to buffer uploads, the buffer_upload > hard-codes the nobody/group - this is probably a bad idea.. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TS-2115) buffer_upload hard-codes "nobody" user/group
[ https://issues.apache.org/jira/browse/TS-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2115: - Assignee: Leif Hedstrom (was: Kit Chan) > buffer_upload hard-codes "nobody" user/group > > > Key: TS-2115 > URL: https://issues.apache.org/jira/browse/TS-2115 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Igor Galić >Assignee: Leif Hedstrom > Fix For: 4.1.0 > > Attachments: 2115_patch.diff > > > When creating a directory on disk to buffer uploads, the buffer_upload > hard-codes the nobody/group - this is probably a bad idea.. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2115) buffer_upload hard-codes "nobody" user/group
[ https://issues.apache.org/jira/browse/TS-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2115: -- Fix Version/s: (was: sometime) 4.1.0 > buffer_upload hard-codes "nobody" user/group > > > Key: TS-2115 > URL: https://issues.apache.org/jira/browse/TS-2115 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Igor Galić >Assignee: Leif Hedstrom > Fix For: 4.1.0 > > Attachments: 2115_patch.diff > > > When creating a directory on disk to buffer uploads, the buffer_upload > hard-codes the nobody/group - this is probably a bad idea.. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2115) buffer_upload hard-codes "nobody" user/group
[ https://issues.apache.org/jira/browse/TS-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan updated TS-2115: - Attachment: 2115_patch.diff Here is the patch for this issue > buffer_upload hard-codes "nobody" user/group > > > Key: TS-2115 > URL: https://issues.apache.org/jira/browse/TS-2115 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Igor Galić >Assignee: Kit Chan > Fix For: sometime > > Attachments: 2115_patch.diff > > > When creating a directory on disk to buffer uploads, the buffer_upload > hard-codes the nobody/group - this is probably a bad idea.. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2311) ESI plugin: Support responses that are of other text content type as well as non-200 status response
Kit Chan created TS-2311: Summary: ESI plugin: Support responses that are of other text content type as well as non-200 status response Key: TS-2311 URL: https://issues.apache.org/jira/browse/TS-2311 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Kit Chan Attachments: 2311_patch.diff We want to enhance the ESI plugin so that we can support transformation for other text content-type such as javascript. We also want to enable ESI transformation for non-200 response (e.g. 404) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2311) ESI plugin: Support responses that are of other text content type as well as non-200 status response
[ https://issues.apache.org/jira/browse/TS-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan updated TS-2311: - Attachment: 2311_patch.diff Here is the patch for this. > ESI plugin: Support responses that are of other text content type as well as > non-200 status response > > > Key: TS-2311 > URL: https://issues.apache.org/jira/browse/TS-2311 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Kit Chan > Attachments: 2311_patch.diff > > > We want to enhance the ESI plugin so that we can support transformation for > other text content-type such as javascript. We also want to enable ESI > transformation for non-200 response (e.g. 404) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1955) read_while_writer sends wrong response for range request.
[
https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810733#comment-13810733
]
Leif Hedstrom commented on TS-1955:
---
tracing it, I see this (which explains why it's setting the CL: as it is):
{code}
[Oct 31 15:32:09.380] Server {0x7f5729d4f700} DEBUG: (http_trans)
[build_response_from_cache] Match! Serving full document.
[Oct 31 15:32:09.380] Server {0x7f5729d4f700} DEBUG: (http_trans) Unable to
accelerate range request, fallback to transform
[Oct 31 15:32:09.380] Server {0x7f5729d4f700} DEBUG: (http_trans)
RangeTransform creation finishes
[Oct 31 15:32:09.380] Server {0x7f572a254700} DEBUG: (http_trans)
[handle_content_length_header] RESPONSE cont len in hdr is 1073741835
{code}
> read_while_writer sends wrong response for range request.
> -
>
> Key: TS-1955
> URL: https://issues.apache.org/jira/browse/TS-1955
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.2.4
>Reporter: jaekyung oh
>Assignee: Alan M. Carroll
> Labels: range
> Fix For: 4.2.0
>
>
> Basically read_while_writer works fine when ATS handles normal file.
> In progressive download and playback of mp4 in which moov atom is placed at
> the end of the file, ATS makes and returns wrong response for range request
> from unfulfilled cache when read_while_writer is 1.
> In origin, apache has h264 streaming module. Everything is ok whether the
> moov atom is placed at the beginning of the file or not in origin except a
> range request happens with read_while_writer.
> Mostly our customer’s contents placed moov atom at the end of the file and in
> the case movie player stops playing when it seek somewhere in the movie.
> to check if read_while_writer works fine,
> 1. prepare a mp4 file whose moov atom is placed at the end of the file.
> 2. curl --range - http://www.test.com/mp4/test.mp4 1>
> no_cache_from_origin
> 3. wget http://www.test.com/mp4/test.mp4
> 4. right after wget, execute “curl --range -
> http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal
> (the point is sending range request while ATS is still downloading)
> 5. after wget gets done, curl --range -
> http://www.test.com/mp4/test.mp4 1> from_cache
> 6. you can check compare those files by bindiff.
> The response from origin(no_cache_from_origin) for the range request is
> exactly same to from_cache resulted from #5's range request. but
> from_read_while_writer from #4 is totally different from others.
> i think a range request should be forwarded to origin server if it can’t find
> the content with the offset in cache even if the read_while_writer is on,
> instead ATS makes(from where?) and sends wrong response. (In squid.log it
> indicates TCP_HIT)
> That’s why a movie player stops when it seeks right after the movie starts.
> Well. we turned off read_while_writer and movie play is ok but the problems
> is read_while_writer is global options. we can’t set it differently for each
> remap entry by conf_remap.
> So the downloading of Big file(not mp4 file) gives overhead to origin server
> because read_while_writer is off.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-1955) read_while_writer sends wrong response for range request.
[
https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810712#comment-13810712
]
Leif Hedstrom commented on TS-1955:
---
Ok, I've tested this with v4.1.0 ("RC candidate"), and it's definitely very
broken. Here's what's wrong:
1) It will try to serve it out of the partially written cache. This means that
it'll hang until the part that it needs is actually written to cache. This on
it's own is both good and bad, but probably should be configurable.
2) What's particularly bad is that it returns the completely wrong
Content-Length: header :-/. E.g.
{code}
Content-Range: bytes 1073741824-1073741834/1073741835
Content-Length: 1073741835
Age: 5
Connection: keep-alive
Last Bytes
{code}
Note how it got the Content-Range: right, and it returns the right body ("Last
Bytes" is the last 11 bytes. But, I expect the response to have a
{code}
Content-Length: 11
{code}
Broken!
3) As a side effect of 2) , some clients will now hang on this. This is because
it's telling us that we should see a very large object (per the
Content-Length: header), but it's only sending 11 bytes (as it should). Fixing
#2 will fix #3, I'm sure.
So, I think at a minimum, we need to fix 2) above. Ideally, we also make an
addition such that the owner of the ATS box can specify if request that can't
(currently) be filled out of a read_while_write cache goes straight to origin.
But I can see a use case for both behavior, honestly.
> read_while_writer sends wrong response for range request.
> -
>
> Key: TS-1955
> URL: https://issues.apache.org/jira/browse/TS-1955
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.2.4
>Reporter: jaekyung oh
>Assignee: Alan M. Carroll
> Labels: range
> Fix For: 4.2.0
>
>
> Basically read_while_writer works fine when ATS handles normal file.
> In progressive download and playback of mp4 in which moov atom is placed at
> the end of the file, ATS makes and returns wrong response for range request
> from unfulfilled cache when read_while_writer is 1.
> In origin, apache has h264 streaming module. Everything is ok whether the
> moov atom is placed at the beginning of the file or not in origin except a
> range request happens with read_while_writer.
> Mostly our customer’s contents placed moov atom at the end of the file and in
> the case movie player stops playing when it seek somewhere in the movie.
> to check if read_while_writer works fine,
> 1. prepare a mp4 file whose moov atom is placed at the end of the file.
> 2. curl --range - http://www.test.com/mp4/test.mp4 1>
> no_cache_from_origin
> 3. wget http://www.test.com/mp4/test.mp4
> 4. right after wget, execute “curl --range -
> http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal
> (the point is sending range request while ATS is still downloading)
> 5. after wget gets done, curl --range -
> http://www.test.com/mp4/test.mp4 1> from_cache
> 6. you can check compare those files by bindiff.
> The response from origin(no_cache_from_origin) for the range request is
> exactly same to from_cache resulted from #5's range request. but
> from_read_while_writer from #4 is totally different from others.
> i think a range request should be forwarded to origin server if it can’t find
> the content with the offset in cache even if the read_while_writer is on,
> instead ATS makes(from where?) and sends wrong response. (In squid.log it
> indicates TCP_HIT)
> That’s why a movie player stops when it seeks right after the movie starts.
> Well. we turned off read_while_writer and movie play is ok but the problems
> is read_while_writer is global options. we can’t set it differently for each
> remap entry by conf_remap.
> So the downloading of Big file(not mp4 file) gives overhead to origin server
> because read_while_writer is off.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TS-2310) document the map_with_recv_port remap rule type
James Peach created TS-2310: --- Summary: document the map_with_recv_port remap rule type Key: TS-2310 URL: https://issues.apache.org/jira/browse/TS-2310 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: James Peach TS-876 introduced map_with_recv_port into remap.config but documented it only in the default remap.config file. We should document this in the official documentation. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TS-2309) Allow mod_generator plugin for lighted to accept "SI" postfixes
[ https://issues.apache.org/jira/browse/TS-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2309: - Assignee: Leif Hedstrom > Allow mod_generator plugin for lighted to accept "SI" postfixes > --- > > Key: TS-2309 > URL: https://issues.apache.org/jira/browse/TS-2309 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 4.2.0 > > > Such as > http://loki.ogre.com:8080/1024M-69-0-cache -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2309) Allow mod_generator plugin for lighted to accept "SI" postfixes
[ https://issues.apache.org/jira/browse/TS-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2309: -- Fix Version/s: 4.2.0 > Allow mod_generator plugin for lighted to accept "SI" postfixes > --- > > Key: TS-2309 > URL: https://issues.apache.org/jira/browse/TS-2309 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Leif Hedstrom > Fix For: 4.2.0 > > > Such as > http://loki.ogre.com:8080/1024M-69-0-cache -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2309) Allow mod_generator plugin for lighted to accept "SI" postfixes
Leif Hedstrom created TS-2309: - Summary: Allow mod_generator plugin for lighted to accept "SI" postfixes Key: TS-2309 URL: https://issues.apache.org/jira/browse/TS-2309 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Such as http://loki.ogre.com:8080/1024M-69-0-cache -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2307: Labels: A (was: ) > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > Labels: A > Fix For: 4.2.0 > > > 1. Precondition > – Upload file such as video or music file on Origin server > – On Chrome, access to the content file > – Repeat followings > – Delete the cache of Chrome > – Refresh( press F5 ) > 2. Result > – Chrome does not play the content. > 3. Cause > – When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the value of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >- The if_value points the string of value of If-Range > 4. Expected Behaviour > – Video and music file will be played in all the time on all case. > – When the value of If-Range is ETAG and is matched with ETAG of header of > cached content , response should include the header related with range > request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reopened TS-2306: - Assignee: (was: James Peach) Reopening, since the fix for TS-2211 apparently does not address this. > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran > Fix For: 4.2.0 > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for https://localhost:8080/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8081/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2306. - Resolution: Duplicate Assignee: James Peach Pretty sure this is a duplicate of TS-2211 > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran >Assignee: James Peach > Fix For: 4.2.0 > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for https://localhost:8080/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8081/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2308) includedir in config.layout is not used
[ https://issues.apache.org/jira/browse/TS-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2308: -- Fix Version/s: 4.2.0 > includedir in config.layout is not used > --- > > Key: TS-2308 > URL: https://issues.apache.org/jira/browse/TS-2308 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Craig Forbes > Fix For: 4.2.0 > > > The includedir is hard coded as $(prefix)/include/ts in: > mgmt/api/include/Makefile.am > proxy/api/ts/Makefile.am > so the value set in config.layout is ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2308) includedir in config.layout is not used
Craig Forbes created TS-2308: Summary: includedir in config.layout is not used Key: TS-2308 URL: https://issues.apache.org/jira/browse/TS-2308 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Craig Forbes The includedir is hard coded as $(prefix)/include/ts in: mgmt/api/include/Makefile.am proxy/api/ts/Makefile.am so the value set in config.layout is ignored. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2008) Cache control with multiple suffixes
[ https://issues.apache.org/jira/browse/TS-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810417#comment-13810417 ] ASF subversion and git services commented on TS-2008: - Commit 84634608b3c4cb87cc7b94ca81d57000c3191ef5 in branch refs/heads/master from [~bettydreamit] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8463460 ] TS-2008: Cache control with multiple suffixes. > Cache control with multiple suffixes > > > Key: TS-2008 > URL: https://issues.apache.org/jira/browse/TS-2008 > Project: Traffic Server > Issue Type: New Feature > Components: Cache, HTTP >Affects Versions: 3.3.4 >Reporter: bettydramit >Assignee: James Peach > Fix For: 5.0.0 > > Attachments: ts-2008-v3.patch, ts-2008-v4.patch > > > if you want to control on ver many suffix in cache.config: jpeg js ... you > need to specify: > dest_domain=www.test.com suffix=jpeg ttl-in-cache=1m > dest_domain=www.test.com suffix=js ttl-in-cache=1m > ... > and we can change to : > dest_domain=www.test.com suffix=jpeg,js,css,html ttl-in-cache=1m -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2247) ua close time in milestone may not set
[ https://issues.apache.org/jira/browse/TS-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810413#comment-13810413 ] ASF subversion and git services commented on TS-2247: - Commit d1006996b3f0db0fe8f91ee9733ba68bf22a3a40 in branch refs/heads/master from [~gary1943] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d100699 ] TS-2247: ua close time in milestone may not set > ua close time in milestone may not set > -- > > Key: TS-2247 > URL: https://issues.apache.org/jira/browse/TS-2247 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, Logging, Stats >Reporter: Zhao Yongming >Assignee: portl4t > Fix For: 4.2.0 > > Attachments: time.patch > > > that will cause many problems such as create some negative stats on > transaction time. > LiGang have a patch for that. > which maybe related to TS-2238 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2008) Cache control with multiple suffixes
[ https://issues.apache.org/jira/browse/TS-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810406#comment-13810406 ] James Peach commented on TS-2008: - Let's commit this! > Cache control with multiple suffixes > > > Key: TS-2008 > URL: https://issues.apache.org/jira/browse/TS-2008 > Project: Traffic Server > Issue Type: New Feature > Components: Cache, HTTP >Affects Versions: 3.3.4 >Reporter: bettydramit >Assignee: James Peach > Fix For: 5.0.0 > > Attachments: ts-2008-v3.patch, ts-2008-v4.patch > > > if you want to control on ver many suffix in cache.config: jpeg js ... you > need to specify: > dest_domain=www.test.com suffix=jpeg ttl-in-cache=1m > dest_domain=www.test.com suffix=js ttl-in-cache=1m > ... > and we can change to : > dest_domain=www.test.com suffix=jpeg,js,css,html ttl-in-cache=1m -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2302) log collation causes error logging to stop
[
https://issues.apache.org/jira/browse/TS-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810325#comment-13810325
]
ASF subversion and git services commented on TS-2302:
-
Commit 538eba5c078f6b14cbd3b6e6887da669fd7205c9 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=538eba5 ]
TS-2302: convert Log::error_log into a generic prefedined LogObject
Initialize LogObject pointer arrays to NULL before using them. Use
const accessors to get to LogObject::m_name. Sprinkle more const
through the logging API.
Use the standard ConfigProcessor pattern to reload LogConfig. This
removes part of the need to keep a global array of inactive LogObjects.
Using newDeleter() in LogObjectManager::unmanage_api_object(),
removes the rest of this need. Now the whole Log::inactive_object
array can be removed.
Using the ConfigProcessor reload pattern also fixes a memory leak,
since previously the old LogConfig object was never freed.
Fix LogObjectManager::transfer_objects(). Previously, matching
objects would be assigned to the new manager, but also left on the
old manager, leaving it unclear who should have ownership of which
log object.
Move a bunch of inline LogObjectManager methods to the .cc file
where they are mre easily accessible. None of these are called often
enough to justify being inline.
The global Log::error_log is now managed my the log object manager
just like other predefined log objects. This lets us remove code
in a number of places that were treating is specially. It also fixes
a log collation bug in LogConfig::init(). This function attempts
to figure out which log space threshold to use. If all the logs are
being collated, then it used the orphan space value. The problem
is that the error log was never checked (and it is never collated),
so enabling log collation and making a poor choice of space thresholds
causes error logging to stop. Like the rest of the bugs here, the
fix is to stop treating the error log specially, and bring it into
the log object manager.
> log collation causes error logging to stop
> --
>
> Key: TS-2302
> URL: https://issues.apache.org/jira/browse/TS-2302
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Quality
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.1.0
>
>
> When we started using the log collation ATS stopped writing to the errors.log
> file. Traffic Server thinks that the configured log space is exhausted:
> {code}
> [Sep 18 23:00:40.817] Server {0x2b1bdcc51700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 18 23:01:45.008] Server {0x2b05c4e93700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 19 20:57:05.766] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(1832) bytes
> [Sep 19 20:57:15.743] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(4360) bytes
> {code}
> {{LogConfig::update_space_used()}} emits the exhaustion message when
> {{LogConfig::space_to_write(headroom)}} fails:
> {code}
> $ sudo /opt/bazinga/bin/traffic_line -r proxy.config.log.max_space_mb_headroom
> 1000
> $ sudo gdb -p 28375
> ...
> (gdb) p (bool)(Log::config->space_to_write((int64_t)(1000*1024)))
> $1 = false
> (gdb) p *(Log::config)
> $1 = {initialized = true, reconfiguration_needed = false,
> logging_space_exhausted = true, m_space_used = 28313954,
> m_partition_space_left = 46870138880,
> roll_log_files_now = false, log_object_manager = {_objects =
> 0x2b1b68758d00, _numObjects = 1, _maxObjects = 8, _APIobjects =
> 0x2b1b68758d50, _numAPIobjects = 0,
> _maxAPIobjects = 8, _APImutex = 0x2b1b6874ee40}, global_filter_list =
> {m_filter_list = {> = {head = 0x0}, tail
> = 0x0},
> m_does_conjunction = true}, global_format_list = {m_format_list =
> {> = {head = 0x2b1b68764810}, tail =
> 0x2b1b68767e10}},
> log_buffer_size = 9216, max_secs_per_buffer = 5, max_space_mb_for_logs =
> 102400, max_space_mb_for_orphan_logs = 25, max_space_mb_headroom = 1000,
> logfile_perm = 420, squid_log_enabled = false, xuid_logging_enabled = true,
> squid_log_is_ascii = false, common_log_enabled = false, common_log_is_ascii =
> true,
> extended_log_enabled = false, extended_log_is_ascii = false,
> extended2_log_enabled = false, extended2_log_is_ascii = true,
> separate_icp_logs = false,
> separate_host_logs = false, collation_mode = 2, collation_port = 8085,
> collation_host_tagged = false, collation_preproc_threads = 1,
> collation_retry_sec = 5,
> collation_max_send_buffers = 16, rolling_enabled = 2, rolling_interval_sec
> = 8640
[jira] [Commented] (TS-2302) log collation causes error logging to stop
[
https://issues.apache.org/jira/browse/TS-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810326#comment-13810326
]
ASF subversion and git services commented on TS-2302:
-
Commit b4ee382d35b3d71aad90363069195358198ee259 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b4ee382 ]
TS-2302: allow predefined formats to specify log collation support
Directly specify the log file format in the predefined format
structure. Specify whether this predefined log format supports log
collation or not. Currently the error log does not support collation.
> log collation causes error logging to stop
> --
>
> Key: TS-2302
> URL: https://issues.apache.org/jira/browse/TS-2302
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Quality
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.1.0
>
>
> When we started using the log collation ATS stopped writing to the errors.log
> file. Traffic Server thinks that the configured log space is exhausted:
> {code}
> [Sep 18 23:00:40.817] Server {0x2b1bdcc51700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 18 23:01:45.008] Server {0x2b05c4e93700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 19 20:57:05.766] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(1832) bytes
> [Sep 19 20:57:15.743] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(4360) bytes
> {code}
> {{LogConfig::update_space_used()}} emits the exhaustion message when
> {{LogConfig::space_to_write(headroom)}} fails:
> {code}
> $ sudo /opt/bazinga/bin/traffic_line -r proxy.config.log.max_space_mb_headroom
> 1000
> $ sudo gdb -p 28375
> ...
> (gdb) p (bool)(Log::config->space_to_write((int64_t)(1000*1024)))
> $1 = false
> (gdb) p *(Log::config)
> $1 = {initialized = true, reconfiguration_needed = false,
> logging_space_exhausted = true, m_space_used = 28313954,
> m_partition_space_left = 46870138880,
> roll_log_files_now = false, log_object_manager = {_objects =
> 0x2b1b68758d00, _numObjects = 1, _maxObjects = 8, _APIobjects =
> 0x2b1b68758d50, _numAPIobjects = 0,
> _maxAPIobjects = 8, _APImutex = 0x2b1b6874ee40}, global_filter_list =
> {m_filter_list = {> = {head = 0x0}, tail
> = 0x0},
> m_does_conjunction = true}, global_format_list = {m_format_list =
> {> = {head = 0x2b1b68764810}, tail =
> 0x2b1b68767e10}},
> log_buffer_size = 9216, max_secs_per_buffer = 5, max_space_mb_for_logs =
> 102400, max_space_mb_for_orphan_logs = 25, max_space_mb_headroom = 1000,
> logfile_perm = 420, squid_log_enabled = false, xuid_logging_enabled = true,
> squid_log_is_ascii = false, common_log_enabled = false, common_log_is_ascii =
> true,
> extended_log_enabled = false, extended_log_is_ascii = false,
> extended2_log_enabled = false, extended2_log_is_ascii = true,
> separate_icp_logs = false,
> separate_host_logs = false, collation_mode = 2, collation_port = 8085,
> collation_host_tagged = false, collation_preproc_threads = 1,
> collation_retry_sec = 5,
> collation_max_send_buffers = 16, rolling_enabled = 2, rolling_interval_sec
> = 86400, rolling_offset_hr = 0, rolling_size_mb = 10240,
> auto_delete_rolled_files = true, custom_logs_enabled = true,
> search_log_enabled = false, search_rolling_interval_sec = 86400,
> search_server_ip_addr = 0,
> search_server_port = 8080, search_top_sites = 100, search_log_filters =
> 0x0, search_url_filter = 0x0, search_log_file_one = 0x2b1b68758e00
> "search_log1",
> search_log_file_two = 0x2b1b68758e20 "search_log2", sampling_frequency = 1,
> file_stat_frequency = 32, space_used_frequency = 2, ascii_buffer_size =
> 36864,
> max_line_size = 9216, hostname = 0x2b1b68758f20 "localhost", logfile_dir =
> 0x2b1b6823fcd0 "/var/log/trafficserver", squid_log_name = 0x2b1b68240960
> "squid",
> squid_log_header = 0x0, common_log_name = 0x2b1b68225a90 "common",
> common_log_header = 0x0, extended_log_name = 0x2b1b682419f0 "extended",
> extended_log_header = 0x0, extended2_log_name = 0x2b1b6874f7b0 "extended2",
> extended2_log_header = 0x0, collation_host = 0x2b1b6874fe50 "none",
> collation_secret = 0x2b1b6874fa20 "Aapl_Baz1ng4!", xml_config_file =
> 0x2b1b68758da0 "logs_xml.config", hosts_config_file = 0x2b1b68758dc0
> "log_hosts.config",
> use_orphan_log_space_value = true, m_log_collation_accept = 0x0,
> m_dir_entry = 0x2b1b68769e30, m_pDir = 0x0, m_disk_full = true, m_disk_low =
> false,
> m_partition_full = false, m_partition_low = false,
> m_log_directory_inaccessible = false}
> {code}
>
[jira] [Commented] (TS-2302) log collation causes error logging to stop
[
https://issues.apache.org/jira/browse/TS-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810323#comment-13810323
]
ASF subversion and git services commented on TS-2302:
-
Commit 48b61b338c2410f5c802a79c0562615db89ab2c0 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=48b61b3 ]
TS-2302: rename log format and file type constants for clarity
> log collation causes error logging to stop
> --
>
> Key: TS-2302
> URL: https://issues.apache.org/jira/browse/TS-2302
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Quality
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.1.0
>
>
> When we started using the log collation ATS stopped writing to the errors.log
> file. Traffic Server thinks that the configured log space is exhausted:
> {code}
> [Sep 18 23:00:40.817] Server {0x2b1bdcc51700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 18 23:01:45.008] Server {0x2b05c4e93700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 19 20:57:05.766] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(1832) bytes
> [Sep 19 20:57:15.743] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(4360) bytes
> {code}
> {{LogConfig::update_space_used()}} emits the exhaustion message when
> {{LogConfig::space_to_write(headroom)}} fails:
> {code}
> $ sudo /opt/bazinga/bin/traffic_line -r proxy.config.log.max_space_mb_headroom
> 1000
> $ sudo gdb -p 28375
> ...
> (gdb) p (bool)(Log::config->space_to_write((int64_t)(1000*1024)))
> $1 = false
> (gdb) p *(Log::config)
> $1 = {initialized = true, reconfiguration_needed = false,
> logging_space_exhausted = true, m_space_used = 28313954,
> m_partition_space_left = 46870138880,
> roll_log_files_now = false, log_object_manager = {_objects =
> 0x2b1b68758d00, _numObjects = 1, _maxObjects = 8, _APIobjects =
> 0x2b1b68758d50, _numAPIobjects = 0,
> _maxAPIobjects = 8, _APImutex = 0x2b1b6874ee40}, global_filter_list =
> {m_filter_list = {> = {head = 0x0}, tail
> = 0x0},
> m_does_conjunction = true}, global_format_list = {m_format_list =
> {> = {head = 0x2b1b68764810}, tail =
> 0x2b1b68767e10}},
> log_buffer_size = 9216, max_secs_per_buffer = 5, max_space_mb_for_logs =
> 102400, max_space_mb_for_orphan_logs = 25, max_space_mb_headroom = 1000,
> logfile_perm = 420, squid_log_enabled = false, xuid_logging_enabled = true,
> squid_log_is_ascii = false, common_log_enabled = false, common_log_is_ascii =
> true,
> extended_log_enabled = false, extended_log_is_ascii = false,
> extended2_log_enabled = false, extended2_log_is_ascii = true,
> separate_icp_logs = false,
> separate_host_logs = false, collation_mode = 2, collation_port = 8085,
> collation_host_tagged = false, collation_preproc_threads = 1,
> collation_retry_sec = 5,
> collation_max_send_buffers = 16, rolling_enabled = 2, rolling_interval_sec
> = 86400, rolling_offset_hr = 0, rolling_size_mb = 10240,
> auto_delete_rolled_files = true, custom_logs_enabled = true,
> search_log_enabled = false, search_rolling_interval_sec = 86400,
> search_server_ip_addr = 0,
> search_server_port = 8080, search_top_sites = 100, search_log_filters =
> 0x0, search_url_filter = 0x0, search_log_file_one = 0x2b1b68758e00
> "search_log1",
> search_log_file_two = 0x2b1b68758e20 "search_log2", sampling_frequency = 1,
> file_stat_frequency = 32, space_used_frequency = 2, ascii_buffer_size =
> 36864,
> max_line_size = 9216, hostname = 0x2b1b68758f20 "localhost", logfile_dir =
> 0x2b1b6823fcd0 "/var/log/trafficserver", squid_log_name = 0x2b1b68240960
> "squid",
> squid_log_header = 0x0, common_log_name = 0x2b1b68225a90 "common",
> common_log_header = 0x0, extended_log_name = 0x2b1b682419f0 "extended",
> extended_log_header = 0x0, extended2_log_name = 0x2b1b6874f7b0 "extended2",
> extended2_log_header = 0x0, collation_host = 0x2b1b6874fe50 "none",
> collation_secret = 0x2b1b6874fa20 "Aapl_Baz1ng4!", xml_config_file =
> 0x2b1b68758da0 "logs_xml.config", hosts_config_file = 0x2b1b68758dc0
> "log_hosts.config",
> use_orphan_log_space_value = true, m_log_collation_accept = 0x0,
> m_dir_entry = 0x2b1b68769e30, m_pDir = 0x0, m_disk_full = true, m_disk_low =
> false,
> m_partition_full = false, m_partition_low = false,
> m_log_directory_inaccessible = false}
> {code}
> Note that use_orphan_log_space_value = true.
> In proxy/logging/LogConfig.h:
> {code}
>169
>170int get_max_space_mb() {
>171 return (use_orphan_log_space_value ? max_space_mb_for_o
[jira] [Commented] (TS-2302) log collation causes error logging to stop
[
https://issues.apache.org/jira/browse/TS-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810324#comment-13810324
]
ASF subversion and git services commented on TS-2302:
-
Commit 3020176c3fe4c844c4784345b183424e7d0c3c14 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3020176 ]
TS-2302: split LogConfig::create_predefined_objects_with_filter
Split the guts of LogConfig::create_predefined_objects_with_filter
into LogConfig::create_predefined_object so that we can later use
it to create an error log object.
> log collation causes error logging to stop
> --
>
> Key: TS-2302
> URL: https://issues.apache.org/jira/browse/TS-2302
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Quality
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.1.0
>
>
> When we started using the log collation ATS stopped writing to the errors.log
> file. Traffic Server thinks that the configured log space is exhausted:
> {code}
> [Sep 18 23:00:40.817] Server {0x2b1bdcc51700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 18 23:01:45.008] Server {0x2b05c4e93700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 19 20:57:05.766] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(1832) bytes
> [Sep 19 20:57:15.743] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(4360) bytes
> {code}
> {{LogConfig::update_space_used()}} emits the exhaustion message when
> {{LogConfig::space_to_write(headroom)}} fails:
> {code}
> $ sudo /opt/bazinga/bin/traffic_line -r proxy.config.log.max_space_mb_headroom
> 1000
> $ sudo gdb -p 28375
> ...
> (gdb) p (bool)(Log::config->space_to_write((int64_t)(1000*1024)))
> $1 = false
> (gdb) p *(Log::config)
> $1 = {initialized = true, reconfiguration_needed = false,
> logging_space_exhausted = true, m_space_used = 28313954,
> m_partition_space_left = 46870138880,
> roll_log_files_now = false, log_object_manager = {_objects =
> 0x2b1b68758d00, _numObjects = 1, _maxObjects = 8, _APIobjects =
> 0x2b1b68758d50, _numAPIobjects = 0,
> _maxAPIobjects = 8, _APImutex = 0x2b1b6874ee40}, global_filter_list =
> {m_filter_list = {> = {head = 0x0}, tail
> = 0x0},
> m_does_conjunction = true}, global_format_list = {m_format_list =
> {> = {head = 0x2b1b68764810}, tail =
> 0x2b1b68767e10}},
> log_buffer_size = 9216, max_secs_per_buffer = 5, max_space_mb_for_logs =
> 102400, max_space_mb_for_orphan_logs = 25, max_space_mb_headroom = 1000,
> logfile_perm = 420, squid_log_enabled = false, xuid_logging_enabled = true,
> squid_log_is_ascii = false, common_log_enabled = false, common_log_is_ascii =
> true,
> extended_log_enabled = false, extended_log_is_ascii = false,
> extended2_log_enabled = false, extended2_log_is_ascii = true,
> separate_icp_logs = false,
> separate_host_logs = false, collation_mode = 2, collation_port = 8085,
> collation_host_tagged = false, collation_preproc_threads = 1,
> collation_retry_sec = 5,
> collation_max_send_buffers = 16, rolling_enabled = 2, rolling_interval_sec
> = 86400, rolling_offset_hr = 0, rolling_size_mb = 10240,
> auto_delete_rolled_files = true, custom_logs_enabled = true,
> search_log_enabled = false, search_rolling_interval_sec = 86400,
> search_server_ip_addr = 0,
> search_server_port = 8080, search_top_sites = 100, search_log_filters =
> 0x0, search_url_filter = 0x0, search_log_file_one = 0x2b1b68758e00
> "search_log1",
> search_log_file_two = 0x2b1b68758e20 "search_log2", sampling_frequency = 1,
> file_stat_frequency = 32, space_used_frequency = 2, ascii_buffer_size =
> 36864,
> max_line_size = 9216, hostname = 0x2b1b68758f20 "localhost", logfile_dir =
> 0x2b1b6823fcd0 "/var/log/trafficserver", squid_log_name = 0x2b1b68240960
> "squid",
> squid_log_header = 0x0, common_log_name = 0x2b1b68225a90 "common",
> common_log_header = 0x0, extended_log_name = 0x2b1b682419f0 "extended",
> extended_log_header = 0x0, extended2_log_name = 0x2b1b6874f7b0 "extended2",
> extended2_log_header = 0x0, collation_host = 0x2b1b6874fe50 "none",
> collation_secret = 0x2b1b6874fa20 "Aapl_Baz1ng4!", xml_config_file =
> 0x2b1b68758da0 "logs_xml.config", hosts_config_file = 0x2b1b68758dc0
> "log_hosts.config",
> use_orphan_log_space_value = true, m_log_collation_accept = 0x0,
> m_dir_entry = 0x2b1b68769e30, m_pDir = 0x0, m_disk_full = true, m_disk_low =
> false,
> m_partition_full = false, m_partition_low = false,
> m_log_directory_inaccessible = false}
> {code}
> Note that use_orphan_log_space_val
[jira] [Commented] (TS-2302) log collation causes error logging to stop
[
https://issues.apache.org/jira/browse/TS-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810327#comment-13810327
]
ASF subversion and git services commented on TS-2302:
-
Commit 7845084ea5f455f1cb6b7c9073f3135512d559fc in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7845084 ]
TS-2302: update CHANGES
> log collation causes error logging to stop
> --
>
> Key: TS-2302
> URL: https://issues.apache.org/jira/browse/TS-2302
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Quality
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.1.0
>
>
> When we started using the log collation ATS stopped writing to the errors.log
> file. Traffic Server thinks that the configured log space is exhausted:
> {code}
> [Sep 18 23:00:40.817] Server {0x2b1bdcc51700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 18 23:01:45.008] Server {0x2b05c4e93700} WARNING: Access logging to
> local log directory suspended - configured space allocation exhausted.
> [Sep 19 20:57:05.766] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(1832) bytes
> [Sep 19 20:57:15.743] Server {0x2b05c4c91700} NOTE: logging space exhausted,
> failed to write orphan file, drop(4360) bytes
> {code}
> {{LogConfig::update_space_used()}} emits the exhaustion message when
> {{LogConfig::space_to_write(headroom)}} fails:
> {code}
> $ sudo /opt/bazinga/bin/traffic_line -r proxy.config.log.max_space_mb_headroom
> 1000
> $ sudo gdb -p 28375
> ...
> (gdb) p (bool)(Log::config->space_to_write((int64_t)(1000*1024)))
> $1 = false
> (gdb) p *(Log::config)
> $1 = {initialized = true, reconfiguration_needed = false,
> logging_space_exhausted = true, m_space_used = 28313954,
> m_partition_space_left = 46870138880,
> roll_log_files_now = false, log_object_manager = {_objects =
> 0x2b1b68758d00, _numObjects = 1, _maxObjects = 8, _APIobjects =
> 0x2b1b68758d50, _numAPIobjects = 0,
> _maxAPIobjects = 8, _APImutex = 0x2b1b6874ee40}, global_filter_list =
> {m_filter_list = {> = {head = 0x0}, tail
> = 0x0},
> m_does_conjunction = true}, global_format_list = {m_format_list =
> {> = {head = 0x2b1b68764810}, tail =
> 0x2b1b68767e10}},
> log_buffer_size = 9216, max_secs_per_buffer = 5, max_space_mb_for_logs =
> 102400, max_space_mb_for_orphan_logs = 25, max_space_mb_headroom = 1000,
> logfile_perm = 420, squid_log_enabled = false, xuid_logging_enabled = true,
> squid_log_is_ascii = false, common_log_enabled = false, common_log_is_ascii =
> true,
> extended_log_enabled = false, extended_log_is_ascii = false,
> extended2_log_enabled = false, extended2_log_is_ascii = true,
> separate_icp_logs = false,
> separate_host_logs = false, collation_mode = 2, collation_port = 8085,
> collation_host_tagged = false, collation_preproc_threads = 1,
> collation_retry_sec = 5,
> collation_max_send_buffers = 16, rolling_enabled = 2, rolling_interval_sec
> = 86400, rolling_offset_hr = 0, rolling_size_mb = 10240,
> auto_delete_rolled_files = true, custom_logs_enabled = true,
> search_log_enabled = false, search_rolling_interval_sec = 86400,
> search_server_ip_addr = 0,
> search_server_port = 8080, search_top_sites = 100, search_log_filters =
> 0x0, search_url_filter = 0x0, search_log_file_one = 0x2b1b68758e00
> "search_log1",
> search_log_file_two = 0x2b1b68758e20 "search_log2", sampling_frequency = 1,
> file_stat_frequency = 32, space_used_frequency = 2, ascii_buffer_size =
> 36864,
> max_line_size = 9216, hostname = 0x2b1b68758f20 "localhost", logfile_dir =
> 0x2b1b6823fcd0 "/var/log/trafficserver", squid_log_name = 0x2b1b68240960
> "squid",
> squid_log_header = 0x0, common_log_name = 0x2b1b68225a90 "common",
> common_log_header = 0x0, extended_log_name = 0x2b1b682419f0 "extended",
> extended_log_header = 0x0, extended2_log_name = 0x2b1b6874f7b0 "extended2",
> extended2_log_header = 0x0, collation_host = 0x2b1b6874fe50 "none",
> collation_secret = 0x2b1b6874fa20 "Aapl_Baz1ng4!", xml_config_file =
> 0x2b1b68758da0 "logs_xml.config", hosts_config_file = 0x2b1b68758dc0
> "log_hosts.config",
> use_orphan_log_space_value = true, m_log_collation_accept = 0x0,
> m_dir_entry = 0x2b1b68769e30, m_pDir = 0x0, m_disk_full = true, m_disk_low =
> false,
> m_partition_full = false, m_partition_low = false,
> m_log_directory_inaccessible = false}
> {code}
> Note that use_orphan_log_space_value = true.
> In proxy/logging/LogConfig.h:
> {code}
>169
>170int get_max_space_mb() {
>171 return (use_orphan_log_space_value ? max_space_mb_for_orphan_logs
> : max_space_mb_for_logs);
[jira] [Commented] (TS-2202) remove manager error and fatal useless errno and error message
[ https://issues.apache.org/jira/browse/TS-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810320#comment-13810320 ] ASF subversion and git services commented on TS-2202: - Commit c2452f5fbfafab8291537ef8abd4ac2e75253c45 in branch refs/heads/master from [~happy_fish100] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c2452f5 ] TS-2202: remove manager error and fatal useless error message we should log errno and strerror(errno) only when errno != 0. the errno parameter should pass by the caller. functions mgmt_elog and mgmt_fatal changed > remove manager error and fatal useless errno and error message > -- > > Key: TS-2202 > URL: https://issues.apache.org/jira/browse/TS-2202 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.2.0 > > Attachments: > 0001-TS-2202-remove-manager-error-and-fatal-useless-error.patch > > > we should log errno and strerror(errno) only when errno != 0. > the errno parameter should pass by the caller. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810294#comment-13810294 ] Thach Tran edited comment on TS-2306 at 10/31/13 2:30 PM: -- Sorry, it's a typo. Edited. I mean the SSL connection to origin hangs while the non-SSL does not. was (Author: thachtran): Sorry, it's a typo. Edited. > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran > Fix For: 4.2.0 > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for https://localhost:8080/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8081/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810294#comment-13810294 ] Thach Tran commented on TS-2306: Sorry, it's a typo. Edited. > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran > Fix For: 4.2.0 > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for https://localhost:8080/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8081/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thach Tran updated TS-2306: --- Description: Setup: ATS in reverse proxy mode and Apache server in the backend to serve some very large test files (~10GB). Backend Apache server listens on both 80 for plain HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of 8080 and 8081): map http://localhost:8080/ http://localhost/ map http://localhost:8081/ https://localhost/ What I am seeing is request for https://localhost:8080/files/testfile10g.bin will hang very quickly without getting much data back while request for http://localhost:8081/files/testfile10g.bin will continue to download just fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) and it seems to work fine. I've disabled the caching (proxy.config.http.cache.http=0) in case it has something to do with that. I'm wondering if this is similar to TS-2211 but in reverse direction (client is non-SSL while origin connection is SSL). I've tested with trunk which includes a fix for TS-2211 but still be able to reproduce this. In my test setup both ATS and Apache are running on the same Linux Mint 13 box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. Any help would be much appreciated. was: Setup: ATS in reverse proxy mode and Apache server in the backend to serve some very large test files (~10GB). Backend Apache server listens on both 80 for plain HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of 8080 and 8081): map http://localhost:8080/ http://localhost/ map http://localhost:8081/ https://localhost/ What I am seeing is request for http://localhost:8080/files/testfile10g.bin will hang very quickly without getting much data back while request for http://localhost:8081/files/testfile10g.bin will continue to download just fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) and it seems to work fine. I've disabled the caching (proxy.config.http.cache.http=0) in case it has something to do with that. I'm wondering if this is similar to TS-2211 but in reverse direction (client is non-SSL while origin connection is SSL). I've tested with trunk which includes a fix for TS-2211 but still be able to reproduce this. In my test setup both ATS and Apache are running on the same Linux Mint 13 box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. Any help would be much appreciated. > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran > Fix For: 4.2.0 > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for https://localhost:8080/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8081/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810287#comment-13810287 ] Leif Hedstrom commented on TS-2306: --- I'm a little confused. You are saying the non-SSL connection to origin hangs, and the SSL one does not? > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran > Fix For: 4.2.0 > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for http://localhost:8080/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8081/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
[ https://issues.apache.org/jira/browse/TS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2306: -- Fix Version/s: 4.2.0 > Client connection hang while downloading big file from origin server over SSL > connection > > > Key: TS-2306 > URL: https://issues.apache.org/jira/browse/TS-2306 > Project: Traffic Server > Issue Type: Bug > Components: Network, SSL >Reporter: Thach Tran > Fix For: 4.2.0 > > > Setup: > ATS in reverse proxy mode and Apache server in the backend to serve some very > large test files (~10GB). Backend Apache server listens on both 80 for plain > HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of > 8080 and 8081): > map http://localhost:8080/ http://localhost/ > map http://localhost:8081/ https://localhost/ > What I am seeing is request for http://localhost:8080/files/testfile10g.bin > will hang very quickly without getting much data back while request for > http://localhost:8081/files/testfile10g.bin will continue to download just > fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) > and it seems to work fine. > I've disabled the caching (proxy.config.http.cache.http=0) in case it has > something to do with that. > I'm wondering if this is similar to TS-2211 but in reverse direction (client > is non-SSL while origin connection is SSL). I've tested with trunk which > includes a fix for TS-2211 but still be able to reproduce this. > In my test setup both ATS and Apache are running on the same Linux Mint 13 > box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. > Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2307: -- Fix Version/s: 4.2.0 > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > Fix For: 4.2.0 > > > 1. Precondition > – Upload file such as video or music file on Origin server > – On Chrome, access to the content file > – Repeat followings > – Delete the cache of Chrome > – Refresh( press F5 ) > 2. Result > – Chrome does not play the content. > 3. Cause > – When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the value of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >- The if_value points the string of value of If-Range > 4. Expected Behaviour > – Video and music file will be played in all the time on all case. > – When the value of If-Range is ETAG and is matched with ETAG of header of > cached content , response should include the header related with range > request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungwoo Lee updated TS-2307: Description: 1. Precondition – Upload file such as video or music file on Origin server – On Chrome, access to the content file – Repeat followings – Delete the cache of Chrome – Refresh( press F5 ) 2. Result – Chrome does not play the content. 3. Cause – When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the value of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour – Video and music file will be played in all the time on all case. – When the value of If-Range is ETAG and is matched with ETAG of header of cached content , response should include the header related with range request. was: 1. Precondition – Upload file such as video or music file on Origin server – On Chrome, access to the content file – Repeat followings – Delete the cache of Chrome – Refresh( press F5 ) 2. Result – Chrome does not play the content. 3. Cause – When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the valud of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour – Video and music file will be played in all the time on all case. – When the value of If-Range is ETAG and is matched with ETAG of cached content header, response should include the header related with range request > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > > 1. Precondition > – Upload file such as video or music file on Origin server > – On Chrome, access to the content file > – Repeat followings > – Delete the cache of Chrome > – Refresh( press F5 ) > 2. Result > – Chrome does not play the content. > 3. Cause > – When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the value of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >- The if_value points the string of value of If-Range > 4. Expected Behaviour > – Video and music file will be played in all the time on all case. > – When the value of If-Range is ETAG and is matched with ETAG of header of > cached content , response should include the header related with range > request. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungwoo Lee updated TS-2307: Affects Version/s: 3.2.5 4.0.1 4.0.2 Fix Version/s: (was: 4.0.2) (was: 4.0.1) (was: 3.2.5) > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > > 1. Precondition > – Upload file such as video or music file on Origin server > – On Chrome, access to the content file > – Repeat followings > – Delete the cache of Chrome > – Refresh( press F5 ) > 2. Result > – Chrome does not play the content. > 3. Cause > – When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the valud of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >- The if_value points the string of value of If-Range > 4. Expected Behaviour > – Video and music file will be played in all the time on all case. > – When the value of If-Range is ETAG and is matched with ETAG of cached > content header, response should include the header related with range request -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2307) Range request with If-Range does not work
[ https://issues.apache.org/jira/browse/TS-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jungwoo Lee updated TS-2307: Fix Version/s: 3.2.5 4.0.1 4.0.2 > Range request with If-Range does not work > - > > Key: TS-2307 > URL: https://issues.apache.org/jira/browse/TS-2307 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.2.5, 4.0.1, 4.0.2 >Reporter: Jungwoo Lee > > 1. Precondition > – Upload file such as video or music file on Origin server > – On Chrome, access to the content file > – Repeat followings > – Delete the cache of Chrome > – Refresh( press F5 ) > 2. Result > – Chrome does not play the content. > 3. Cause > – When Chrome requests including Range and If-Range headers, the value of > If-Range header can be set to the one of ETAG and Last Modified Date. ATS > core has unreasonable condition to check if the value of If-Range is ETAG and > it makes a bug that the valud of If-Range will be compared with Last Modified > Date event if ETAG is set to the value of If-Range. > As a result, response header does not include Content-Range when the value of > If-Range is ETAG. Sometimes this makes client abort. > - The condition to check ETAG is following( > HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, > HTTPHdr * response) function ) >- if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && > if_value[1] == '/')) >- The if_value points the string of value of If-Range > 4. Expected Behaviour > – Video and music file will be played in all the time on all case. > – When the value of If-Range is ETAG and is matched with ETAG of cached > content header, response should include the header related with range request -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2307) Range request with If-Range does not work
Jungwoo Lee created TS-2307: --- Summary: Range request with If-Range does not work Key: TS-2307 URL: https://issues.apache.org/jira/browse/TS-2307 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Jungwoo Lee 1. Precondition – Upload file such as video or music file on Origin server – On Chrome, access to the content file – Repeat followings – Delete the cache of Chrome – Refresh( press F5 ) 2. Result – Chrome does not play the content. 3. Cause – When Chrome requests including Range and If-Range headers, the value of If-Range header can be set to the one of ETAG and Last Modified Date. ATS core has unreasonable condition to check if the value of If-Range is ETAG and it makes a bug that the valud of If-Range will be compared with Last Modified Date event if ETAG is set to the value of If-Range. As a result, response header does not include Content-Range when the value of If-Range is ETAG. Sometimes this makes client abort. - The condition to check ETAG is following( HttpTransactCache::match_response_to_request_conditionals(HTTPHdr * request, HTTPHdr * response) function ) - if (!if_value || if_value[0] == '"' || (comma_sep_list_len > 1 && if_value[1] == '/')) - The if_value points the string of value of If-Range 4. Expected Behaviour – Video and music file will be played in all the time on all case. – When the value of If-Range is ETAG and is matched with ETAG of cached content header, response should include the header related with range request -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2200) the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin use these macros
[ https://issues.apache.org/jira/browse/TS-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-2200: -- Fix Version/s: (was: 4.2.0) 4.1.0 > the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin > use these macros > -- > > Key: TS-2200 > URL: https://issues.apache.org/jira/browse/TS-2200 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.1.0 > > Attachments: 0001-define-macro-TS_HRTIME_XXX-directly.patch > > > such macro defines in proxy/api/ts/experimental.h: > #define TS_HRTIME_FOREVER HRTIME_FOREVER > #define TS_HRTIME_DECADE HRTIME_DECADE > #define TS_HRTIME_YEAR HRTIME_YEAR > #define TS_HRTIME_WEEK HRTIME_WEEK > #define TS_HRTIME_DAY HRTIME_DAY > #define TS_HRTIME_HOUR HRTIME_HOUR > #define TS_HRTIME_MINUTE HRTIME_MINUTE > #define TS_HRTIME_SECOND HRTIME_SECOND > #define TS_HRTIME_MSECOND HRTIME_MSECOND > #define TS_HRTIME_USECOND HRTIME_USECOND > #define TS_HRTIME_NSECOND HRTIME_NSECOND > ... > The macros of HRTIME_xxx (such as HRTIME_SECOND) in lib/ts/ink_hrtime.h。 > Because the TS plugins SHOULD not include the header file ink_hrtime.h, so > they can't use above macros like TS_HRTIME_xxx。 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2200) the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin use these macros
[ https://issues.apache.org/jira/browse/TS-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810130#comment-13810130 ] ASF subversion and git services commented on TS-2200: - Commit e75d33a39fd94ae0942714201d875876cec574f4 in branch refs/heads/master from [~happy_fish100] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e75d33a ] TS-2200: define macro TS_HRTIME_XXX directly old macro defines can NOT be used in plugin because the target macros defined in lib/ts/ink_hrtime.h > the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin > use these macros > -- > > Key: TS-2200 > URL: https://issues.apache.org/jira/browse/TS-2200 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.2.0 > > Attachments: 0001-define-macro-TS_HRTIME_XXX-directly.patch > > > such macro defines in proxy/api/ts/experimental.h: > #define TS_HRTIME_FOREVER HRTIME_FOREVER > #define TS_HRTIME_DECADE HRTIME_DECADE > #define TS_HRTIME_YEAR HRTIME_YEAR > #define TS_HRTIME_WEEK HRTIME_WEEK > #define TS_HRTIME_DAY HRTIME_DAY > #define TS_HRTIME_HOUR HRTIME_HOUR > #define TS_HRTIME_MINUTE HRTIME_MINUTE > #define TS_HRTIME_SECOND HRTIME_SECOND > #define TS_HRTIME_MSECOND HRTIME_MSECOND > #define TS_HRTIME_USECOND HRTIME_USECOND > #define TS_HRTIME_NSECOND HRTIME_NSECOND > ... > The macros of HRTIME_xxx (such as HRTIME_SECOND) in lib/ts/ink_hrtime.h。 > Because the TS plugins SHOULD not include the header file ink_hrtime.h, so > they can't use above macros like TS_HRTIME_xxx。 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2235) url_print should NOT output "?" for empty query string
[ https://issues.apache.org/jira/browse/TS-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810118#comment-13810118 ] ASF subversion and git services commented on TS-2235: - Commit 1ab59b435498e1c77fce9463d6072778edaa2798 in branch refs/heads/master from [~happy_fish100] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1ab59b4 ] TS-2235: url_print should NOT output "?" for empty query string the same problem with params and fragment, when plugins removed all the query strings, we should remote the "?" too. > url_print should NOT output "?" for empty query string > --- > > Key: TS-2235 > URL: https://issues.apache.org/jira/browse/TS-2235 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.2.0 > > Attachments: > 0001-TS-2235-url_print-should-NOT-output-for-empty-query-.patch > > > the same problem with parameter and fragment parts. > for example: a remap plugin removes the query part (set query to empty), but > the remaped url end with "?". -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2292) the version of records.config increases unexpectly
[ https://issues.apache.org/jira/browse/TS-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810116#comment-13810116 ] ASF subversion and git services commented on TS-2292: - Commit 6cb58be3e7a5defab6d3419229d8d5e4b548e933 in branch refs/heads/master from [~happy_fish100] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6cb58be ] TS-2292: the version of records.config increases unexpectly > the version of records.config increases unexpectly > -- > > Key: TS-2292 > URL: https://issues.apache.org/jira/browse/TS-2292 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.1.0 > > Attachments: > 0001-TS-2292-the-version-of-records.config-increases-unex.patch > > > the version of records.config increases unexpectly when: > 1. trafficserver startup > 2. change a config parameter using "traffic_line -s name -v value" in cluster > 3. use traffic_line -x to reload modified records.config in cluster > when the version of config file increases, the traffic manager will broadcast > it to other machines in the cluster. then the traffic manager will fetch and > update the config from the machine whose version is larger. so many useless > config syncs happen in a cluster, in particular the big cluster as more than > 100 machines. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2277) cluster alarm messages broadcast infinitely
[ https://issues.apache.org/jira/browse/TS-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810109#comment-13810109 ] ASF subversion and git services commented on TS-2277: - Commit 26e1417a94ded811b60dbde91358ccf51e58c460 in branch refs/heads/master from [~happy_fish100] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=26e1417 ] TS-2277: cluster alarm messages broadcast infinitely > cluster alarm messages broadcast infinitely > --- > > Key: TS-2277 > URL: https://issues.apache.org/jira/browse/TS-2277 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.1.0 > > Attachments: > 0001-TS-2277-cluster-alarm-messages-broadcast-infinitely.patch > > > in mgmt/cluster/ClusterCom.cc, the alarm messages generated by > lmgmt->alarm_keeper->signalAlarm(xxx) will be broadcasted infinitely. > because these messages have no consumers. I think we should NOT generate > these alarms in this case. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2276) manager memory leak in some case
[
https://issues.apache.org/jira/browse/TS-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810101#comment-13810101
]
ASF subversion and git services commented on TS-2276:
-
Commit 316b450415f41cf80dca05f18538aa27c53b7b51 in branch refs/heads/master
from [~happy_fish100]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=316b450 ]
TS-2276: manager memory leak in some case
> manager memory leak in some case
> -
>
> Key: TS-2276
> URL: https://issues.apache.org/jira/browse/TS-2276
> Project: Traffic Server
> Issue Type: Bug
> Components: Management
>Reporter: Yu Qing
>Assignee: Yu Qing
> Fix For: 4.1.0
>
> Attachments: 0001-TS-2276-manager-memory-leak-in-some-case.patch
>
>
> 1. mgmt/utils/MgmtHashTable.h: in function mgmt_hash_table_delete, should
> free the value when destroy_and_free is true
> 2. mgmt/Alarms.cc: in function signalAlarm, two temp variables malloced for
> ip and desc should be freed. the code as:
> {code}
> 350 char *tmp, *tmp2;
> 351 AlarmCallbackFunc func = (AlarmCallbackFunc)
> ink_hash_table_entry_value(remote_alarms, entry);
> 352 if (ip) {
> 353 tmp = (char *)ats_strdup(ip);
> 354 } else {
> 355 tmp = NULL;
> 356 }
> 357
> 358 if (desc) {
> 359 tmp2 = ats_strdup(desc);
> 360 } else {
> 361 tmp2 = NULL;
> 362 }
> 363 Debug("alarm", "[Alarms::signalAlarm] invoke callback for %d", a);
> 364 (*(func)) (a, tmp, tmp2);
> {code}
> tmp and tmp2 should be freed after callback.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-1638) less strict on kernel version checking in clustering
[ https://issues.apache.org/jira/browse/TS-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810097#comment-13810097 ] ASF subversion and git services commented on TS-1638: - Commit e819a5f1b9394595d09f595fb9fa501190e0dd95 in branch refs/heads/master from [~happy_fish100] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e819a5f ] TS-1638: less strict on kernel version checking in clustering > less strict on kernel version checking in clustering > > > Key: TS-1638 > URL: https://issues.apache.org/jira/browse/TS-1638 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Zhao Yongming >Assignee: Yu Qing > Fix For: 4.1.0 > > Attachments: > 0001-TS-1638-less-strict-on-kernel-version-checking-in-cl.patch > > > we should do less strict checking on kernel version as it will be impossible > to do a kernel upgrade without bring down the whole system. > for kernel as 3.6.10-gentoo-zym > strict to 3.6 is enough in most case. > and print a message is fine. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2306) Client connection hang while downloading big file from origin server over SSL connection
Thach Tran created TS-2306: -- Summary: Client connection hang while downloading big file from origin server over SSL connection Key: TS-2306 URL: https://issues.apache.org/jira/browse/TS-2306 Project: Traffic Server Issue Type: Bug Components: Network, SSL Reporter: Thach Tran Setup: ATS in reverse proxy mode and Apache server in the backend to serve some very large test files (~10GB). Backend Apache server listens on both 80 for plain HTTP and 443 for HTTPS. Remap rules for ATS (with two plain HTTP ports of 8080 and 8081): map http://localhost:8080/ http://localhost/ map http://localhost:8081/ https://localhost/ What I am seeing is request for http://localhost:8080/files/testfile10g.bin will hang very quickly without getting much data back while request for http://localhost:8081/files/testfile10g.bin will continue to download just fine until it's finished. I've tried with other smaller files (~200MB, ~1MB) and it seems to work fine. I've disabled the caching (proxy.config.http.cache.http=0) in case it has something to do with that. I'm wondering if this is similar to TS-2211 but in reverse direction (client is non-SSL while origin connection is SSL). I've tested with trunk which includes a fix for TS-2211 but still be able to reproduce this. In my test setup both ATS and Apache are running on the same Linux Mint 13 box (which is effectively Ubuntu 12.04) with OpenSSL version 1.0.1. Any help would be much appreciated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2264) The current cache connection counter is not reliably decremented with use_client_source_port
[ https://issues.apache.org/jira/browse/TS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810013#comment-13810013 ] Mohamad Khateeb commented on TS-2264: - Alan , I have tried setting terminate_sm flag to true, i did not get any crash , i'm running load on the machines since yesterday. > The current cache connection counter is not reliably decremented with > use_client_source_port > > > Key: TS-2264 > URL: https://issues.apache.org/jira/browse/TS-2264 > Project: Traffic Server > Issue Type: Bug > Components: TProxy >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Fix For: 4.2.0 > > > If use_client_target_addr and use_client_source_port are enabled with > transparent proxy, in some cases the current cache connection counter is not > decremented. This happens when a client connection is terminated due to an > EADDRNOTAVAIL failure. -- This message was sent by Atlassian JIRA (v6.1#6144)
