[jira] [Created] (TS-3164) why the load of trafficserver occurrs a abrupt rise on a occasion ?
taoyunxing created TS-3164: -- Summary: why the load of trafficserver occurrs a abrupt rise on a occasion ? Key: TS-3164 URL: https://issues.apache.org/jira/browse/TS-3164 Project: Traffic Server Issue Type: Bug Components: Core Reporter: taoyunxing I use Tsar to monitor the traffic status of the ATS 4.2.0, and come across the following problem: Time ---cpu-- ---mem-- ---tcp-- -traffic --sda--- --sdb--- --sdc--- ---load- Time util util retranbytin bytout util util util load1 03/11/14-18:20 40.6787.19 3.3624.5M 43.9M13.0294.68 0.00 5.34 03/11/14-18:25 40.3087.20 3.2722.5M 42.6M12.3894.87 0.00 5.79 03/11/14-18:30 40.8484.67 3.4421.4M 42.0M13.2995.37 0.00 6.28 03/11/14-18:35 43.6387.36 3.2123.8M 45.0M13.2393.99 0.00 7.37 03/11/14-18:40 42.2587.37 3.0924.2M 44.8M12.8495.77 0.00 7.25 03/11/14-18:45 42.9687.44 3.4623.3M 46.0M12.9695.84 0.00 7.10 03/11/14-18:50 44.0087.42 3.4922.3M 43.0M14.1794.99 0.00 6.57 03/11/14-18:55 42.2087.44 3.4622.3M 43.6M13.1996.05 0.00 6.09 03/11/14-19:00 44.9087.53 3.6023.6M 46.5M13.6196.67 0.00 8.06 03/11/14-19:05 46.2687.73 3.2425.8M 49.1M15.3994.05 0.00 9.98 03/11/14-19:10 43.8587.69 3.1925.4M 50.9M12.8897.80 0.00 7.99 03/11/14-19:15 45.2887.69 3.3625.6M 49.6M13.1096.86 0.00 7.47 03/11/14-19:20 44.1185.20 3.2924.1M 47.8M14.2496.75 0.00 5.82 03/11/14-19:25 45.2687.78 3.5224.4M 47.7M13.2195.44 0.00 7.61 03/11/14-19:30 44.8387.80 3.6425.7M 50.8M13.2798.02 0.00 6.85 03/11/14-19:35 44.8987.78 3.6123.9M 49.0M13.3497.42 0.00 7.04 03/11/14-19:40 69.2188.88 0.5518.3M 33.7M11.3971.23 0.00 65.80 03/11/14-19:45 72.4788.66 0.2715.4M 31.6M11.5172.31 0.00 11.56 03/11/14-19:50 44.8788.72 4.1122.7M 46.3M12.9997.33 0.00 8.29 in addition, top command show hi:0 ni:0 si:45.56 st:0 sy:13.92 us:12.58 wa:14.3 id:15.96 who help me ? think in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3164) why the load of trafficserver occurrs a abrupt rise on a occasion ?
[ https://issues.apache.org/jira/browse/TS-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] taoyunxing updated TS-3164: --- Description: I use Tsar to monitor the traffic status of the ATS 4.2.0, and come across the following problem: Time ---cpu-- ---mem-- ---tcp-- -traffic --sda--- --sdb--- --sdc--- ---load- Time util util retranbytin bytout util util util load1 03/11/14-18:20 40.6787.19 3.3624.5M 43.9M13.0294.68 0.00 5.34 03/11/14-18:25 40.3087.20 3.2722.5M 42.6M12.3894.87 0.00 5.79 03/11/14-18:30 40.8484.67 3.4421.4M 42.0M13.2995.37 0.00 6.28 03/11/14-18:35 43.6387.36 3.2123.8M 45.0M13.2393.99 0.00 7.37 03/11/14-18:40 42.2587.37 3.0924.2M 44.8M12.8495.77 0.00 7.25 03/11/14-18:45 42.9687.44 3.4623.3M 46.0M12.9695.84 0.00 7.10 03/11/14-18:50 44.0087.42 3.4922.3M 43.0M14.1794.99 0.00 6.57 03/11/14-18:55 42.2087.44 3.4622.3M 43.6M13.1996.05 0.00 6.09 03/11/14-19:00 44.9087.53 3.6023.6M 46.5M13.6196.67 0.00 8.06 03/11/14-19:05 46.2687.73 3.2425.8M 49.1M15.3994.05 0.00 9.98 03/11/14-19:10 43.8587.69 3.1925.4M 50.9M12.8897.80 0.00 7.99 03/11/14-19:15 45.2887.69 3.3625.6M 49.6M13.1096.86 0.00 7.47 03/11/14-19:20 44.1185.20 3.2924.1M 47.8M14.2496.75 0.00 5.82 03/11/14-19:25 45.2687.78 3.5224.4M 47.7M13.2195.44 0.00 7.61 03/11/14-19:30 44.8387.80 3.6425.7M 50.8M13.2798.02 0.00 6.85 03/11/14-19:35 44.8987.78 3.6123.9M 49.0M13.3497.42 0.00 7.04 03/11/14-19:40 69.2188.88 0.5518.3M 33.7M11.3971.23 0.00 65.80 03/11/14-19:45 72.4788.66 0.2715.4M 31.6M11.5172.31 0.00 11.56 03/11/14-19:50 44.8788.72 4.1122.7M 46.3M12.9997.33 0.00 8.29 in addition, top command show hi:0 ni:0 si:45.56 st:0 sy:13.92 us:12.58 wa:14.3 id:15.96 who help me ? thanks in advance. was: I use Tsar to monitor the traffic status of the ATS 4.2.0, and come across the following problem: Time ---cpu-- ---mem-- ---tcp-- -traffic --sda--- --sdb--- --sdc--- ---load- Time util util retranbytin bytout util util util load1 03/11/14-18:20 40.6787.19 3.3624.5M 43.9M13.0294.68 0.00 5.34 03/11/14-18:25 40.3087.20 3.2722.5M 42.6M12.3894.87 0.00 5.79 03/11/14-18:30 40.8484.67 3.4421.4M 42.0M13.2995.37 0.00 6.28 03/11/14-18:35 43.6387.36 3.2123.8M 45.0M13.2393.99 0.00 7.37 03/11/14-18:40 42.2587.37 3.0924.2M 44.8M12.8495.77 0.00 7.25 03/11/14-18:45 42.9687.44 3.4623.3M 46.0M12.9695.84 0.00 7.10 03/11/14-18:50 44.0087.42 3.4922.3M 43.0M14.1794.99 0.00 6.57 03/11/14-18:55 42.2087.44 3.4622.3M 43.6M13.1996.05 0.00 6.09 03/11/14-19:00 44.9087.53 3.6023.6M 46.5M13.6196.67 0.00 8.06 03/11/14-19:05 46.2687.73 3.2425.8M 49.1M15.3994.05 0.00 9.98 03/11/14-19:10 43.8587.69 3.1925.4M 50.9M12.8897.80 0.00 7.99 03/11/14-19:15 45.2887.69 3.3625.6M 49.6M13.1096.86 0.00 7.47 03/11/14-19:20 44.1185.20 3.2924.1M 47.8M14.2496.75 0.00 5.82 03/11/14-19:25 45.2687.78 3.5224.4M 47.7M13.2195.44 0.00 7.61 03/11/14-19:30 44.8387.80 3.6425.7M 50.8M13.2798.02 0.00 6.85 03/11/14-19:35 44.8987.78 3.6123.9M 49.0M13.3497.42 0.00 7.04 03/11/14-19:40 69.2188.88 0.5518.3M 33.7M11.3971.23 0.00 65.80 03/11/14-19:45 72.4788.66 0.2715.4M 31.6M11.5172.31 0.00 11.56 03/11/14-19:50 44.8788.72 4.1122.7M 46.3M12.9997.33 0.00 8.29 in addition, top command show hi:0 ni:0 si:45.56 st:0 sy:13.92 us:12.58 wa:14.3 id:15.96 who help me ? think in advance. Environment: CentOS 6.3 64bit, 8 cores, 128G mem > why the load of trafficserver occurrs a abrupt rise on a occasion ? > --- > > Key: TS-3164 >
[jira] [Assigned] (TS-60) support writing large buffers via zero-copy
[ https://issues.apache.org/jira/browse/TS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-60: - Assignee: Alan M. Carroll (was: John Plevyak) > support writing large buffers via zero-copy > --- > > Key: TS-60 > URL: https://issues.apache.org/jira/browse/TS-60 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 3.0.0 > Environment: all >Reporter: John Plevyak >Assignee: Alan M. Carroll > Fix For: sometime > > Original Estimate: 48h > Remaining Estimate: 48h > > Currently all write data is written from the aggregation buffer. In order to > support large buffer writes efficiently > it would be nice to be able to write directly from page aligned memory. This > would be bother more efficient and > would help support large objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-54) UnixNet cleanup, encapsulation of event subsystem
[ https://issues.apache.org/jira/browse/TS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-54: - Assignee: Phil Sorber (was: John Plevyak) > UnixNet cleanup, encapsulation of event subsystem > - > > Key: TS-54 > URL: https://issues.apache.org/jira/browse/TS-54 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup > Environment: all unixesque >Reporter: John Plevyak >Assignee: Phil Sorber > Fix For: sometime > > Attachments: proposed-jp-v1-List.h, ts-List-net-cleanup-jp-v2.patch, > ts-List_and_net-cleanup-jp-v1.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The UnixNet subsystem was modified for epoll, but lots of the old data > structures, data members and code > remain for the old "bucket" approach. > The epoll code should also be encapsulated to simplify support for other > platforms and a possible move > to an event library. > The current code is complicated by limitations in Queue which require > specifying the link field for every > use, but which can be fixed by in the template. > Finally, the current code does an unnecessary allocation for the epoll struct > which should be part of the NetVConnection etc. > and it takes a lock for the enable_queue which can be avoided by using the > non-locking AtomicSSL. > This work is also good preparation for evaluating libev or libevent as it > will reduce the amount of code which > will have to be changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-61) multiple do_io_pread on a CacheVConnection
[ https://issues.apache.org/jira/browse/TS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196303#comment-14196303 ] Alan M. Carroll commented on TS-61: --- I think I'll roll this in to the partial object caching. > multiple do_io_pread on a CacheVConnection > -- > > Key: TS-61 > URL: https://issues.apache.org/jira/browse/TS-61 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 3.0.0 >Reporter: John Plevyak >Assignee: Alan M. Carroll > Fix For: sometime > > Attachments: pread-2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > The current TS-46 patch includes do_io_pread support but allows only a single > do_io_pread. > In order to efficiently support range requests with multiple ranges it would > be helpful to be able > to do multiple do_io_pread's on a single open CacheVConnection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-81) Have one single place to store and lookup remap rules irrespective of type
[ https://issues.apache.org/jira/browse/TS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-81: - Fix Version/s: (was: 5.3.0) sometime > Have one single place to store and lookup remap rules irrespective of type > -- > > Key: TS-81 > URL: https://issues.apache.org/jira/browse/TS-81 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0a >Reporter: Manjesh Nilange >Priority: Minor > Labels: A > Fix For: sometime > > > Currently, remap rules are stored in different structures and looked up > separately based on type (forward, reverse, etc.). It'd be better design and > more maintainable to process (store, search) all rules in one structure and > then use type to determine action. > A fundamental problem with our current implementation is that the order in > remap.config is not honored. E.g. a map directive always takes precedence > over any redirect directives (if both matches). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-110) Improve regex remap to allow substitutions in path field
[ https://issues.apache.org/jira/browse/TS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-110: -- Fix Version/s: (was: 5.3.0) sometime > Improve regex remap to allow substitutions in path field > > > Key: TS-110 > URL: https://issues.apache.org/jira/browse/TS-110 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0 >Reporter: Manjesh Nilange >Assignee: Brian Geffon >Priority: Minor > Fix For: sometime > > > Currently, regex support covers only the host field of the remap rules. It'd > be nice to extend this to allow substitutions into the path field as well. > This will allow rules like: > regex_map http://www.example-(.*).com/ http://real-example.com/$1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-81) Have one single place to store and lookup remap rules irrespective of type
[ https://issues.apache.org/jira/browse/TS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-81: - Labels: (was: A) > Have one single place to store and lookup remap rules irrespective of type > -- > > Key: TS-81 > URL: https://issues.apache.org/jira/browse/TS-81 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0a >Reporter: Manjesh Nilange >Priority: Minor > Fix For: sometime > > > Currently, remap rules are stored in different structures and looked up > separately based on type (forward, reverse, etc.). It'd be better design and > more maintainable to process (store, search) all rules in one structure and > then use type to determine action. > A fundamental problem with our current implementation is that the order in > remap.config is not honored. E.g. a map directive always takes precedence > over any redirect directives (if both matches). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-110) Improve regex remap to allow substitutions in path field
[ https://issues.apache.org/jira/browse/TS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196312#comment-14196312 ] Susan Hinrichs commented on TS-110: --- Brian, are you still working on this? Any target for ETA? > Improve regex remap to allow substitutions in path field > > > Key: TS-110 > URL: https://issues.apache.org/jira/browse/TS-110 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0 >Reporter: Manjesh Nilange >Assignee: Brian Geffon >Priority: Minor > Fix For: sometime > > > Currently, regex support covers only the host field of the remap rules. It'd > be nice to extend this to allow substitutions into the path field as well. > This will allow rules like: > regex_map http://www.example-(.*).com/ http://real-example.com/$1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-119) RAM only caching
[ https://issues.apache.org/jira/browse/TS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196314#comment-14196314 ] Alan M. Carroll commented on TS-119: This may end up being part of the Cache API toolkit (which is also tiered caching). > RAM only caching > > > Key: TS-119 > URL: https://issues.apache.org/jira/browse/TS-119 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Priority: Minor > Fix For: sometime > > > It would be nice if we could run with a RAM only cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-119) RAM only caching
[ https://issues.apache.org/jira/browse/TS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-119: -- Assignee: (was: Phil Sorber) > RAM only caching > > > Key: TS-119 > URL: https://issues.apache.org/jira/browse/TS-119 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Priority: Minor > Fix For: sometime > > > It would be nice if we could run with a RAM only cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-203) config files ownership
[ https://issues.apache.org/jira/browse/TS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-203: -- Fix Version/s: (was: 5.2.0) 6.0.0 > config files ownership > -- > > Key: TS-203 > URL: https://issues.apache.org/jira/browse/TS-203 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 6.0.0 > > > It's semi-odd that the admin user (nobody) is also the user as to which > traffic_server process changes it's euid to. This means that the > traffic_server process has write permissions on the config files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-228) Cleanup usage of "long" in all code
[ https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-228: -- Assignee: (was: James Peach) > Cleanup usage of "long" in all code > --- > > Key: TS-228 > URL: https://issues.apache.org/jira/browse/TS-228 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: John Plevyak >Priority: Critical > Fix For: 5.2.0 > > > Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit. > This is a potential can of worms which at the least is making records.snap > incompatible but at worse could be the cause of other bugs. > In any case we should not be using "long" in the TS code, but instead use > either "int" which is always 32-bits or "inkXXX" of a particular size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-228) Cleanup usage of "long" in all code
[ https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-228: -- Fix Version/s: (was: 5.2.0) 5.3.0 > Cleanup usage of "long" in all code > --- > > Key: TS-228 > URL: https://issues.apache.org/jira/browse/TS-228 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: John Plevyak >Priority: Critical > Fix For: 5.3.0 > > > Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit. > This is a potential can of worms which at the least is making records.snap > incompatible but at worse could be the cause of other bugs. > In any case we should not be using "long" in the TS code, but instead use > either "int" which is always 32-bits or "inkXXX" of a particular size. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-242) Connect timeout doesn't reset until first byte is received from server
[ https://issues.apache.org/jira/browse/TS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-242: -- Fix Version/s: (was: 5.3.0) sometime > Connect timeout doesn't reset until first byte is received from server > -- > > Key: TS-242 > URL: https://issues.apache.org/jira/browse/TS-242 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Steve Jiang >Assignee: Alan M. Carroll >Priority: Minor > Fix For: sometime > > > proxy.config.http.connect_attempts_timeout > proxy.config.http.parent_proxy.connect_attempts_timeout > proxy.config.http.post_connect_attempts_timeout > These timeouts are implemented with inactivity timeout on the netvc and don't > behave as expected. > If the connect succeeds (the remote server successfully accepted) but the > remote server does not respond with any bytes within the timeout period, TS > still treats it as a connect timeout. If retries are enabled and the origin > server is slow to start sending responses (but not down), it will keep > sending requests and closing the connection after getting no response within > the connect timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-60) support writing large buffers via zero-copy
[ https://issues.apache.org/jira/browse/TS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196323#comment-14196323 ] John Plevyak commented on TS-60: This would be a win on systems which write large files frequently (as opposed to just serving them). Is that a common enough workload to justify the complexity? Perhaps when linux native AIO is enabled otherwise the benefit would likely be swamped by context switch overhead. > support writing large buffers via zero-copy > --- > > Key: TS-60 > URL: https://issues.apache.org/jira/browse/TS-60 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 3.0.0 > Environment: all >Reporter: John Plevyak >Assignee: Alan M. Carroll > Fix For: sometime > > Original Estimate: 48h > Remaining Estimate: 48h > > Currently all write data is written from the aggregation buffer. In order to > support large buffer writes efficiently > it would be nice to be able to write directly from page aligned memory. This > would be bother more efficient and > would help support large objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-275) API: TSHttpTxnConnectTimeoutSet isn't documented
[ https://issues.apache.org/jira/browse/TS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-275: -- Labels: Docs (was: ) > API: TSHttpTxnConnectTimeoutSet isn't documented > > > Key: TS-275 > URL: https://issues.apache.org/jira/browse/TS-275 > Project: Traffic Server > Issue Type: Bug > Components: Documentation, TS API >Reporter: Miles Libbey >Priority: Minor > Labels: Docs > Fix For: Docs > > > Someone had a question about INKHttpTxnConnectTimeoutSet -- it's not > documented in the SDK guide. Can someone please provide: > - Where it should live (ie, Function Reference/HTTP Functions/ HTTP > Transaction Functions) > - suggested text in a similar format to > http://incubator.apache.org/trafficserver/docs/sdk/HTTPFunctions.html > (ie, what it does; prototype; description; returns, and possibly an example) > (Bryan also mentioned that a few timeout apis were added last year, but, I > don't see any others with timeout in them (except for > https://issues.apache.org/jira/browse/TS-256 -- INKHttpSchedule -- are we > missing others?) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-302) -fstrict-aliasing optimizer generates bad code
[
https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-302:
--
Assignee: (was: Phil Sorber)
> -fstrict-aliasing optimizer generates bad code
> --
>
> Key: TS-302
> URL: https://issues.apache.org/jira/browse/TS-302
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Reporter: Miles Libbey
>Priority: Minor
> Fix For: sometime
>
> Attachments: no-no-fstrict-alias.patch, ts-302.patch
>
>
> (moving from yahoo bug 525119)
> Original description
> by Leif Hedstrom 4 years ago at 2005-12-16 08:41
> Not sure if this is a compiler bug or a code issue on our side, but enabling
> the
> -fstrict-aliasing optimization option generates faulty code. This optimization
> technique is enabled implicitly with -Os, -O2 and -O3, so for now I'm
> explicitly
> turning it off with
>-O3 -fno-strict-aliasing
> This solves the problem where the traffic server would return data of 0 or 1
> length out of the cache. This initially looked like the cache corruption
> problem, but is completely different and unrelated. The cache corruption
> problem
> has been fixed and closed.
> I'm opening this bug as a reminder, at some point we should isolate which code
> triggers the strict-aliasing problem, and confirm if it's a compiler bug or a
> problem in our code.
>
>
> Comment 1
> by Michael Bigby 4 years ago at 2005-12-16 09:07:40
> I'm recommending that we get Ed's input on this. He may some insight compiler
> issues...
>
>
> Comment 2
> by Leif Hedstrom 4 years ago at 2005-12-16 10:02:07
> That'd be great!
> We haven't had a chance yet to review the code that might be affecting this,
> it's obviously something with unions and how the compiler handles
> storage/alignment on the members.
>
>
> Comment 3
> by Ed Hall 4 years ago at 2006-03-03 11:46:52
> This is with gcc 2.95.3, correct? There have been a number of complaints
> around
> the 'net about problems with -fstrict-aliasing. I've not really looked very
> deeply into it, though I should mention that certain C code was known at the
> time to malfunction when by-the-standard aliasing rules were enforced
> (starting
> with the Linux kernel).
> In essense, the -fstrict-aliasing optimizations assume that any particular
> part
> of memory accessed via a specific type of pointer won't be accessed as another
> type. There are a set of optimizations that are safe only when it can be
> guaranteed that a given bit of memory hasn't been manipulated via pointer; if
> the compiler assumes that the rather arcane C aliasing rules have been
> followed
> ("aliasing" in this case meaning accessing a given bit of memory with more
> than
> one type of pointer), there are more situations where such optimizations can
> be
> applied. Code which uses type casts where unions might be more appropriate is
> the most likely to break aliasing rules.
> In any case, gcc 3/4 is less aggressive (and perhaps less buggy) in applying
> the
> C aliasing rules, and has added warnings for obvious violations. It's never
> been clear to me if gcc 2.95.3 was actually broken or not, or if there simply
> was a lot of code out there that ran afoul of the standard.
>
>
> Comment 4
> by Leif Hedstrom 4 years ago at 2006-03-03 12:50:22
> Actually, the problem only occured after we converted the code from gcc-2.9x
> to
> gcc-3.4.4. We have since cleared out a *lot* of compiler warnings (thousands
> and
> thousands), so maybe we should try again to compile without the
> -fno-strict-aliasing, and see if gcc will point us to some places where we do
> dangerous things. The code does some very scary things manipulating objects
> directly, by byte-offsets for instance.
> I think it's pretty easy to reproduce the problem, it basically renders the
> cache completely useless, returning objects of size 0 or 1.
>
>
> Comment 5
> by Ed Hall 4 years ago at 2006-03-03 16:44:04
> Ah, that makes sense. I just checked, and the -fstrict-aliasing option wasn't
> part of the -O2 optimizations on gcc 2.95, but got added sometime during gcc 3
> development.
>
>
> Comment 6
> by Ed Hall 4 years ago at 2006-03-03 16:46:43
> (Just to be clear, -fstrict-aliasing was *available* with gcc 2.95.3, it just
> wasn't activated by the -O optimization flags.)
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-306) enable log rotation for diags.log
[ https://issues.apache.org/jira/browse/TS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-306: -- Assignee: kang li > enable log rotation for diags.log > - > > Key: TS-306 > URL: https://issues.apache.org/jira/browse/TS-306 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Miles Libbey >Assignee: kang li >Priority: Critical > Fix For: 5.3.0 > > > (from yahoo bug 913896) > Original description > by Leif Hedstrom 3 years ago at 2006-12-04 12:42 > There might be reasons why this file might get filled up, e.g. libraries used > by plugins producing output on STDOUT/STDERR. A few suggestions have been > made, to somehow rotate traffic.out. One possible solution (suggested by > Ryan) is to use cronolog (http://cronolog.org/), which seems like a fine idea. > > > Comment 1 > by Joseph Rothrock 2 years ago at 2007-10-17 09:13:24 > Maybe consider rolling diags.log as well. -Feature enhancement. > > Comment 2 > by Kevin Dalley 13 months ago at 2009-03-04 15:32:18 > When traffic.out gets filled up, error.log stops filing up, even though > rotation is turned on. This is > counter-intuitive. Rotation does not control traffic.out, but a large > traffic.out will stop error.log from being > written. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-315: -- Fix Version/s: (was: 5.2.0) sometime > Add switch to disable config file generation/runtime behavior changing > -- > > Key: TS-315 > URL: https://issues.apache.org/jira/browse/TS-315 > Project: Traffic Server > Issue Type: Sub-task > Components: Configuration >Reporter: Miles Libbey >Priority: Minor > Fix For: sometime > > > (was yahoo bug 1863676) > Original description > by Michael S. Fischer 2 years ago at 2008-04-09 09:52 > In production, in order to improve site stability, it is imperative that TS > never accidentally overwrite its own > configuration files. > For this reason, we'd like to request a switch be added to TS, preferably via > the command line, that disables all > automatic configuration file generation or other runtime behavioral changes > initiated by any form of IPC other than > 'traffic_line -x' (including the web interface, etc.) > > > Comment 1 > by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 > A very crucial request, in my opinion. If TS needs to be able to read > command-line config changes on the fly, these > changes should be stored in another config file (for example > remap.config.local instead of remap.config). We have a > patch config package that overwrites 4 of the config files under > /home/conf/ts/, and with all packages > we'd like to think that the content of these files can't change outside our > control. > > Comment 2 > by Bryan Call 2 years ago at 2008-04-09 11:02:46 > traffic_line -x doesn't modify the configuration, it reloads the > configuration files. If we want to have an option for > this it would be good to have it as an option configuration file (CONFIG > proxy.config.write_protect INT 1). > It would be an equivalent of write protecting floppies (ahh the memories)... > > > Comment 3 > by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 > I don't think it would be a good idea to have this in the configuration file, > as it would introduce a chicken/egg > problem. > > > Comment 4 > by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 > So I'm not 100% positive that this isn't just a bad interaction. Now, it's > only > triggered when trafficserver is running, but usually what ends up happening > is that we get a records.config which > looks like it's the default config that comes with the trafficserver package. > It's possible it's all one and the same issue, or we might have two issues. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-337) Cache Replacement Algorithm plug-in API
[ https://issues.apache.org/jira/browse/TS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-337: - Assignee: Susan Hinrichs > Cache Replacement Algorithm plug-in API > --- > > Key: TS-337 > URL: https://issues.apache.org/jira/browse/TS-337 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 2.0.0 >Reporter: Mark Nottingham >Assignee: Susan Hinrichs > Fix For: sometime > > > New cache replacement algorithms are often proposed, and often it's not a > "one size fits all" problem; different workloads require different approaches. > To facilitate this, TS should have a pluggable cache replacement policy API, > both for the memory and disk cache. > Squid has done this to good effect; see > http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/repl/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-337) Cache Replacement Algorithm plug-in API
[ https://issues.apache.org/jira/browse/TS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-337: -- Assignee: Alan M. Carroll (was: Susan Hinrichs) > Cache Replacement Algorithm plug-in API > --- > > Key: TS-337 > URL: https://issues.apache.org/jira/browse/TS-337 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 2.0.0 >Reporter: Mark Nottingham >Assignee: Alan M. Carroll > Fix For: sometime > > > New cache replacement algorithms are often proposed, and often it's not a > "one size fits all" problem; different workloads require different approaches. > To facilitate this, TS should have a pluggable cache replacement policy API, > both for the memory and disk cache. > Squid has done this to good effect; see > http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/repl/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3164) why the load of trafficserver occurrs a abrupt rise on a occasion ?
[
https://issues.apache.org/jira/browse/TS-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-3164:
Description:
I use Tsar to monitor the traffic status of the ATS 4.2.0, and come across the
following problem:
{code}
Time ---cpu-- ---mem-- ---tcp-- -traffic --sda--- --sdb---
--sdc--- ---load-
Time util util retranbytin bytout util util
util load1
03/11/14-18:20 40.6787.19 3.3624.5M 43.9M13.0294.68
0.00 5.34
03/11/14-18:25 40.3087.20 3.2722.5M 42.6M12.3894.87
0.00 5.79
03/11/14-18:30 40.8484.67 3.4421.4M 42.0M13.2995.37
0.00 6.28
03/11/14-18:35 43.6387.36 3.2123.8M 45.0M13.2393.99
0.00 7.37
03/11/14-18:40 42.2587.37 3.0924.2M 44.8M12.8495.77
0.00 7.25
03/11/14-18:45 42.9687.44 3.4623.3M 46.0M12.9695.84
0.00 7.10
03/11/14-18:50 44.0087.42 3.4922.3M 43.0M14.1794.99
0.00 6.57
03/11/14-18:55 42.2087.44 3.4622.3M 43.6M13.1996.05
0.00 6.09
03/11/14-19:00 44.9087.53 3.6023.6M 46.5M13.6196.67
0.00 8.06
03/11/14-19:05 46.2687.73 3.2425.8M 49.1M15.3994.05
0.00 9.98
03/11/14-19:10 43.8587.69 3.1925.4M 50.9M12.8897.80
0.00 7.99
03/11/14-19:15 45.2887.69 3.3625.6M 49.6M13.1096.86
0.00 7.47
03/11/14-19:20 44.1185.20 3.2924.1M 47.8M14.2496.75
0.00 5.82
03/11/14-19:25 45.2687.78 3.5224.4M 47.7M13.2195.44
0.00 7.61
03/11/14-19:30 44.8387.80 3.6425.7M 50.8M13.2798.02
0.00 6.85
03/11/14-19:35 44.8987.78 3.6123.9M 49.0M13.3497.42
0.00 7.04
03/11/14-19:40 69.2188.88 0.5518.3M 33.7M11.3971.23
0.00 65.80
03/11/14-19:45 72.4788.66 0.2715.4M 31.6M11.5172.31
0.00 11.56
03/11/14-19:50 44.8788.72 4.1122.7M 46.3M12.9997.33
0.00 8.29
{code}
in addition, top command show
{code}
hi:0
ni:0
si:45.56
st:0
sy:13.92
us:12.58
wa:14.3
id:15.96
{code}
who help me ? thanks in advance.
was:
I use Tsar to monitor the traffic status of the ATS 4.2.0, and come across the
following problem:
Time ---cpu-- ---mem-- ---tcp-- -traffic --sda--- --sdb---
--sdc--- ---load-
Time util util retranbytin bytout util util
util load1
03/11/14-18:20 40.6787.19 3.3624.5M 43.9M13.0294.68
0.00 5.34
03/11/14-18:25 40.3087.20 3.2722.5M 42.6M12.3894.87
0.00 5.79
03/11/14-18:30 40.8484.67 3.4421.4M 42.0M13.2995.37
0.00 6.28
03/11/14-18:35 43.6387.36 3.2123.8M 45.0M13.2393.99
0.00 7.37
03/11/14-18:40 42.2587.37 3.0924.2M 44.8M12.8495.77
0.00 7.25
03/11/14-18:45 42.9687.44 3.4623.3M 46.0M12.9695.84
0.00 7.10
03/11/14-18:50 44.0087.42 3.4922.3M 43.0M14.1794.99
0.00 6.57
03/11/14-18:55 42.2087.44 3.4622.3M 43.6M13.1996.05
0.00 6.09
03/11/14-19:00 44.9087.53 3.6023.6M 46.5M13.6196.67
0.00 8.06
03/11/14-19:05 46.2687.73 3.2425.8M 49.1M15.3994.05
0.00 9.98
03/11/14-19:10 43.8587.69 3.1925.4M 50.9M12.8897.80
0.00 7.99
03/11/14-19:15 45.2887.69 3.3625.6M 49.6M13.1096.86
0.00 7.47
03/11/14-19:20 44.1185.20 3.2924.1M 47.8M14.2496.75
0.00 5.82
03/11/14-19:25 45.2687.78 3.5224.4M 47.7M13.2195.44
0.00 7.61
03/11/14-19:30 44.8387.80 3.6425.7M 50.8M13.2798.02
0.00 6.85
03/11/14-19:35 44.8987.78 3.6123.9M 49.0M13.3497.42
0.00 7.04
03/11/14-19:40 69.2188.88 0.5518.3M 33.7M11.3971.23
0.00 65.80
03/11/14-19:45 72.4788.66 0.2715.4M 31.6M11.5172.31
0.00 11.56
03/11/14-19:50 44.8788.72 4.1122.7M 46.3M12.9997.33
0.00 8.29
in addition, top command show
hi:0
ni:0
si:45.56
st:0
sy:13.92
us:12.58
wa:14.3
id:15.96
who help me ? thanks in advance.
> why the load of trafficserver occurrs a abrupt rise on a occasion ?
> ---
>
> Key: TS-3164
> URL: h
[jira] [Assigned] (TS-357) Compiling with -Wconversion generates a lot of errors
[ https://issues.apache.org/jira/browse/TS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-357: - Assignee: Susan Hinrichs > Compiling with -Wconversion generates a lot of errors > - > > Key: TS-357 > URL: https://issues.apache.org/jira/browse/TS-357 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: Bryan Call >Assignee: Susan Hinrichs > Fix For: sometime > > > After adding -Wconversion to CFLAGS and CXXFLAGS I got 11k errors: > [bcall@snowball traffic.git]$ gmake -k 2> /dev/stdout | grep -c ' error: ' > 11432 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-357) Compiling with -Wconversion generates a lot of errors
[ https://issues.apache.org/jira/browse/TS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196331#comment-14196331 ] Susan Hinrichs commented on TS-357: --- Bryan will check this out, because a number of these have been fixed in other efforts. > Compiling with -Wconversion generates a lot of errors > - > > Key: TS-357 > URL: https://issues.apache.org/jira/browse/TS-357 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: sometime > > > After adding -Wconversion to CFLAGS and CXXFLAGS I got 11k errors: > [bcall@snowball traffic.git]$ gmake -k 2> /dev/stdout | grep -c ' error: ' > 11432 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-357) Compiling with -Wconversion generates a lot of errors
[ https://issues.apache.org/jira/browse/TS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-357: -- Assignee: Bryan Call (was: Susan Hinrichs) > Compiling with -Wconversion generates a lot of errors > - > > Key: TS-357 > URL: https://issues.apache.org/jira/browse/TS-357 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: sometime > > > After adding -Wconversion to CFLAGS and CXXFLAGS I got 11k errors: > [bcall@snowball traffic.git]$ gmake -k 2> /dev/stdout | grep -c ' error: ' > 11432 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3164) why the load of trafficserver occurrs a abrupt rise on a occasion ?
[
https://issues.apache.org/jira/browse/TS-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196335#comment-14196335
]
James Peach commented on TS-3164:
-
I suggest using standard Linux tools to investigate this. {strace} and {perf}
could show you interesting data.
> why the load of trafficserver occurrs a abrupt rise on a occasion ?
> ---
>
> Key: TS-3164
> URL: https://issues.apache.org/jira/browse/TS-3164
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: CentOS 6.3 64bit, 8 cores, 128G mem
>Reporter: taoyunxing
>
> I use Tsar to monitor the traffic status of the ATS 4.2.0, and come across
> the following problem:
> {code}
> Time ---cpu-- ---mem-- ---tcp-- -traffic --sda--- --sdb---
> --sdc--- ---load-
> Time util util retranbytin bytout util util
> util load1
> 03/11/14-18:20 40.6787.19 3.3624.5M 43.9M13.0294.68
> 0.00 5.34
> 03/11/14-18:25 40.3087.20 3.2722.5M 42.6M12.3894.87
> 0.00 5.79
> 03/11/14-18:30 40.8484.67 3.4421.4M 42.0M13.2995.37
> 0.00 6.28
> 03/11/14-18:35 43.6387.36 3.2123.8M 45.0M13.2393.99
> 0.00 7.37
> 03/11/14-18:40 42.2587.37 3.0924.2M 44.8M12.8495.77
> 0.00 7.25
> 03/11/14-18:45 42.9687.44 3.4623.3M 46.0M12.9695.84
> 0.00 7.10
> 03/11/14-18:50 44.0087.42 3.4922.3M 43.0M14.1794.99
> 0.00 6.57
> 03/11/14-18:55 42.2087.44 3.4622.3M 43.6M13.1996.05
> 0.00 6.09
> 03/11/14-19:00 44.9087.53 3.6023.6M 46.5M13.6196.67
> 0.00 8.06
> 03/11/14-19:05 46.2687.73 3.2425.8M 49.1M15.3994.05
> 0.00 9.98
> 03/11/14-19:10 43.8587.69 3.1925.4M 50.9M12.8897.80
> 0.00 7.99
> 03/11/14-19:15 45.2887.69 3.3625.6M 49.6M13.1096.86
> 0.00 7.47
> 03/11/14-19:20 44.1185.20 3.2924.1M 47.8M14.2496.75
> 0.00 5.82
> 03/11/14-19:25 45.2687.78 3.5224.4M 47.7M13.2195.44
> 0.00 7.61
> 03/11/14-19:30 44.8387.80 3.6425.7M 50.8M13.2798.02
> 0.00 6.85
> 03/11/14-19:35 44.8987.78 3.6123.9M 49.0M13.3497.42
> 0.00 7.04
> 03/11/14-19:40 69.2188.88 0.5518.3M 33.7M11.3971.23
> 0.00 65.80
> 03/11/14-19:45 72.4788.66 0.2715.4M 31.6M11.5172.31
> 0.00 11.56
> 03/11/14-19:50 44.8788.72 4.1122.7M 46.3M12.9997.33
> 0.00 8.29
> {code}
>
> in addition, top command show
> {code}
> hi:0
> ni:0
> si:45.56
> st:0
> sy:13.92
> us:12.58
> wa:14.3
> id:15.96
> {code}
> who help me ? thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-382) socket option "cleanup" (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-382: -- Assignee: (was: Alan M. Carroll) > socket option "cleanup" (and bug fixes) > --- > > Key: TS-382 > URL: https://issues.apache.org/jira/browse/TS-382 > Project: Traffic Server > Issue Type: Bug > Components: Network >Reporter: Leif Hedstrom > Fix For: sometime > > > This is a bug moved from Y! Bugzilla, I'm posting the original bug > description and a few comments separately. Note that the bug description is > fairly limited, but while looking at this code, I noticed a lot of oddities > with the "socket option" support (lots of hardcoded stuff, and most of it is > not configurable). > Note that the original bug should have been fixed already in Apache TS, but > the other comments are still applicable. > From Bugzilla (posted by Leif): > We have two socket option config options in records.config: > proxy.config.net.sock_option_flag_in > proxy.config.net.sock_option_flag_out > With accept thread enabled, at least the _in option isn't honored. There are > possibly other cases in UnixNetAccept.cc > that we don't honor these flags either. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-454) Dynamic resizing API stats
[ https://issues.apache.org/jira/browse/TS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-454: -- Assignee: (was: Phil Sorber) > Dynamic resizing API stats > -- > > Key: TS-454 > URL: https://issues.apache.org/jira/browse/TS-454 > Project: Traffic Server > Issue Type: Bug > Components: Metrics >Reporter: Leif Hedstrom > Fix For: sometime > > > This is a new bug, as introduced with TS-390. We do not properly allow to > resize the librecords container, not allowing API (plugins) to create the > requested number of stats "slots". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3165) Cache Toolkit API
[ https://issues.apache.org/jira/browse/TS-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-3165: --- Assignee: Alan M. Carroll > Cache Toolkit API > - > > Key: TS-3165 > URL: https://issues.apache.org/jira/browse/TS-3165 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > > Implement the Cache Toolkit API as described in > https://cwiki.apache.org/confluence/download/attachments/47384310/ApacheCon-2014-Cache-Toolkit.pdf?version=1&modificationDate=1414085058000&api=v2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3165) Cache Toolkit API
Alan M. Carroll created TS-3165: --- Summary: Cache Toolkit API Key: TS-3165 URL: https://issues.apache.org/jira/browse/TS-3165 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Implement the Cache Toolkit API as described in https://cwiki.apache.org/confluence/download/attachments/47384310/ApacheCon-2014-Cache-Toolkit.pdf?version=1&modificationDate=1414085058000&api=v2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-454) Dynamic resizing API stats
[ https://issues.apache.org/jira/browse/TS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196345#comment-14196345 ] Susan Hinrichs commented on TS-454: --- Related to work for reducing number of callbacks for states. Not sure there is a bug created for that work yet. [~jtblatt] is directing that effort. > Dynamic resizing API stats > -- > > Key: TS-454 > URL: https://issues.apache.org/jira/browse/TS-454 > Project: Traffic Server > Issue Type: Bug > Components: Metrics >Reporter: Leif Hedstrom > Fix For: sometime > > > This is a new bug, as introduced with TS-390. We do not properly allow to > resize the librecords container, not allowing API (plugins) to create the > requested number of stats "slots". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 client is broken
[ https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-464: -- Fix Version/s: (was: sometime) 5.3.0 > Chunked response with bad Content-Length header to HTTP/1.0 client is broken > > > Key: TS-464 > URL: https://issues.apache.org/jira/browse/TS-464 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: HTTP, Violation > Fix For: 5.3.0 > > > A client sends an HTTP/1.0 request through ATS, which gets proxied with > HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) > returns with both > Content-Length: 10 > Transfer-Encoding: chunked > and a chunked body which is > 10 bytes long. In this case, ATS should still > respond with an HTTP/1.0 response, undoing the chunking, and return with an > appropriate CL: header. We do everything, except set the correct > Content-Length header, we simply return the erroneous CL header that the > Origin provided. This is not allowed in the RFC. > (Originally discovered using Coadvisor). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 client is broken
[ https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-464: -- Assignee: Leif Hedstrom > Chunked response with bad Content-Length header to HTTP/1.0 client is broken > > > Key: TS-464 > URL: https://issues.apache.org/jira/browse/TS-464 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: HTTP, Violation > Fix For: 5.3.0 > > > A client sends an HTTP/1.0 request through ATS, which gets proxied with > HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) > returns with both > Content-Length: 10 > Transfer-Encoding: chunked > and a chunked body which is > 10 bytes long. In this case, ATS should still > respond with an HTTP/1.0 response, undoing the chunking, and return with an > appropriate CL: header. We do everything, except set the correct > Content-Length header, we simply return the erroneous CL header that the > Origin provided. This is not allowed in the RFC. > (Originally discovered using Coadvisor). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-337) Cache Replacement Algorithm plug-in API
[ https://issues.apache.org/jira/browse/TS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196348#comment-14196348 ] Alan M. Carroll commented on TS-337: I will look at this as part of the Cache Toolkit work. > Cache Replacement Algorithm plug-in API > --- > > Key: TS-337 > URL: https://issues.apache.org/jira/browse/TS-337 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 2.0.0 >Reporter: Mark Nottingham >Assignee: Alan M. Carroll > Fix For: sometime > > > New cache replacement algorithms are often proposed, and often it's not a > "one size fits all" problem; different workloads require different approaches. > To facilitate this, TS should have a pluggable cache replacement policy API, > both for the memory and disk cache. > Squid has done this to good effect; see > http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/repl/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-467) Proxy should not forward request headers that matches a Connection token
[ https://issues.apache.org/jira/browse/TS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-467: - Assignee: Susan Hinrichs > Proxy should not forward request headers that matches a Connection token > > > Key: TS-467 > URL: https://issues.apache.org/jira/browse/TS-467 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Labels: CoAdvisor > Fix For: 5.3.0 > > > If a client sends a request like > X-foobar: fum > Connection: ,,X-foobar,, > the proxy (Traffic Server) MUST remove the header X-foobar before forwarding > the request. From the RFC: > HTTP/1.1 proxies MUST parse the Connection header field before a >message is forwarded and, for each connection-token in this field, >remove any header field(s) from the message with the same name as the >connection-token. > and > A system receiving an HTTP/1.0 (or lower-version) message that >includes a Connection header MUST, for each connection-token in this >field, remove and ignore any header field(s) from the message with >the same name as the connection-token. > (Originally discovered with Coadvisor). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-337) Cache Replacement Algorithm plug-in API
[ https://issues.apache.org/jira/browse/TS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-337. -- Resolution: Later > Cache Replacement Algorithm plug-in API > --- > > Key: TS-337 > URL: https://issues.apache.org/jira/browse/TS-337 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 2.0.0 >Reporter: Mark Nottingham >Assignee: Alan M. Carroll > Fix For: sometime > > > New cache replacement algorithms are often proposed, and often it's not a > "one size fits all" problem; different workloads require different approaches. > To facilitate this, TS should have a pluggable cache replacement policy API, > both for the memory and disk cache. > Squid has done this to good effect; see > http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/repl/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-467) Proxy should not forward request headers that matches a Connection token
[ https://issues.apache.org/jira/browse/TS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-467: -- Fix Version/s: (was: sometime) 5.3.0 > Proxy should not forward request headers that matches a Connection token > > > Key: TS-467 > URL: https://issues.apache.org/jira/browse/TS-467 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Labels: CoAdvisor > Fix For: 5.3.0 > > > If a client sends a request like > X-foobar: fum > Connection: ,,X-foobar,, > the proxy (Traffic Server) MUST remove the header X-foobar before forwarding > the request. From the RFC: > HTTP/1.1 proxies MUST parse the Connection header field before a >message is forwarded and, for each connection-token in this field, >remove any header field(s) from the message with the same name as the >connection-token. > and > A system receiving an HTTP/1.0 (or lower-version) message that >includes a Connection header MUST, for each connection-token in this >field, remove and ignore any header field(s) from the message with >the same name as the connection-token. > (Originally discovered with Coadvisor). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-382) socket option "cleanup" (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-382: -- Assignee: James Peach > socket option "cleanup" (and bug fixes) > --- > > Key: TS-382 > URL: https://issues.apache.org/jira/browse/TS-382 > Project: Traffic Server > Issue Type: Bug > Components: Network >Reporter: Leif Hedstrom >Assignee: James Peach > Fix For: sometime > > > This is a bug moved from Y! Bugzilla, I'm posting the original bug > description and a few comments separately. Note that the bug description is > fairly limited, but while looking at this code, I noticed a lot of oddities > with the "socket option" support (lots of hardcoded stuff, and most of it is > not configurable). > Note that the original bug should have been fixed already in Apache TS, but > the other comments are still applicable. > From Bugzilla (posted by Leif): > We have two socket option config options in records.config: > proxy.config.net.sock_option_flag_in > proxy.config.net.sock_option_flag_out > With accept thread enabled, at least the _in option isn't honored. There are > possibly other cases in UnixNetAccept.cc > that we don't honor these flags either. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-469) A PUT request should invalidate a previously cached object with the same URI
[ https://issues.apache.org/jira/browse/TS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-469: -- Assignee: (was: Bryan Call) > A PUT request should invalidate a previously cached object with the same URI > > > Key: TS-469 > URL: https://issues.apache.org/jira/browse/TS-469 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.6 >Reporter: Leif Hedstrom > Labels: CoAdvisor > Fix For: sometime > > > If the client first fetches an object with GET, and TS caches it, a > subsequent PUT request for the same URL should invalidate the cached object. > Update: This is a problem with PUT/POST when the response from the origin is > a 201, and there is a Location: header. We then must also invalidate any > cached object for the URL which the Location header refers to > (Originally discovered with Coadvisor). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-469) A PUT request should invalidate a previously cached object with the same URI
[ https://issues.apache.org/jira/browse/TS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-469: -- Fix Version/s: (was: 5.2.0) sometime > A PUT request should invalidate a previously cached object with the same URI > > > Key: TS-469 > URL: https://issues.apache.org/jira/browse/TS-469 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.6 >Reporter: Leif Hedstrom > Labels: CoAdvisor > Fix For: sometime > > > If the client first fetches an object with GET, and TS caches it, a > subsequent PUT request for the same URL should invalidate the cached object. > Update: This is a problem with PUT/POST when the response from the origin is > a 201, and there is a Location: header. We then must also invalidate any > cached object for the URL which the Location header refers to > (Originally discovered with Coadvisor). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-481) Missing remap support for two cases
[ https://issues.apache.org/jira/browse/TS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-481: - Assignee: Susan Hinrichs > Missing remap support for two cases > --- > > Key: TS-481 > URL: https://issues.apache.org/jira/browse/TS-481 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Fix For: sometime > > > There are two cases where the remap processor is not used, but it should. As > of v2.1.4, the broken support was removed (broken code is worse than no > code), making two cases not use / support "remap" features. Both cases > currently call request_url_remap() which is now set to return false. The two > cases are > 1) If you configure remap mode to be URL_REMAP_FOR_OS (2). This is an > undocumented feature, I don't even know when or why you'd want to use it. The > setting in RecordsConfig.cc is proxy.config.url_remap.url_remap_mode, which > defaults to "1". > 2) If TS uses "raw" connections, I think for example when using the CONNECT > method, we will not do remap rules. This would be in a forward proxy mode, > primarily for things like HTTPS afaik. > I don't think either case are critical to get support for the remap processor > for v2.2, but please adjust the fix version if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-481) Missing remap support for two cases
[ https://issues.apache.org/jira/browse/TS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-481: -- Assignee: Leif Hedstrom (was: Susan Hinrichs) > Missing remap support for two cases > --- > > Key: TS-481 > URL: https://issues.apache.org/jira/browse/TS-481 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: sometime > > > There are two cases where the remap processor is not used, but it should. As > of v2.1.4, the broken support was removed (broken code is worse than no > code), making two cases not use / support "remap" features. Both cases > currently call request_url_remap() which is now set to return false. The two > cases are > 1) If you configure remap mode to be URL_REMAP_FOR_OS (2). This is an > undocumented feature, I don't even know when or why you'd want to use it. The > setting in RecordsConfig.cc is proxy.config.url_remap.url_remap_mode, which > defaults to "1". > 2) If TS uses "raw" connections, I think for example when using the CONNECT > method, we will not do remap rules. This would be in a forward proxy mode, > primarily for things like HTTPS afaik. > I don't think either case are critical to get support for the remap processor > for v2.2, but please adjust the fix version if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-510) API: Add documentation for HTTP Status code counters in stats (TS-509)
[ https://issues.apache.org/jira/browse/TS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-510: - Assignee: Susan Hinrichs > API: Add documentation for HTTP Status code counters in stats (TS-509) > -- > > Key: TS-510 > URL: https://issues.apache.org/jira/browse/TS-510 > Project: Traffic Server > Issue Type: Bug > Components: Documentation, TS API >Affects Versions: 2.1.6 >Reporter: Theo Schlossnagle >Assignee: Susan Hinrichs > Fix For: Docs > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-510) API: Add documentation for HTTP Status code counters in stats (TS-509)
[ https://issues.apache.org/jira/browse/TS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-510: -- Assignee: (was: Susan Hinrichs) > API: Add documentation for HTTP Status code counters in stats (TS-509) > -- > > Key: TS-510 > URL: https://issues.apache.org/jira/browse/TS-510 > Project: Traffic Server > Issue Type: Bug > Components: Documentation, TS API >Affects Versions: 2.1.6 >Reporter: Theo Schlossnagle > Fix For: Docs > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs reassigned TS-518: - Assignee: Susan Hinrichs (was: James Peach) > Close UA connection early if the origin sent Connection close:, there's a bad > Content-Length header, and the UA connection has Keep-Alive. > -- > > Key: TS-518 > URL: https://issues.apache.org/jira/browse/TS-518 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > > In a very special case, we could improve the user experience by forcefully > closing the connection early. The case is > 1) The origin server sends a Content-Length: header that is wrong, where the > CL: value exceeds the actually body size. > 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 > without keep-alive. > 3) The client (and TS) uses Keep-Alive to the UA. > In this case, we can end up stalling the UA until either the UA or the TS > connection times out. It might make sense to prematurely disconnect the > client when this case is detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196370#comment-14196370 ] Alan M. Carroll commented on TS-518: Is it presumed the origin server has sent a FIN or RST on the connection? > Close UA connection early if the origin sent Connection close:, there's a bad > Content-Length header, and the UA connection has Keep-Alive. > -- > > Key: TS-518 > URL: https://issues.apache.org/jira/browse/TS-518 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > > In a very special case, we could improve the user experience by forcefully > closing the connection early. The case is > 1) The origin server sends a Content-Length: header that is wrong, where the > CL: value exceeds the actually body size. > 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 > without keep-alive. > 3) The client (and TS) uses Keep-Alive to the UA. > In this case, we can end up stalling the UA until either the UA or the TS > connection times out. It might make sense to prematurely disconnect the > client when this case is detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196373#comment-14196373 ] Susan Hinrichs commented on TS-518: --- Need to verify that the UA is being shutdown. Things have changed in this area recently. > Close UA connection early if the origin sent Connection close:, there's a bad > Content-Length header, and the UA connection has Keep-Alive. > -- > > Key: TS-518 > URL: https://issues.apache.org/jira/browse/TS-518 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > > In a very special case, we could improve the user experience by forcefully > closing the connection early. The case is > 1) The origin server sends a Content-Length: header that is wrong, where the > CL: value exceeds the actually body size. > 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 > without keep-alive. > 3) The client (and TS) uses Keep-Alive to the UA. > In this case, we can end up stalling the UA until either the UA or the TS > connection times out. It might make sense to prematurely disconnect the > client when this case is detected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-608: -- Assignee: (was: Bin Chen) > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 5.2.0 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-608: -- Assignee: Bryan Call > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Bryan Call > Fix For: 5.2.0 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-641) WebUI: Kill it with fire.
[ https://issues.apache.org/jira/browse/TS-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-641: -- Assignee: Leif Hedstrom > WebUI: Kill it with fire. > - > > Key: TS-641 > URL: https://issues.apache.org/jira/browse/TS-641 > Project: Traffic Server > Issue Type: Improvement > Components: Web UI >Reporter: Igor Galić >Assignee: Leif Hedstrom > Fix For: sometime > > Original Estimate: 14m > Remaining Estimate: 14m > > Get rid of proxy/mgmt/html2 > Get rid of all code in proxy/mgmt/web2 that is not used > Merge used code into proxy/mgmt/utils/WebMgmtUtils.* -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-654: -- Assignee: Alan M. Carroll (was: portl4t) > request for support of Layer7 http health checking for Origin Servers > - > > Key: TS-654 > URL: https://issues.apache.org/jira/browse/TS-654 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Affects Versions: 3.0.0 >Reporter: Zhao Yongming >Assignee: Alan M. Carroll > Attachments: HCUtil.cc, hc.patch > > > this ticket is for the L7 health checking project: > https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-654: -- Fix Version/s: (was: 5.3.0) > request for support of Layer7 http health checking for Origin Servers > - > > Key: TS-654 > URL: https://issues.apache.org/jira/browse/TS-654 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Affects Versions: 3.0.0 >Reporter: Zhao Yongming >Assignee: Alan M. Carroll > Attachments: HCUtil.cc, hc.patch > > > this ticket is for the L7 health checking project: > https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3166) HostDB Upgrade
Alan M. Carroll created TS-3166: --- Summary: HostDB Upgrade Key: TS-3166 URL: https://issues.apache.org/jira/browse/TS-3166 Project: Traffic Server Issue Type: Improvement Components: HostDB, DNS Reporter: Alan M. Carroll Implement the HostDB upgrade as described in https://cwiki.apache.org/confluence/download/attachments/47384310/ApacheCon-2014-Host-Resolution.pdf?version=1&modificationDate=1414085058000&api=v2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-658: -- Assignee: Alan M. Carroll (was: Phil Sorber) > HTTP SM holds the cache write lock for too long > --- > > Key: TS-658 > URL: https://issues.apache.org/jira/browse/TS-658 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Labels: A > Fix For: 5.2.0 > > > It seems we open the cache for write very early on in the HTTP SM, which can > have very bad effect on performance if the object is not cacheable. It's not > totally clear as to why this is done this way, but we should examine this for > v3.1, and try to minimize how long we hold the lock. It's possible this is > related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-656) reimplement Connection Collapsing in a smooth way
[ https://issues.apache.org/jira/browse/TS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-656. - Resolution: Duplicate Addressed via documentation. Remainder addressed by ts-2604. > reimplement Connection Collapsing in a smooth way > - > > Key: TS-656 > URL: https://issues.apache.org/jira/browse/TS-656 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 2.1.6 > Environment: per discussed in IRC, we'd like to clean the current CC > codes from trunk. >Reporter: Zhao Yongming > Fix For: 5.3.0 > > > we should figure out how to implement the Connection Collapsing that not so > ugly. target for V3.1 or so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-656) reimplement Connection Collapsing in a smooth way
[ https://issues.apache.org/jira/browse/TS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-656: -- Fix Version/s: (was: 5.3.0) > reimplement Connection Collapsing in a smooth way > - > > Key: TS-656 > URL: https://issues.apache.org/jira/browse/TS-656 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 2.1.6 > Environment: per discussed in IRC, we'd like to clean the current CC > codes from trunk. >Reporter: Zhao Yongming > > we should figure out how to implement the Connection Collapsing that not so > ugly. target for V3.1 or so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-658: -- Fix Version/s: (was: 5.2.0) sometime > HTTP SM holds the cache write lock for too long > --- > > Key: TS-658 > URL: https://issues.apache.org/jira/browse/TS-658 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Labels: A > Fix For: sometime > > > It seems we open the cache for write very early on in the HTTP SM, which can > have very bad effect on performance if the object is not cacheable. It's not > totally clear as to why this is done this way, but we should examine this for > v3.1, and try to minimize how long we hold the lock. It's possible this is > related to read_while_writer, but then it should be modified IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-727) Do we need support for "streams" partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-727. - Resolution: Duplicate > Do we need support for "streams" partitions? > > > Key: TS-727 > URL: https://issues.apache.org/jira/browse/TS-727 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Labels: CacheToolKit > Fix For: 6.0.0 > > > There's code in the cache related to MIXT streams volumes (caches). Since we > don't support streams, I'm thinking this code could be removed? Or > alternatively, we should expose APIs so that someone writing a plugin and > wish to store a different protocol (e.g. QT) can register this media type > with the API and core. The idea being that the core only contains protocols > that are in the core, but expose the cache core so that plugins can take > advantage of it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-727) Do we need support for "streams" partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-727: -- Fix Version/s: (was: 6.0.0) > Do we need support for "streams" partitions? > > > Key: TS-727 > URL: https://issues.apache.org/jira/browse/TS-727 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Labels: CacheToolKit > > There's code in the cache related to MIXT streams volumes (caches). Since we > don't support streams, I'm thinking this code could be removed? Or > alternatively, we should expose APIs so that someone writing a plugin and > wish to store a different protocol (e.g. QT) can register this media type > with the API and core. The idea being that the core only contains protocols > that are in the core, but expose the cache core so that plugins can take > advantage of it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-754) Reduce memory usage on idle connections
[ https://issues.apache.org/jira/browse/TS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-754: - Labels: (was: A) > Reduce memory usage on idle connections > --- > > Key: TS-754 > URL: https://issues.apache.org/jira/browse/TS-754 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom >Assignee: Bryan Call > Fix For: 5.3.0 > > > We should examine what memory (if any) can be returned to class allocators / > freelist when a connection is idle (in keep-alive). Right now, I suspect we > hold on to more memory than is necessary, which limits the number of KA > connections a server can have. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-767) Make the cluster interface configurable
[ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-767. - Resolution: Duplicate Fix Version/s: (was: sometime) Already addressed by Http proxy port issues. > Make the cluster interface configurable > --- > > Key: TS-767 > URL: https://issues.apache.org/jira/browse/TS-767 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Network >Affects Versions: 2.1.8 >Reporter: Arno Toell >Priority: Minor > > I consider the way how Traffic Server opens listening ports dangerous, or at > least more risky than necessary. Currently ATS allows to configure port > numbers for the related services, but not the listening interface. Instead it > binds to 0.0.0.0. Therefore I'd like to suggest > * -Allow the user to specify a listening interface, don't assume 0.0.0.0 > suits for all setups.- > * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless > proxy.local.cluster.type is set to enable clustering (!= 3). I think > _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS > locally. If so it should be bound to the loop back at least or using Unix > Domain Sockets or whatever local socket method you prefer.- > * Disable the "reliable service port" (i.e. 8088 by default) unless > proxy.local.cluster.type enables clustering. Similar to the > "autoconfiguration port". If _traffic_cop_ (or something else on the local > machine) is using this port, the same suggestions apply as above. > * -The "internal communication port" (8084) should not open a public socket > at all. Instead use Unix Domain Sockets or something similar.- > n.b. striked through issues are obsolete or tracked in TS-765. For the > remaining issue is worth to be added the comment from TS-765: > 8088 is no problem anymore until clustering is enabled, so there is only the > TS-766 improvement left there. However if enabled, I think it is still fairly > useful to allow the user to bind to a specific IP. Say, you run a public > facing proxy in cluster mode where you want to communicate in between on > private IPs between cluster peers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-767) Make the cluster interface configurable
[ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196421#comment-14196421 ] Susan Hinrichs edited comment on TS-767 at 11/4/14 5:40 PM: Already addressed by Http proxy port issues. Reworked port specification with the IPv6 additions. was (Author: shinrich): Already addressed by Http proxy port issues. > Make the cluster interface configurable > --- > > Key: TS-767 > URL: https://issues.apache.org/jira/browse/TS-767 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Network >Affects Versions: 2.1.8 >Reporter: Arno Toell >Priority: Minor > > I consider the way how Traffic Server opens listening ports dangerous, or at > least more risky than necessary. Currently ATS allows to configure port > numbers for the related services, but not the listening interface. Instead it > binds to 0.0.0.0. Therefore I'd like to suggest > * -Allow the user to specify a listening interface, don't assume 0.0.0.0 > suits for all setups.- > * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless > proxy.local.cluster.type is set to enable clustering (!= 3). I think > _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS > locally. If so it should be bound to the loop back at least or using Unix > Domain Sockets or whatever local socket method you prefer.- > * Disable the "reliable service port" (i.e. 8088 by default) unless > proxy.local.cluster.type enables clustering. Similar to the > "autoconfiguration port". If _traffic_cop_ (or something else on the local > machine) is using this port, the same suggestions apply as above. > * -The "internal communication port" (8084) should not open a public socket > at all. Instead use Unix Domain Sockets or something similar.- > n.b. striked through issues are obsolete or tracked in TS-765. For the > remaining issue is worth to be added the comment from TS-765: > 8088 is no problem anymore until clustering is enabled, so there is only the > TS-766 improvement left there. However if enabled, I think it is still fairly > useful to allow the user to bind to a specific IP. Say, you run a public > facing proxy in cluster mode where you want to communicate in between on > private IPs between cluster peers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-777) Increasing logbuffer size makes us "drop" log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-777: -- Fix Version/s: (was: 5.2.0) 5.3.0 > Increasing logbuffer size makes us "drop" log entries > - > > Key: TS-777 > URL: https://issues.apache.org/jira/browse/TS-777 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 2.1.8 >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: A > Fix For: 5.3.0 > > > Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB > makes us start losing log entries. This is bad, since increasing this setting > could be a way to increase performance for busy systems. I've for now set the > defaults to 16KB, which seems to be stable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-795:
--
Fix Version/s: (was: 5.2.0)
sometime
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K,/* 3 */
> BUFFER_SIZE_INDEX_2K,/* 4 */
> BUFFER_SIZE_INDEX_4K,/* 5 */
> BUFFER_SIZE_INDEX_8K,/* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M,/* 13 */
> BUFFER_SIZE_INDEX_2M,/* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196430#comment-14196430
]
Alan M. Carroll commented on TS-795:
I should contribute my NumericTypeId class for this.
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K,/* 3 */
> BUFFER_SIZE_INDEX_2K,/* 4 */
> BUFFER_SIZE_INDEX_4K,/* 5 */
> BUFFER_SIZE_INDEX_8K,/* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M,/* 13 */
> BUFFER_SIZE_INDEX_2M,/* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-802) Unique KA pools for SOCKS/src IP parameters
[ https://issues.apache.org/jira/browse/TS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-802. - Resolution: Duplicate > Unique KA pools for SOCKS/src IP parameters > --- > > Key: TS-802 > URL: https://issues.apache.org/jira/browse/TS-802 > Project: Traffic Server > Issue Type: Wish > Components: HTTP >Reporter: M. Nunberg > Fix For: sometime > > > From what I've observed, ATS' keepalive/connection cache only indexes by the > OS server or next proxy server, but not by other types of > connection/transport/socket parameters, specifically in my case, negotiated > SOCKS connections and outgoing connections which are bound to a specific > source IP > Is it possible to have such functionality in the near future? Currently I've > been forced to write my own 'KA gateway' which pretends to be an HTTP server > (to which ATS can maintain unique connections) and have that do SOCKS/source > ip bind()ing for me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-802) Unique KA pools for SOCKS/src IP parameters
[ https://issues.apache.org/jira/browse/TS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-802: -- Fix Version/s: (was: sometime) > Unique KA pools for SOCKS/src IP parameters > --- > > Key: TS-802 > URL: https://issues.apache.org/jira/browse/TS-802 > Project: Traffic Server > Issue Type: Wish > Components: HTTP >Reporter: M. Nunberg > > From what I've observed, ATS' keepalive/connection cache only indexes by the > OS server or next proxy server, but not by other types of > connection/transport/socket parameters, specifically in my case, negotiated > SOCKS connections and outgoing connections which are bound to a specific > source IP > Is it possible to have such functionality in the near future? Currently I've > been forced to write my own 'KA gateway' which pretends to be an HTTP server > (to which ATS can maintain unique connections) and have that do SOCKS/source > ip bind()ing for me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-803) Fix SOCKS breakage and allow for setting next-hop SOCKS
[
https://issues.apache.org/jira/browse/TS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs closed TS-803.
-
Resolution: Won't Fix
Fix Version/s: (was: sometime)
If someone wishes to fix, please provide a patch against the current master.
> Fix SOCKS breakage and allow for setting next-hop SOCKS
> ---
>
> Key: TS-803
> URL: https://issues.apache.org/jira/browse/TS-803
> Project: Traffic Server
> Issue Type: New Feature
> Components: Network
>Affects Versions: 3.0.0
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
>
> Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7
> unstable/git. There are some quirks here, and I'm not that sure any more what
> this patch does exactly. However it:
> 1) Does fix SOCKS connections in general
> 2) Allows setting next-hop SOCKS proxy via the API
> Problems:
> See https://issues.apache.org/jira/browse/TS-802
> This has no effect on connections which are drawn from the connection pool,
> as it seems ATS currently doesn't maintain unique identities for peripheral
> connection params (source IP, SOCKS etc); i.e. this only affects new TCP
> connections to an OS.
> diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h
> tsgit217/iocore/net/I_NetVConnection.h
> --- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0
> +
> @@ -120,6 +120,13 @@
>/// Version of SOCKS to use.
>unsigned char socks_version;
> + struct {
> + unsigned int ip;
> + int port;
> + char *username;
> + char *password;
> + } socks_override;
> +
>int socket_recv_bufsize;
>int socket_send_bufsize;
> Only in tsgit217/iocore/net: Makefile
> Only in tsgit217/iocore/net: Makefile.in
> diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
> --- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
> @@ -126,7 +126,7 @@
>unsigned char version;
>bool write_done;
> -
> + bool manual_parent_selection;
>SocksAuthHandler auth_handler;
>unsigned char socks_cmd;
> @@ -145,7 +145,8 @@
> SocksEntry():Continuation(NULL), netVConnection(0),
> ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
> -lerrno(0), timeout(0), version(5), write_done(false),
> auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
> +lerrno(0), timeout(0), version(5), write_done(false),
> manual_parent_selection(false),
> +auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
>{
>}
> };
> diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
> --- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
> @@ -73,7 +73,8 @@
>nattempts = 0;
>findServer();
> - timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +// timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> + timeout = this_ethread()->schedule_in(this, HRTIME_SECONDS(5));
>write_done = false;
> }
> @@ -81,6 +82,15 @@
> SocksEntry::findServer()
> {
>nattempts++;
> + if(manual_parent_selection) {
> + if(nattempts > 1) {
> + //Nullify IP and PORT
> + server_ip = -1;
> + server_port = 0;
> + }
> + Debug("mndebug(Socks)", "findServer() is a noop with manual socks
> selection");
> + return;
> + }
> #ifdef SOCKS_WITH_TS
>if (nattempts == 1) {
> @@ -187,7 +197,6 @@
> }
> Debug("Socks", "Failed to connect to %u.%u.%u.%u:%d",
> PRINT_IP(server_ip), server_port);
> -
> findServer();
> if (server_ip == (uint32_t) - 1) {
> diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc
> tsgit217/iocore/net/UnixNetProcessor.cc
> --- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0
> +
> @@ -228,6 +228,11 @@
>!socks_conf_stuff->ip_range.match(ip))
> #endif
> );
> + if(opt->socks_override.ip >= 1) {
> + using_socks = true;
> + Debug("mndebug", "trying to set using_socks to true");
> + }
> +
>SocksEntry *socksEntry = NULL;
> #endif
>NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
> @@ -242,6 +247,16 @@
>if (using_socks) {
> Debug("Socks", "Using Socks ip: %u.%u.%u.%u:%d\n", PRINT_IP(ip), port);
> socksEntry = socksAllocator.alloc();
> +
> +if (opt->socks_override.ip) {
> +//Needs to be done before socksEntry->init()
> +
[jira] [Closed] (TS-817) TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests
[ https://issues.apache.org/jira/browse/TS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-817. - Resolution: Invalid Fix Version/s: (was: 5.2.0) > TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests > > > Key: TS-817 > URL: https://issues.apache.org/jira/browse/TS-817 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.0 >Reporter: Naveen > Labels: api-change, function > > The API calls TSFetchUrl/TSFetchPages do not work with HTTP/1.1 requests. The > implementation seems to use the "end of the connection" to signal the user > callback function, which is not the case on persistent connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-829: -- Fix Version/s: (was: sometime) 5.3.0 > socks stats cleanup - some stats are registered, but not used > - > > Key: TS-829 > URL: https://issues.apache.org/jira/browse/TS-829 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.0 >Reporter: Bryan Call >Priority: Minor > Fix For: 5.3.0 > > > From reviewing TS-818 I noticed that the stats that were being double > resisted are not used. Some cleanup work should be done for the socks stats. > Stats that are registered, but not used in the code: > [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc > "proxy.process.socks.connections_successful", > "proxy.process.socks.connections_unsuccessful", > "proxy.process.socks.connections_currently_open", > These stats are used some tests, so maybe they should be added back into the > code. > [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match > proxy.process.socks.connections_ * > iocore/net/Net.cc > mgmt/api/remote/APITestCliRemote.cc > test/plugin/test-mgmt/test-mgmt.c > I did however see these stats being used: > [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * > proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-829: -- Assignee: Bryan Call > socks stats cleanup - some stats are registered, but not used > - > > Key: TS-829 > URL: https://issues.apache.org/jira/browse/TS-829 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.0.0 >Reporter: Bryan Call >Assignee: Bryan Call >Priority: Minor > Fix For: 5.3.0 > > > From reviewing TS-818 I noticed that the stats that were being double > resisted are not used. Some cleanup work should be done for the socks stats. > Stats that are registered, but not used in the code: > [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc > "proxy.process.socks.connections_successful", > "proxy.process.socks.connections_unsuccessful", > "proxy.process.socks.connections_currently_open", > These stats are used some tests, so maybe they should be added back into the > code. > [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match > proxy.process.socks.connections_ * > iocore/net/Net.cc > mgmt/api/remote/APITestCliRemote.cc > test/plugin/test-mgmt/test-mgmt.c > I did however see these stats being used: > [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * > proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); > proxy/SocksProxy.cc: > SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-852) hostdb and dns system hangup
[
https://issues.apache.org/jira/browse/TS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-852:
--
Fix Version/s: (was: sometime)
> hostdb and dns system hangup
>
>
> Key: TS-852
> URL: https://issues.apache.org/jira/browse/TS-852
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, DNS
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
>Assignee: Phil Sorber
>Priority: Minor
> Labels: dns, hostdb
> Fix For: 3.1.0
>
> Attachments: TS-852.patch
>
>
> in my testing, all request that need go OS, fails with 30s timeout, and the
> slow query shows data from dns missed:
> {code}
> [Jun 22 15:33:47.183] Server {1106880832} ERROR: [8122411] Slow Request: url:
> http://download.im.alisoft.com/aliim/AliIM6/update/packages//2011-5-4-10-10-40/0/modulesproxy/8203.xml.wwzip
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.667 sm_finish: 30.667
> [Jun 22 15:33:47.220] Server {1099663680} ERROR: [8122422] Slow Request: url:
> http://img.uu1001.cn/materials/original/2010-11-22/22-48/a302876929a9c40a8272ac439a16ad25e74edf71.png
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.318 sm_finish: 30.318
> [Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122421] Slow Request: url:
> http://img02.taobaocdn.com/bao/uploaded/i2/T1mp8QXopdXXblNIZ6_061203.jpg_b.jpg
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.597 sm_finish: 30.597
> [Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122409] Slow Request: url:
> http://img04.taobaocdn.com/tps/i4/T1EM9gXltt-440-135.jpg status: 0
> unique id: bytes: 0 fd: 0 client state: 6 server state: 0 ua_begin: 0.000
> ua_read_header_done: 0.000 cache_open_read_begin: 0.000 cache_open_read_end:
> 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000 server_connect: -1.000
> server_first_read: -1.000 server_read_header_done: -1.000 server_close:
> -1.000 ua_close: 30.948 sm_finish: 30.948
> {code}
> all http SM show from {http} in DNS_LOOKUP
> and traffic.out show nothing with error, when I enable debug on
> hostdb.*|dns.*:
> {code}
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) probe
> img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) timeout 64204
> 1308663404 300
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) delaying force 0
> answer for img03.taobaocdn.com [timeout 0]
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) probe
> img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) timeout 64204
> 1308663404 300
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) DNS
> img03.taobaocdn.com
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) enqueuing
> additional request
> [Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) probe 127.0.0.1
> E9B7563422C93608 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) immediate
> answer for 127.0.0.1
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) probe
> img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) timeout 64281
> 1308663327 300
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) delaying force 0
> answer for img08.taobaocdn.com [timeout 0]
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) probe
> img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) timeout 64281
> 1308663327 300
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) DNS
> img08.taobaocdn.com
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) enqueuing
> additional request
> [Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb) probe 127.0.0.1
> E9B7563422C93608 1 [ignore_timeout = 0]
> [Jun 22 15:27:
[jira] [Updated] (TS-852) hostdb and dns system hangup
[
https://issues.apache.org/jira/browse/TS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-852:
---
Fix Version/s: sometime
> hostdb and dns system hangup
>
>
> Key: TS-852
> URL: https://issues.apache.org/jira/browse/TS-852
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, DNS
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
>Assignee: Phil Sorber
>Priority: Minor
> Labels: dns, hostdb
> Fix For: 3.1.0, sometime
>
> Attachments: TS-852.patch
>
>
> in my testing, all request that need go OS, fails with 30s timeout, and the
> slow query shows data from dns missed:
> {code}
> [Jun 22 15:33:47.183] Server {1106880832} ERROR: [8122411] Slow Request: url:
> http://download.im.alisoft.com/aliim/AliIM6/update/packages//2011-5-4-10-10-40/0/modulesproxy/8203.xml.wwzip
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.667 sm_finish: 30.667
> [Jun 22 15:33:47.220] Server {1099663680} ERROR: [8122422] Slow Request: url:
> http://img.uu1001.cn/materials/original/2010-11-22/22-48/a302876929a9c40a8272ac439a16ad25e74edf71.png
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.318 sm_finish: 30.318
> [Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122421] Slow Request: url:
> http://img02.taobaocdn.com/bao/uploaded/i2/T1mp8QXopdXXblNIZ6_061203.jpg_b.jpg
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.597 sm_finish: 30.597
> [Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122409] Slow Request: url:
> http://img04.taobaocdn.com/tps/i4/T1EM9gXltt-440-135.jpg status: 0
> unique id: bytes: 0 fd: 0 client state: 6 server state: 0 ua_begin: 0.000
> ua_read_header_done: 0.000 cache_open_read_begin: 0.000 cache_open_read_end:
> 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000 server_connect: -1.000
> server_first_read: -1.000 server_read_header_done: -1.000 server_close:
> -1.000 ua_close: 30.948 sm_finish: 30.948
> {code}
> all http SM show from {http} in DNS_LOOKUP
> and traffic.out show nothing with error, when I enable debug on
> hostdb.*|dns.*:
> {code}
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) probe
> img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) timeout 64204
> 1308663404 300
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) delaying force 0
> answer for img03.taobaocdn.com [timeout 0]
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) probe
> img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) timeout 64204
> 1308663404 300
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) DNS
> img03.taobaocdn.com
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) enqueuing
> additional request
> [Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) probe 127.0.0.1
> E9B7563422C93608 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) immediate
> answer for 127.0.0.1
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) probe
> img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) timeout 64281
> 1308663327 300
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) delaying force 0
> answer for img08.taobaocdn.com [timeout 0]
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) probe
> img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) timeout 64281
> 1308663327 300
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) DNS
> img08.taobaocdn.com
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) enqueuing
> additional request
> [Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb) probe 127.0.0.1
> E9B7563422C93608 1 [ignore_timeout = 0]
> [Jun 22 15:27
[jira] [Updated] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-871:
--
Assignee: Leif Hedstrom
> Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
> ---
>
> Key: TS-871
> URL: https://issues.apache.org/jira/browse/TS-871
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.0
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: sometime
>
> Attachments: TS-871-20121107.diff, TS-871.diff,
> ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
> revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
> serf_revproxy.cap, stats.diff
>
>
> When accessing a remote subversion repository via http or https with svn 1.7,
> it will currently timeout:
> {noformat}
> igalic@tynix ~/src/asf % svn co
> http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
> svn: E020014: Unable to connect to a repository at URL
> 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
> svn: E020014: Unspecified error message: 504 Connection Timed Out
> 1 igalic@tynix ~/src/asf %
> {noformat}
> I have started traffic_server -Thttp and captured the output, which I'm
> attaching.
> There's also a capture from the network.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196463#comment-14196463
]
Bryan Call commented on TS-871:
---
@Leif Can you test again and see if it works with subversion?
> Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
> ---
>
> Key: TS-871
> URL: https://issues.apache.org/jira/browse/TS-871
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.0
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: sometime
>
> Attachments: TS-871-20121107.diff, TS-871.diff,
> ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
> revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
> serf_revproxy.cap, stats.diff
>
>
> When accessing a remote subversion repository via http or https with svn 1.7,
> it will currently timeout:
> {noformat}
> igalic@tynix ~/src/asf % svn co
> http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
> svn: E020014: Unable to connect to a repository at URL
> 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
> svn: E020014: Unspecified error message: 504 Connection Timed Out
> 1 igalic@tynix ~/src/asf %
> {noformat}
> I have started traffic_server -Thttp and captured the output, which I'm
> attaching.
> There's also a capture from the network.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196463#comment-14196463
]
Bryan Call edited comment on TS-871 at 11/4/14 5:59 PM:
[~zwoop] Can you test again and see if it works with subversion?
was (Author: bcall):
@Leif Can you test again and see if it works with subversion?
> Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
> ---
>
> Key: TS-871
> URL: https://issues.apache.org/jira/browse/TS-871
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.0.0
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: sometime
>
> Attachments: TS-871-20121107.diff, TS-871.diff,
> ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
> revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
> serf_revproxy.cap, stats.diff
>
>
> When accessing a remote subversion repository via http or https with svn 1.7,
> it will currently timeout:
> {noformat}
> igalic@tynix ~/src/asf % svn co
> http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
> svn: E020014: Unable to connect to a repository at URL
> 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
> svn: E020014: Unspecified error message: 504 Connection Timed Out
> 1 igalic@tynix ~/src/asf %
> {noformat}
> I have started traffic_server -Thttp and captured the output, which I'm
> attaching.
> There's also a capture from the network.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-879) Seek on cached file
[ https://issues.apache.org/jira/browse/TS-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll closed TS-879. -- Resolution: Duplicate > Seek on cached file > --- > > Key: TS-879 > URL: https://issues.apache.org/jira/browse/TS-879 > Project: Traffic Server > Issue Type: Bug > Components: Cache, TS API >Affects Versions: 3.0.0 >Reporter: Nelson Pérez >Assignee: Alan M. Carroll > Labels: api-addition, cache, trafficserver > Fix For: sometime > > > I want a custom written plugin to be able to seek to any point in a cached > file. According to John Plevyak > (http://www.mail-archive.com/dev@trafficserver.apache.org/msg02785.html) this > feature is new in the cache, but not yet available to the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-892) request for bulk setting in remap.config for refer filter
[
https://issues.apache.org/jira/browse/TS-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-892.
--
Resolution: Won't Fix
Closing in liu of future configuration refactoring.
> request for bulk setting in remap.config for refer filter
> -
>
> Key: TS-892
> URL: https://issues.apache.org/jira/browse/TS-892
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, HTTP
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
> Labels: remap
>
> when we put our TS online, we find out we are complex when handling squid's
> default filter rule such as:
> {code}
> acl ctoc referer_regex -i XXXa\.com\/ XXXb\.com\/ XXXc\.com\/
> http_access deny ctoc
> {code}
> we have to convert every map rule to map_with_referer, and get very ugly. if
> we can get the referer filter config in the bulk way as IP based filter in
> the remap.config, it will make the config file clear and clean
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-892) request for bulk setting in remap.config for refer filter
[
https://issues.apache.org/jira/browse/TS-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-892:
-
Fix Version/s: (was: sometime)
> request for bulk setting in remap.config for refer filter
> -
>
> Key: TS-892
> URL: https://issues.apache.org/jira/browse/TS-892
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, HTTP
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
> Labels: remap
>
> when we put our TS online, we find out we are complex when handling squid's
> default filter rule such as:
> {code}
> acl ctoc referer_regex -i XXXa\.com\/ XXXb\.com\/ XXXc\.com\/
> http_access deny ctoc
> {code}
> we have to convert every map rule to map_with_referer, and get very ugly. if
> we can get the referer filter config in the bulk way as IP based filter in
> the remap.config, it will make the config file clear and clean
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-893) the prefetch function in codes need more love to show up
[ https://issues.apache.org/jira/browse/TS-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-893: - Assignee: (was: Zhao Yongming) > the prefetch function in codes need more love to show up > > > Key: TS-893 > URL: https://issues.apache.org/jira/browse/TS-893 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Affects Versions: 3.0.0 >Reporter: Zhao Yongming > Fix For: sometime > > > the prefetch function in proxy is a good solution when you really need to > faster up your user download time, it can parse any allowed plean html file, > get all resource tags out and do batch loading from OS. I am going to preload > my site before we put it online, as it will get about 1 month to get the disk > full and hit rate stable. it is a cool feature but it have the following > issues: > 1, the prefetch config file is not managed well. ie, it is not managed by > cluster > 2, the it does not any document in the admin guide or old pdf file. > 3, prefetching just care plean html file, without compressing, should we do > some decompressing? is that possible? > hopes this is the starting of make prefetch really useful for some cutting > edge situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-852) hostdb and dns system hangup
[
https://issues.apache.org/jira/browse/TS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196472#comment-14196472
]
Susan Hinrichs commented on TS-852:
---
[~psudaemon] any additional thoughts on this.
> hostdb and dns system hangup
>
>
> Key: TS-852
> URL: https://issues.apache.org/jira/browse/TS-852
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, DNS
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
>Assignee: Phil Sorber
>Priority: Minor
> Labels: dns, hostdb
> Fix For: 3.1.0, sometime
>
> Attachments: TS-852.patch
>
>
> in my testing, all request that need go OS, fails with 30s timeout, and the
> slow query shows data from dns missed:
> {code}
> [Jun 22 15:33:47.183] Server {1106880832} ERROR: [8122411] Slow Request: url:
> http://download.im.alisoft.com/aliim/AliIM6/update/packages//2011-5-4-10-10-40/0/modulesproxy/8203.xml.wwzip
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.667 sm_finish: 30.667
> [Jun 22 15:33:47.220] Server {1099663680} ERROR: [8122422] Slow Request: url:
> http://img.uu1001.cn/materials/original/2010-11-22/22-48/a302876929a9c40a8272ac439a16ad25e74edf71.png
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.318 sm_finish: 30.318
> [Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122421] Slow Request: url:
> http://img02.taobaocdn.com/bao/uploaded/i2/T1mp8QXopdXXblNIZ6_061203.jpg_b.jpg
> status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
> ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
> cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 30.597 sm_finish: 30.597
> [Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122409] Slow Request: url:
> http://img04.taobaocdn.com/tps/i4/T1EM9gXltt-440-135.jpg status: 0
> unique id: bytes: 0 fd: 0 client state: 6 server state: 0 ua_begin: 0.000
> ua_read_header_done: 0.000 cache_open_read_begin: 0.000 cache_open_read_end:
> 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000 server_connect: -1.000
> server_first_read: -1.000 server_read_header_done: -1.000 server_close:
> -1.000 ua_close: 30.948 sm_finish: 30.948
> {code}
> all http SM show from {http} in DNS_LOOKUP
> and traffic.out show nothing with error, when I enable debug on
> hostdb.*|dns.*:
> {code}
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) probe
> img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) timeout 64204
> 1308663404 300
> [Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) delaying force 0
> answer for img03.taobaocdn.com [timeout 0]
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) probe
> img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) timeout 64204
> 1308663404 300
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) DNS
> img03.taobaocdn.com
> [Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) enqueuing
> additional request
> [Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) probe 127.0.0.1
> E9B7563422C93608 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) immediate
> answer for 127.0.0.1
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) probe
> img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) timeout 64281
> 1308663327 300
> [Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) delaying force 0
> answer for img08.taobaocdn.com [timeout 0]
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) probe
> img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) timeout 64281
> 1308663327 300
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) DNS
> img08.taobaocdn.com
> [Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) enqueuing
> additional request
> [Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb)
[jira] [Created] (TS-3167) Remove the prefetch feature
Susan Hinrichs created TS-3167: -- Summary: Remove the prefetch feature Key: TS-3167 URL: https://issues.apache.org/jira/browse/TS-3167 Project: Traffic Server Issue Type: Task Reporter: Susan Hinrichs In discussions with [~amc] and [~zwoop] and [~bcall], it was decided to remove the prefetch feature. It currently does not work. It would be best to remove the broken feature. If someone really needs this feature, then they can build a working feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3167) Remove the prefetch feature
[ https://issues.apache.org/jira/browse/TS-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3167: --- Assignee: Leif Hedstrom > Remove the prefetch feature > --- > > Key: TS-3167 > URL: https://issues.apache.org/jira/browse/TS-3167 > Project: Traffic Server > Issue Type: Task >Reporter: Susan Hinrichs >Assignee: Leif Hedstrom > > In discussions with [~amc] and [~zwoop] and [~bcall], it was decided to > remove the prefetch feature. It currently does not work. It would be best > to remove the broken feature. If someone really needs this feature, then > they can build a working feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-898: -- Assignee: Leif Hedstrom > fix potential problems from coverity scan > - > > Key: TS-898 > URL: https://issues.apache.org/jira/browse/TS-898 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0 > Environment: RHEL5 >Reporter: Bryan Call >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > Ran Coverity over the code and it reported 856 potential problems with the > code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-898) fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-898: -- Fix Version/s: (was: sometime) 5.2.0 > fix potential problems from coverity scan > - > > Key: TS-898 > URL: https://issues.apache.org/jira/browse/TS-898 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0 > Environment: RHEL5 >Reporter: Bryan Call >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > Ran Coverity over the code and it reported 856 potential problems with the > code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-904) when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule
[ https://issues.apache.org/jira/browse/TS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-904. - Resolution: Invalid Fix Version/s: (was: sometime) > when doing custom logging, it would be nice if we can set dedicate sampling > rate for each rule > -- > > Key: TS-904 > URL: https://issues.apache.org/jira/browse/TS-904 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Affects Versions: 3.0.0 >Reporter: Zhao Yongming >Priority: Minor > > the sampling is a global config in logging, we want to get it custom-able. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-905) Improve state machine around DNS lookups and handling of URL_REMAP_FOR_OS
[ https://issues.apache.org/jira/browse/TS-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-905. - Resolution: Duplicate Fix Version/s: (was: sometime) > Improve state machine around DNS lookups and handling of URL_REMAP_FOR_OS > - > > Key: TS-905 > URL: https://issues.apache.org/jira/browse/TS-905 > Project: Traffic Server > Issue Type: Improvement > Components: DNS, HTTP >Reporter: Leif Hedstrom > > The code around DNS lookups in the HTTP state machine is somewhat odd. The > same state is revisited at least twice in the case of a parent proxy lookup > for example, and the internal state is not reset in between such lookups. > This caused breakage of parent proxy when we added an API to bypass origin > DNS lookup, as a very obscure side effect. > Also, there's code in there for a remapping mode URL_REMAP_FOR_OS (2), which > I believe we have crippled, and it's unclear exactly when it would be used. > We should examine this, and either fix this mode, or disable it completely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3168) Remove Log Collation
Susan Hinrichs created TS-3168: -- Summary: Remove Log Collation Key: TS-3168 URL: https://issues.apache.org/jira/browse/TS-3168 Project: Traffic Server Issue Type: Task Components: Logging Reporter: Susan Hinrichs In discussion with [~amc], [~zwoop], and [~bcall], decided to remove this feature. Does not work. Better to use newer dedicated log sub systems and syslog-ng -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-910) log collation in custom log will make dedicate connection to the same collation server
[ https://issues.apache.org/jira/browse/TS-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs closed TS-910. - Resolution: Invalid Fix Version/s: (was: sometime) Removing feature. > log collation in custom log will make dedicate connection to the same > collation server > -- > > Key: TS-910 > URL: https://issues.apache.org/jira/browse/TS-910 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Affects Versions: 3.1.0 >Reporter: Zhao Yongming >Assignee: Zhao Yongming >Priority: Trivial > > when you define LogObject in logs_xml.config, and set CollationHosts, it will > open connections for each LogObject, despite you put the same host in > CollationHosts. > it will affect the default squid logging too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196504#comment-14196504 ] Susan Hinrichs commented on TS-935: --- [~briang] unassign yourself unless you are still working on it. > Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT > > > Key: TS-935 > URL: https://issues.apache.org/jira/browse/TS-935 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.1 >Reporter: Brian Geffon >Assignee: Brian Geffon > Labels: api-change > Fix For: sometime > > > When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon > the fact that the API will decrement the event count for EVENT_INTERNAL or > EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we > be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT > because as of now doing so would cause m_event_count to become -1 or > shouldn't these defined values be something different? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-946) Scheduling a continuation on all threads of a specific type
[ https://issues.apache.org/jira/browse/TS-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-946: -- Fix Version/s: (was: 5.2.0) 5.3.0 > Scheduling a continuation on all threads of a specific type > --- > > Key: TS-946 > URL: https://issues.apache.org/jira/browse/TS-946 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Affects Versions: 3.0.0 >Reporter: Leif Hedstrom > Fix For: 5.3.0 > > > It would be incredibly useful, both in the core and in plugin APIs, to be > able to schedule a continuation to run on all threads of a specific type. > E.g. in a plugin, something like > TSAction TSContScheduleOnThreads(TSCont cont, TSThreadPool tp); > This would be useful for e.g. setting up per-thread specifics from a plugin, > but quite possibly also from the core. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything
[ https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-966: -- Fix Version/s: (was: 5.2.0) 5.3.0 > cache.config dest_domain= dest_hostname= dest_ip= do not match anything > --- > > Key: TS-966 > URL: https://issues.apache.org/jira/browse/TS-966 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.0, 3.0.1 >Reporter: Igor Galić > Labels: A > Fix For: 5.3.0 > > > Caching policies are not applied when using these options to match targets. > It is also not very clear *what* dest_domain= vs dest_hostname= can match. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-946) Scheduling a continuation on all threads of a specific type
[ https://issues.apache.org/jira/browse/TS-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-946: -- Assignee: Leif Hedstrom > Scheduling a continuation on all threads of a specific type > --- > > Key: TS-946 > URL: https://issues.apache.org/jira/browse/TS-946 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Affects Versions: 3.0.0 >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > It would be incredibly useful, both in the core and in plugin APIs, to be > able to schedule a continuation to run on all threads of a specific type. > E.g. in a plugin, something like > TSAction TSContScheduleOnThreads(TSCont cont, TSThreadPool tp); > This would be useful for e.g. setting up per-thread specifics from a plugin, > but quite possibly also from the core. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-965: -- Fix Version/s: (was: 5.2.0) 5.3.0 > cache.config can't deal with both revalidate= and ttl-in-cache= specified > - > > Key: TS-965 > URL: https://issues.apache.org/jira/browse/TS-965 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.0, 3.0.1 >Reporter: Igor Galić > Labels: A > Fix For: 5.3.0 > > > If both of these options are specified (with the same time?), nothing is > cached at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-965: -- Assignee: Alan M. Carroll > cache.config can't deal with both revalidate= and ttl-in-cache= specified > - > > Key: TS-965 > URL: https://issues.apache.org/jira/browse/TS-965 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.0, 3.0.1 >Reporter: Igor Galić >Assignee: Alan M. Carroll > Labels: A > Fix For: 5.3.0 > > > If both of these options are specified (with the same time?), nothing is > cached at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-974) TS should have a mode to hold partial objects in cache
[ https://issues.apache.org/jira/browse/TS-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-974: -- Assignee: Alan M. Carroll > TS should have a mode to hold partial objects in cache > -- > > Key: TS-974 > URL: https://issues.apache.org/jira/browse/TS-974 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 3.0.1 >Reporter: William Bardwell >Assignee: Alan M. Carroll > Labels: A > Fix For: sometime > > > For ATS to do an excelent job caching large files like video it would need to > be able to hold partial objects for a large file. This could be done in a > plugin or in the core. This would need to be integrated with the Range > handling code to serve requests out of the partial objects and to get more > parts of a file to satisfy a Range request. > An intermediate step (also do-able in the core or in a plugin) would be to > have some settings to let the Range handling code be able to trigger a full > file download either asynchronously when a Range response indicates that the > file isn't larger than some threshold, or synchronously when a Range request > could reasonably be answered quickly from a full request. (Right now Range > requests are tunneled if there is not full cached content as far as I can > tell.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-974) TS should have a mode to hold partial objects in cache
[ https://issues.apache.org/jira/browse/TS-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-974: -- Fix Version/s: (was: sometime) 5.3.0 > TS should have a mode to hold partial objects in cache > -- > > Key: TS-974 > URL: https://issues.apache.org/jira/browse/TS-974 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 3.0.1 >Reporter: William Bardwell >Assignee: Alan M. Carroll > Labels: A > Fix For: 5.3.0 > > > For ATS to do an excelent job caching large files like video it would need to > be able to hold partial objects for a large file. This could be done in a > plugin or in the core. This would need to be integrated with the Range > handling code to serve requests out of the partial objects and to get more > parts of a file to satisfy a Range request. > An intermediate step (also do-able in the core or in a plugin) would be to > have some settings to let the Range handling code be able to trigger a full > file download either asynchronously when a Range response indicates that the > file isn't larger than some threshold, or synchronously when a Range request > could reasonably be answered quickly from a full request. (Right now Range > requests are tunneled if there is not full cached content as far as I can > tell.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything
[ https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-966: -- Assignee: Alan M. Carroll > cache.config dest_domain= dest_hostname= dest_ip= do not match anything > --- > > Key: TS-966 > URL: https://issues.apache.org/jira/browse/TS-966 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.0, 3.0.1 >Reporter: Igor Galić >Assignee: Alan M. Carroll > Labels: A > Fix For: 5.3.0 > > > Caching policies are not applied when using these options to match targets. > It is also not very clear *what* dest_domain= vs dest_hostname= can match. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-974) TS should have a mode to hold partial objects in cache
[ https://issues.apache.org/jira/browse/TS-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196518#comment-14196518 ] Alan M. Carroll commented on TS-974: This is now under active development. > TS should have a mode to hold partial objects in cache > -- > > Key: TS-974 > URL: https://issues.apache.org/jira/browse/TS-974 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 3.0.1 >Reporter: William Bardwell >Assignee: Alan M. Carroll > Labels: A > Fix For: 5.3.0 > > > For ATS to do an excelent job caching large files like video it would need to > be able to hold partial objects for a large file. This could be done in a > plugin or in the core. This would need to be integrated with the Range > handling code to serve requests out of the partial objects and to get more > parts of a file to satisfy a Range request. > An intermediate step (also do-able in the core or in a plugin) would be to > have some settings to let the Range handling code be able to trigger a full > file download either asynchronously when a Range response indicates that the > file isn't larger than some threshold, or synchronously when a Range request > could reasonably be answered quickly from a full request. (Right now Range > requests are tunneled if there is not full cached content as far as I can > tell.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
