[jira] [Created] (TS-2794) Build failure related to header requirements of atscppapi
Ryo OKUBO created TS-2794:
-
Summary: Build failure related to header requirements of atscppapi
Key: TS-2794
URL: https://issues.apache.org/jira/browse/TS-2794
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Ryo OKUBO
Assignee: Brian Geffon
When I built my plugin outside of trafficserver source tree, I found build
failure related to header requirements of atscppapi as below logs.
{noformat}
# I set /usr/local/trafficserver/ as prefix.
In file included from
/usr/local/trafficserver/include/atscppapi/Transaction.h:30:
/usr/local/trafficserver/include/atscppapi/shared_ptr.h:28:10: fatal error:
'ink_autoconf.h' file not found
#include "ink_autoconf.h"
^
1 error generated.
{noformat}
The shared_ptr.h requires a variable defined on ink_autoconf.h but it doesn't
exist in destination directory. so I've already posted Pull-Request on GitHub
to fix it. please review, and show me better solution if you have.
https://github.com/apache/trafficserver/pull/80
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2810) add TSVConnFdCreate API
James Peach created TS-2810:
---
Summary: add TSVConnFdCreate API
Key: TS-2810
URL: https://issues.apache.org/jira/browse/TS-2810
Project: Traffic Server
Issue Type: Bug
Components: Core, TS API
Reporter: James Peach
Add a new API {{TSVConnFdCreate}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-2792: Summary: Large request header causes unexpected remap (was: Large request header occurs unexpected remap) > Large request header causes unexpected remap > > > Key: TS-2792 > URL: https://issues.apache.org/jira/browse/TS-2792 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.0.2, 5.0.0 >Reporter: Masakazu Kitajo > Attachments: quickfix.diff > > > I get unexpected remap result when I request with likely 4KB of header. It > seems to be caused by coalescing of heaps. > In url_rewrite_remap_request, requestPath points to the path string of the > URL. However, the address of the string may be changed in remap process in > this function (e.g. request_url->host_set()). Because large header uses lots > of space so reallocation of heap may be caused when we modify the header > values. So the memcpy in this function may use the old invalid address as a > source, and it results unexpected remap and also results broken log outputs. > It may not cause crashes, but works incorrectly. > How to reproduce: > It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of > header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2807) SPDY + TLS matches http remap rules
[ https://issues.apache.org/jira/browse/TS-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998155#comment-13998155 ] Brian Geffon commented on TS-2807: -- I validated that this works as expected. This issue can be closed. > SPDY + TLS matches http remap rules > --- > > Key: TS-2807 > URL: https://issues.apache.org/jira/browse/TS-2807 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Bryan Call >Assignee: Brian Geffon > Labels: spdy, yahoo > Fix For: 5.0.0 > > > When a client connects with SPDY + TLS it shouldn't match the http:// from > remap rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997108#comment-13997108 ] Ethan Lai commented on TS-2344: --- [~zwoop] I've close previous pull request and create a new one with this patch, which remove handleIfRedirect() in done section. Please kindly review it. > 404 error was logged while url redirect request was processed corrctly > -- > > Key: TS-2344 > URL: https://issues.apache.org/jira/browse/TS-2344 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eddie >Assignee: Leif Hedstrom > Labels: Review > Fix For: 5.0.0 > > Attachments: no_redirect_after_map.patch > > > I am seeing a lot of entries in the error log for my url redirect request. > The request was processed correctly and I could see the expected response in > log as below: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed in the error log too, which > generates a lot of error logs (log rotation configured) and filling up disk > space pretty fast. > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in > the error log for my url redirect request. The request was processed correctly > I could see the expected response in log as well: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 and following > is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.extended2_log_header STRING NULL > CONFIG proxy.config.log.separate_icp_logs INT 0 > CONFIG proxy.config.log.separate_host_logs INT 0 > Is this a bug or is this a misconfiguration? Does anyone have any idea?) and > following is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.lo
[jira] [Updated] (TS-2342) problem with cache.cache_responses_to_cookies value 0
[
https://issues.apache.org/jira/browse/TS-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2342:
--
Labels: A (was: )
> problem with cache.cache_responses_to_cookies value 0
> -
>
> Key: TS-2342
> URL: https://issues.apache.org/jira/browse/TS-2342
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Configuration
>Reporter: Paul Marquess
>Assignee: Leif Hedstrom
> Labels: A
> Fix For: 5.0.0
>
>
> I’m attempting to configure TS (3.2.0 but the issue seems to be present in
> 4.0.2 as well) to disable caching for all content where a cookie is present.
> Setting cache.cache_responses_to_cookies to 0 looks like it should do that
> according to the comment in records.config
># cache responses to cookies has 5 options:
># 0 - do not cache any responses to cookies
># 1 - cache for any content-type
># 2 - cache only for image types
># 3 - cache for all but text content-types
># 4 - cache for all but text content-types except OS response
># without "Set-Cookie" or with "Cache-Control: public"
># See also cache-responses-to-cookies in cache.config.
> CONFIG proxy.config.http.cache.cache_responses_to_cookies INT 1
> Unfortunately when I set cache.cache_responses_to_cookies to 0 in
> records.config I don’t see anything written to the cache at all.
> Am I correct in assuming that cache.cache_responses_to_cookies is intended to
> influence the caching of content only when a cookie is in play? So the
> behaviour I’m seeing is wrong?
> Looking in do_cookiesprevent_caching in HttpTransact.cc it looks like the
> test for the 0 use case (COOKIES_CACHE_NONE) is done too early. Below is the
> code
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> I don’t see any other tests in the code that check for cookies that would be
> triggered before do_cookiesprevent_caching is invoked, so surely the
> COOKIES_CACHE_NONE test needs to be done after the presence of cookies
> headers has been determined?
> So the code would become
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> // Know we have a cookie present at this point
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> // and cookie detected
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2791) SPDY POST transactions failing with ERR_CLIENT_ABORT
[ https://issues.apache.org/jira/browse/TS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13994130#comment-13994130 ] Sudheer Vinukonda commented on TS-2791: --- So, the above fix seem to help - POST requests are now successful with this fix. I am yet to verify that the fix will still work if I check for the method to PURGE alone. But, in the mean time, can Yunkai Zhang comment on whether this fix might cause any other side affects? > SPDY POST transactions failing with ERR_CLIENT_ABORT > > > Key: TS-2791 > URL: https://issues.apache.org/jira/browse/TS-2791 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Sudheer Vinukonda > Labels: spdy, yahoo > > During our production testing of SPDY, we noticed that when trying to compose > mails (POST transactions) on Firefox, we are seeing "Network Error" from the > browser and ERR_CLIENT_ABORT from squid.logs. Upon some analysis, this issue > appears to be likely specific to SPDY transactions and seem to be triggered > by the expiry of proxy.config.http.transaction_no_activity_timeout_in timer. > After some investigation, it looks like this may be caused by a timing issue > related to streaming of the POST data to the origin.. If the POST body (data) > is available by the time client session and origin connection is ready, the > POST is successful, but, if the data is large enough that it is not all read > yet by the time origin connection is established, the streaming does not get > triggered. Debugging further to identify the root cause. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2810) add TSVConnFdCreate API
[
https://issues.apache.org/jira/browse/TS-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2810:
Fix Version/s: 5.0.0
Assignee: James Peach
> add TSVConnFdCreate API
> ---
>
> Key: TS-2810
> URL: https://issues.apache.org/jira/browse/TS-2810
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> Add a new API {{TSVConnFdCreate}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2619) TSRecordDump has a bad declaration
[
https://issues.apache.org/jira/browse/TS-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber resolved TS-2619.
-
Resolution: Fixed
> TSRecordDump has a bad declaration
> --
>
> Key: TS-2619
> URL: https://issues.apache.org/jira/browse/TS-2619
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Reporter: James Peach
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 5.0.0
>
>
> {{TSRecordDump}} is declared as taking a {{TSRecordType}} constant. However,
> this API also is defined to be able to operate on a {{TSRecordType}} bit
> mask. When you do this, you get the following compiler error:
> {code}
> /opt/ats/include/ts/ts.h|3083 col 14| note: candidate function not viable: no
> known conversion from 'int' to 'TSRecordType' for 1st argument
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998340#comment-13998340 ] Leif Hedstrom commented on TS-2801: --- It seems turning off the HTTP cache in ATS "fixes" the problem. I.e. it's only when serving content out of cache that it gets it wrong. This would also explain why it happens with both HTTPS and SPDY. If the SPDY request "caches" a corrupt page, presumably both HTTPS and SPDY would serve that broken page equally broken. > Enabling SPDY can cause page corruptions > > > Key: TS-2801 > URL: https://issues.apache.org/jira/browse/TS-2801 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Leif Hedstrom > Fix For: sometime > > Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png > > > When I build ATS with SPDY support, I see (sometimes) severe page corruptions > on my site. What's even odd, these corruptions happens even more frequently > from browsers which do not support SPDY. > Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is > no long corrupted. See the attached screenschot from a corruption from > https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2342) problem with cache.cache_responses_to_cookies value 0
[
https://issues.apache.org/jira/browse/TS-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997990#comment-13997990
]
Leif Hedstrom commented on TS-2342:
---
Paul, I totally dropped the ball on this... Sorry about that. Can you maybe
attach a proposed patch for these fixes? Against current master branch :).
Thanks!
> problem with cache.cache_responses_to_cookies value 0
> -
>
> Key: TS-2342
> URL: https://issues.apache.org/jira/browse/TS-2342
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Configuration
>Reporter: Paul Marquess
>Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
>
> I’m attempting to configure TS (3.2.0 but the issue seems to be present in
> 4.0.2 as well) to disable caching for all content where a cookie is present.
> Setting cache.cache_responses_to_cookies to 0 looks like it should do that
> according to the comment in records.config
># cache responses to cookies has 5 options:
># 0 - do not cache any responses to cookies
># 1 - cache for any content-type
># 2 - cache only for image types
># 3 - cache for all but text content-types
># 4 - cache for all but text content-types except OS response
># without "Set-Cookie" or with "Cache-Control: public"
># See also cache-responses-to-cookies in cache.config.
> CONFIG proxy.config.http.cache.cache_responses_to_cookies INT 1
> Unfortunately when I set cache.cache_responses_to_cookies to 0 in
> records.config I don’t see anything written to the cache at all.
> Am I correct in assuming that cache.cache_responses_to_cookies is intended to
> influence the caching of content only when a cookie is in play? So the
> behaviour I’m seeing is wrong?
> Looking in do_cookiesprevent_caching in HttpTransact.cc it looks like the
> test for the 0 use case (COOKIES_CACHE_NONE) is done too early. Below is the
> code
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> I don’t see any other tests in the code that check for cookies that would be
> triggered before do_cookiesprevent_caching is invoked, so surely the
> COOKIES_CACHE_NONE test needs to be done after the presence of cookies
> headers has been determined?
> So the code would become
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> // Know we have a cookie present at this point
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> // and cookie detected
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2803) Use documentation strings extracted from source files in project documentation
[ https://issues.apache.org/jira/browse/TS-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2803: Component/s: Documentation Fix Version/s: 5.0.0 Assignee: James Peach This looks great. Will merge by the end of the week. > Use documentation strings extracted from source files in project documentation > -- > > Key: TS-2803 > URL: https://issues.apache.org/jira/browse/TS-2803 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Reporter: Jack Bates >Assignee: James Peach > Fix For: 5.0.0 > > > Add a Sphinx extension that can grab documentation strings that have been > extracted from source files by Doxygen, translate them into reStructuredText, > and then use them inside Sphinx documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998303#comment-13998303 ] Ethan Lai commented on TS-2344: --- Sorry, do not notice that constant changed in 5.x. I've committed the new change, please take a look again. > 404 error was logged while url redirect request was processed corrctly > -- > > Key: TS-2344 > URL: https://issues.apache.org/jira/browse/TS-2344 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eddie >Assignee: Leif Hedstrom > Labels: Review > Fix For: 5.0.0 > > Attachments: no_redirect_after_map.patch > > > I am seeing a lot of entries in the error log for my url redirect request. > The request was processed correctly and I could see the expected response in > log as below: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed in the error log too, which > generates a lot of error logs (log rotation configured) and filling up disk > space pretty fast. > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in > the error log for my url redirect request. The request was processed correctly > I could see the expected response in log as well: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 and following > is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.extended2_log_header STRING NULL > CONFIG proxy.config.log.separate_icp_logs INT 0 > CONFIG proxy.config.log.separate_host_logs INT 0 > Is this a bug or is this a misconfiguration? Does anyone have any idea?) and > following is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG pro
[jira] [Commented] (TS-2801) Enabling SPDY can cause page corruptions
[ https://issues.apache.org/jira/browse/TS-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998342#comment-13998342 ] Leif Hedstrom commented on TS-2801: --- Update: Even with the http.cache turned off, I once in a while get what looks like an empty page. This happens with both HTTPS and SPDY requests (but only when SPDY is built). > Enabling SPDY can cause page corruptions > > > Key: TS-2801 > URL: https://issues.apache.org/jira/browse/TS-2801 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Leif Hedstrom > Fix For: sometime > > Attachments: Screenshot 2014-05-12 at 05.06.15 PM.png > > > When I build ATS with SPDY support, I see (sometimes) severe page corruptions > on my site. What's even odd, these corruptions happens even more frequently > from browsers which do not support SPDY. > Disabling SPDY from the build fixes the issues, and regular HTTPS traffic is > no long corrupted. See the attached screenschot from a corruption from > https://www.ogre.com using a non-SPDY browser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2789) Typo in HttpSessionManger would cause ATS reuse wrong session to origin server.
[
https://issues.apache.org/jira/browse/TS-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kang li updated TS-2789:
Description:
There is a typo in HttpSessionManger
(ats_ip_addr_eq(&s->server_ip.sa, addr) && ats_ip_port_cast(addr) ==
ats_ip_port_cast(addr)))
The fix would be
{code}
- (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
+ (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
ats_ip_port_cast(&s->server_ip.sa) == ats_ip_port_cast(addr)))
{code}
This typo skip the port check, so if requests to same origin server would use
one same session even though different port.
Which would cause ATS-5.0 reuse wrong session to origin.
was:
There is a typo in HttpSessionManger
(ats_ip_addr_eq(&s->server_ip.sa, addr) && ats_ip_port_cast(addr) ==
ats_ip_port_cast(addr)))
The fix would be
- (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
+ (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
ats_ip_port_cast(&s->server_ip.sa) == ats_ip_port_cast(addr)))
This typo skip the port check, so if requests to same origin server would use
one same session even though different port.
Which would cause ATS-5.0 reuse wrong session to origin.
> Typo in HttpSessionManger would cause ATS reuse wrong session to origin
> server.
> ---
>
> Key: TS-2789
> URL: https://issues.apache.org/jira/browse/TS-2789
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: kang li
>
> There is a typo in HttpSessionManger
> (ats_ip_addr_eq(&s->server_ip.sa, addr) && ats_ip_port_cast(addr) ==
> ats_ip_port_cast(addr)))
> The fix would be
> {code}
> - (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
> ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
> + (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
> ats_ip_port_cast(&s->server_ip.sa) == ats_ip_port_cast(addr)))
> {code}
> This typo skip the port check, so if requests to same origin server would use
> one same session even though different port.
>
> Which would cause ATS-5.0 reuse wrong session to origin.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2805) Client connections are connecting with SPDY 3 instead of 3.1
[ https://issues.apache.org/jira/browse/TS-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997001#comment-13997001 ] Bryan Call commented on TS-2805: The order looks like it needs to be changed: Protocol selection It's expected that a client will have a list of protocols that it supports, in preference order, and will only select a protocol if the server supports it. In that case, the client SHOULD select the first protocol advertised by the server that it also supports. In the event that the client doesn't support any of server's protocols, or the server doesn't advertise any, it SHOULD select the first protocol that it supports. There may be cases where the client knows, via other means, that a server supports an unadvertised protocol. In these cases the client can simply select that protocol. https://tools.ietf.org/id/draft-agl-tls-nextprotoneg-03.html#rfc.section.4 > Client connections are connecting with SPDY 3 instead of 3.1 > > > Key: TS-2805 > URL: https://issues.apache.org/jira/browse/TS-2805 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Bryan Call >Assignee: Brian Geffon > Labels: spdy, yahoo > Fix For: 5.0.0 > > > When testing with Chrome spdycat it is preferring to connect with SPDY 3: > [bcall@cat ~]$ spdycat -v https://l10.ycs.sjb.yahoo.com > [ 0.025] NPN select next protocol: the remote server offers: > * spdy/3 > * spdy/3.1 > * http/1.0 > * http/1.1 > NPN selected the protocol: spdy/3 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2807) SPDY + TLS matches http remap rules
[ https://issues.apache.org/jira/browse/TS-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-2807. -- Resolution: Implemented > SPDY + TLS matches http remap rules > --- > > Key: TS-2807 > URL: https://issues.apache.org/jira/browse/TS-2807 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Reporter: Bryan Call >Assignee: Brian Geffon > Labels: spdy, yahoo > Fix For: 5.0.0 > > > When a client connects with SPDY + TLS it shouldn't match the http:// from > remap rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2789) Typo in HttpSessionManger would cause ATS reuse wrong session to origin server.
[
https://issues.apache.org/jira/browse/TS-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2789:
--
Assignee: Bryan Call
> Typo in HttpSessionManger would cause ATS reuse wrong session to origin
> server.
> ---
>
> Key: TS-2789
> URL: https://issues.apache.org/jira/browse/TS-2789
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: kang li
>Assignee: Bryan Call
> Labels: yahoo
> Fix For: 5.0.0
>
>
> There is a typo in HttpSessionManger
> (ats_ip_addr_eq(&s->server_ip.sa, addr) && ats_ip_port_cast(addr) ==
> ats_ip_port_cast(addr)))
> The fix would be
> {code}
> - (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
> ats_ip_port_cast(addr) == ats_ip_port_cast(addr)))
> + (ats_ip_addr_eq(&s->server_ip.sa, addr) &&
> ats_ip_port_cast(&s->server_ip.sa) == ats_ip_port_cast(addr)))
> {code}
> This typo skip the port check, so if requests to same origin server would use
> one same session even though different port.
>
> Which would cause ATS-5.0 reuse wrong session to origin.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2809) Make various header sizes configurable (instead of fixed)
Leif Hedstrom created TS-2809:
-
Summary: Make various header sizes configurable (instead of fixed)
Key: TS-2809
URL: https://issues.apache.org/jira/browse/TS-2809
Project: Traffic Server
Issue Type: New Feature
Components: Core, HTTP
Reporter: Leif Hedstrom
It'd be swell if [~amc] could make some of the currently static buffer sizes
runtime configurable. Ideally even overridable. For example
{code}
proxy/hdrs/HdrHeap.h:#define HDR_HEAP_DEFAULT_SIZE 2048
proxy/hdrs/HdrHeap.h:#define HDR_STR_HEAP_DEFAULT_SIZE 2048
proxy/http/HttpSM.h:#define HTTP_HEADER_BUFFER_SIZE 2048
{code}
There might be several others :). I imagine a site using ATS could have some
reasonable knowledge of their typical header sizes, and size these accordingly
for optimal performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2782) ats crash in master in HdrHeap::inherit_string_heaps
[
https://issues.apache.org/jira/browse/TS-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13993422#comment-13993422
]
Feifei Cai commented on TS-2782:
Hi [~briang],
Thank you for your commit, and it works!
I build a package using the latest master, and test upgrading from some earlier
version (before your first TS-2766's commit) to this new package, and there's
no crash issues now.
> ats crash in master in HdrHeap::inherit_string_heaps
>
>
> Key: TS-2782
> URL: https://issues.apache.org/jira/browse/TS-2782
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
> Labels: spdy, yahoo
>
> When testing master on production hosts, noticed the below crash occuring
> repeatedly every time ats version is changed. This crash stops happening
> after clearing the cache. This needs further investigation, but, I remember a
> discussion between briang and zwoop about duplicate string fields in HdrHeap.
> Not sure if this core is related to that. Would appreciate if briang or zwoop
> can comment. Thank you.
> {code}
> [example_prep.sh] Checking/Moving old cores...
> [TrafficServer] using root directory '/home/y'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x30d3c0f500)[0x2aae27e2d500]
> /home/y/bin/traffic_server(_ZN7HdrHeap20inherit_string_heapsEPKS_+0x271)[0x61caa1]
> /home/y/bin/traffic_server(_Z14http_hdr_cloneP11HTTPHdrImplP7HdrHeapS2_+0x93)[0x619f83]
> /home/y/bin/traffic_server(_ZN19HttpTransactHeaders18copy_header_fieldsEP7HTTPHdrS1_bl+0x1be)[0x5c201e]
> /home/y/bin/traffic_server(_ZN12HttpTransact14build_responseEPNS_5StateEP7HTTPHdrS3_11HTTPVersion10HTTPStatusPKc+0x3ed)[0x5a287d]
> /home/y/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0x354)[0x5b67f4]
> /home/y/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x448)[0x5b84c8]
> /home/y/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x66)[0x573816]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x58ba72]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x583070]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x58d06a]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x58ba72]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x583070]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x58d06a]
> /home/y/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0xfe)[0x58533e]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x587de8]
> /home/y/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1b2)[0x566e12]
> /home/y/bin/traffic_server(_ZN7CacheVC8callcontEi+0x53)[0x653453]
> /home/y/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x7cf)[0x6be9af]
> /home/y/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x1ed)[0x69d40d]
> /home/y/bin/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x35)[0x6539c5]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x714aef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x71561b]
> /home/y/bin/traffic_server[0x713e9a]
> /lib64/libpthread.so.0(+0x30d3c07851)[0x2aae27e25851]
> /lib64/libc.so.6(clone+0x6d)[0x30d38e890d]
> {code}
> gdb output below:
> {code}
> (gdb) bt
> #0 ink_atomic_increment (this=0x2afb60113010,
> inherit_from=0x2afaa824e688) at ../../lib/ts/ink_atomic.h:162
> #1 refcount_inc (this=0x2afb60113010, inherit_from=0x2afaa824e688) at
> ../../lib/ts/Ptr.h:279
> #2 operator= (this=0x2afb60113010, inherit_from=0x2afaa824e688) at
> ../../lib/ts/Ptr.h:408
> #3 attach_str_heap (this=0x2afb60113010, inherit_from=0x2afaa824e688) at
> HdrHeap.cc:1000
> #4 HdrHeap::inherit_string_heaps (this=0x2afb60113010,
> inherit_from=0x2afaa824e688) at HdrHeap.cc:1081
> #5 0x00619f83 in http_hdr_clone (s_hh=0x2afaa824e710,
> s_heap=0x2afaa824e688, d_heap=0x2afb60113010) at HTTP.cc:375
> #6 0x005c201e in copy (src_hdr=0x2afaa824e0b8,
> new_hdr=0x2afac4058c50, retain_proxy_auth_hdrs=false, date=0) at
> ../../proxy/hdrs/HTTP.h:867
> #7 HttpTransactHeaders::copy_header_fields (src_hdr=0x2afaa824e0b8,
> new_hdr=0x2afac4058c50, retain_proxy_auth_hdrs=false, date=0) at
> HttpTransactHeaders.cc:201
> #8 0x005a287d in HttpTransact::build_response (s=0x2afac4058570,
> base_response=0x2afaa824e0b8, outgoing_response=0x2afac4058c50,
> outgoing_version=,
> status_code=HTTP_STATUS_NONE, reason_phrase=0x7323ac "None") at
> HttpTransact.cc:7926
> #9 0x005b67f4 in HttpTransact::build_response_from_cache
> (s=0x2afac4058570, warning_
[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997683#comment-13997683 ] Leif Hedstrom commented on TS-2344: --- That branch does not build for me, PROXY_INTERNAL_CACHE_NOOP is not defined. > 404 error was logged while url redirect request was processed corrctly > -- > > Key: TS-2344 > URL: https://issues.apache.org/jira/browse/TS-2344 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eddie >Assignee: Leif Hedstrom > Labels: Review > Fix For: 5.0.0 > > Attachments: no_redirect_after_map.patch > > > I am seeing a lot of entries in the error log for my url redirect request. > The request was processed correctly and I could see the expected response in > log as below: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed in the error log too, which > generates a lot of error logs (log rotation configured) and filling up disk > space pretty fast. > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in > the error log for my url redirect request. The request was processed correctly > I could see the expected response in log as well: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 and following > is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.extended2_log_header STRING NULL > CONFIG proxy.config.log.separate_icp_logs INT 0 > CONFIG proxy.config.log.separate_host_logs INT 0 > Is this a bug or is this a misconfiguration? Does anyone have any idea?) and > following is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_
[jira] [Commented] (TS-2237) URL encoding wrong in squid.blog
[ https://issues.apache.org/jira/browse/TS-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998290#comment-13998290 ] James Peach commented on TS-2237: - Bleccch ... it double-encodes :( > URL encoding wrong in squid.blog > > > Key: TS-2237 > URL: https://issues.apache.org/jira/browse/TS-2237 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: David Carlin >Priority: Minor > Fix For: 5.0.0 > > > I was replaying URLs captured from squid.blog and I noticed I was getting > 404's for some of them when squid.blog showed a 200 for that request. Turns > out there is an issue with URL encoding. For example: > Requesting file 'duck%20sports%20authority.gif' via curl will put this in the > logs: > duck%2520sports%2520authority.gif > The % from %20 (space) in the request is being converted to %25 resulting in > %2520 > I tested both the % and % log fields - same thing happens. I > tested on ATS 3.2.0 and 3.3.5 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2797) Not all manpages getting built
[ https://issues.apache.org/jira/browse/TS-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2797. - Resolution: Fixed > Not all manpages getting built > -- > > Key: TS-2797 > URL: https://issues.apache.org/jira/browse/TS-2797 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Affects Versions: 5.0.0 >Reporter: Jack Bates >Assignee: James Peach > Fix For: 5.0.0 > > > Not all of the manpages are getting built because they are not part of the > man_pages list in doc/conf.py > This patch adds all of the files in the doc/reference/api directory to the > list of manual pages. It also adds the manual page descriptions to the HTML > output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2793) remove UnixNetVConnection::selected_next_protocol
James Peach created TS-2793:
---
Summary: remove UnixNetVConnection::selected_next_protocol
Key: TS-2793
URL: https://issues.apache.org/jira/browse/TS-2793
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: James Peach
SPDY uses {{UnixNetVConnection::selected_next_protocol}} to track the SPDY
version requested in the NPN handshake. This is unnecessary, since SPDY can
easily provide a different acceptor on every different NPN string. We should
remove this and simplify the remains.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2796) Leaking CacheVConnections
[
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995394#comment-13995394
]
Thomas Jackson commented on TS-2796:
We're running ATS 4.2.1 and we are seeing this leaking pretty fast (~1gb of an
hour). Memory
{code}
2138112 |2124192 |928 | memory/cacheVConnection
{code
> Leaking CacheVConnections
> -
>
> Key: TS-2796
> URL: https://issues.apache.org/jira/browse/TS-2796
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.0.2, 4.2.1, 5.0.0
>Reporter: Brian Geffon
> Labels: yahoo
> Fix For: 5.0.0
>
>
> It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking
> CacheVConnections resulting in IOBufAllocator leaking also, here is an
> example:
> allocated |in-use | type size | free list name
>67108864 | 0 |2097152 |
> memory/ioBufAllocator[14]
>67108864 | 19922944 |1048576 |
> memory/ioBufAllocator[13]
> 4798283776 | 14155776 | 524288 |
> memory/ioBufAllocator[12]
> 7281311744 | 98304000 | 262144 |
> memory/ioBufAllocator[11]
> 1115684864 | 148242432 | 131072 |
> memory/ioBufAllocator[10]
> 497544 | 379977728 | 65536 |
> memory/ioBufAllocator[9]
> 9902751744 | 5223546880 | 32768 |
> memory/ioBufAllocator[8]
> 14762901504 |14762311680 | 16384 |
> memory/ioBufAllocator[7]
> 6558056448 | 6557859840 | 8192 |
> memory/ioBufAllocator[6]
>41418752 | 30502912 | 4096 |
> memory/ioBufAllocator[5]
> 524288 | 0 | 2048 |
> memory/ioBufAllocator[4]
> 0 | 0 | 1024 |
> memory/ioBufAllocator[3]
> 0 | 0 |512 |
> memory/ioBufAllocator[2]
> 32768 | 0 |256 |
> memory/ioBufAllocator[1]
> 0 | 0 |128 |
> memory/ioBufAllocator[0]
> 2138112 |2124192 |928 |
> memory/cacheVConnection
> [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x.
> The code path in CacheVC that is allocating the IoBuffers is
> memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom
> the real issue here is the leaking CacheVC.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
