[jira] [Created] (TS-5100) Port not being set when using remap rules with forward proxying
Bryan Call created TS-5100:
--
Summary: Port not being set when using remap rules with forward
proxying
Key: TS-5100
URL: https://issues.apache.org/jira/browse/TS-5100
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
{noformat}
[Dec 16 11:22:29.020] Server {0x7fc72d36a700} DEBUG: (http_trans) [0] [is_request_valid] 0 is an invalid connect
port
[Dec 16 11:22:29.020] Server {0x7fc72d36a700} DEBUG: (http_trans) [0] [is_request_valid] 0 is an invalid connect
port
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5100) Port not being set when using remap rules with forward proxying
[
https://issues.apache.org/jira/browse/TS-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5100:
---
Description:
{noformat}
[Dec 16 11:22:29.020] Server {0x7fc72d36a700} DEBUG: (http_trans) [0] [is_request_valid] 0 is an invalid connect
port
map https://www.yahoo.com/ https://www.google.com/
map / https://127.0.0.1:445/
{noformat}
was:
{noformat}
[Dec 16 11:22:29.020] Server {0x7fc72d36a700} DEBUG: (http_trans) [0] [is_request_valid] 0 is an invalid connect
port
[Dec 16 11:22:29.020] Server {0x7fc72d36a700} DEBUG: (http_trans) [0] [is_request_valid] 0 is an invalid connect
port
{noformat}
> Port not being set when using remap rules with forward proxying
> ---
>
> Key: TS-5100
> URL: https://issues.apache.org/jira/browse/TS-5100
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>
> {noformat}
> [Dec 16 11:22:29.020] Server {0x7fc72d36a700} DEBUG: (is_request_valid)> (http_trans) [0] [is_request_valid] 0 is an invalid
> connect port
> map https://www.yahoo.com/ https://www.google.com/
> map / https://127.0.0.1:445/
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5100) Port not being set when using remap rules with forward proxying
[
https://issues.apache.org/jira/browse/TS-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5100:
---
Fix Version/s: 7.1.0
> Port not being set when using remap rules with forward proxying
> ---
>
> Key: TS-5100
> URL: https://issues.apache.org/jira/browse/TS-5100
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
> Fix For: 7.1.0
>
>
> {noformat}
> [Dec 16 11:22:29.020] Server {0x7fc72d36a700} DEBUG: (is_request_valid)> (http_trans) [0] [is_request_valid] 0 is an invalid
> connect port
> map https://www.yahoo.com/ https://www.google.com/
> map / https://127.0.0.1:445/
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5083) Add configuration option to disable libcurl as a dependency
[ https://issues.apache.org/jira/browse/TS-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5083: --- Labels: yahoo (was: ) > Add configuration option to disable libcurl as a dependency > --- > > Key: TS-5083 > URL: https://issues.apache.org/jira/browse/TS-5083 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Bryan Call >Assignee: Bryan Call > Labels: yahoo > Fix For: 7.1.0 > > > We would like to have the option to not require libcurl for traffic_top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5083) Add configuration option to disable libcurl as a dependency
[ https://issues.apache.org/jira/browse/TS-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-5083: -- Assignee: Bryan Call > Add configuration option to disable libcurl as a dependency > --- > > Key: TS-5083 > URL: https://issues.apache.org/jira/browse/TS-5083 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.1.0 > > > We would like to have the option to not require libcurl for traffic_top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5083) Add configuration option to disable libcurl as a dependency
[ https://issues.apache.org/jira/browse/TS-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5083: --- Component/s: Build > Add configuration option to disable libcurl as a dependency > --- > > Key: TS-5083 > URL: https://issues.apache.org/jira/browse/TS-5083 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.1.0 > > > We would like to have the option to not require libcurl for traffic_top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5083) Add configuration option to disable libcurl as a dependency
Bryan Call created TS-5083: -- Summary: Add configuration option to disable libcurl as a dependency Key: TS-5083 URL: https://issues.apache.org/jira/browse/TS-5083 Project: Traffic Server Issue Type: Improvement Reporter: Bryan Call We would like to have the option to not require libcurl for traffic_top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5083) Add configuration option to disable libcurl as a dependency
[ https://issues.apache.org/jira/browse/TS-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5083: --- Fix Version/s: 7.1.0 > Add configuration option to disable libcurl as a dependency > --- > > Key: TS-5083 > URL: https://issues.apache.org/jira/browse/TS-5083 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Bryan Call > Fix For: 7.1.0 > > > We would like to have the option to not require libcurl for traffic_top. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4956) Memory leaks in hostdb test
[
https://issues.apache.org/jira/browse/TS-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-4956.
Resolution: Fixed
Yes, this has been completed.
> Memory leaks in hostdb test
> ---
>
> Key: TS-4956
> URL: https://issues.apache.org/jira/browse/TS-4956
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Memory leaks in hostdb test and there was an issue with the RefCountCache
> destructor.
> {noformat}
> ==18648==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 96 byte(s) in 1 object(s) allocated from:
> #0 0x7f5e41866ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x415c36 in testRefcounting()
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:130
> #2 0x40f066 in main
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:206
> #3 0x7f5e3eadf730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 31 byte(s) in 1 object(s) allocated from:
> #0 0x7f5e41865e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x4179ab in ExampleStruct::alloc(int)
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:48
> #2 0x4179ab in fillCache(RefCountCache*, int, int)
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:81
> #3 0x40f3bd in main
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:229
> #4 0x7f5e3eadf730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f5e41865e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x415c6b in ExampleStruct::alloc(int)
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:48
> #2 0x415c6b in testRefcounting()
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:133
> #3 0x40f066 in main
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:206
> #4 0x7f5e3eadf730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f5e41865e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x415eee in ExampleStruct::alloc(int)
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:48
> #2 0x415eee in testRefcounting()
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:142
> #3 0x40f066 in main
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:206
> #4 0x7f5e3eadf730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Indirect leak of 1120 byte(s) in 4 object(s) allocated from:
> #0 0x7f5e41865e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f5e4156cf85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x411f36 in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x411f36 in Vec DefaultAlloc, 0>::set_expand() ../../lib/ts/Vec.h:781
> #4 0x411f36 in TSHashTable::TSHashTable(unsigned
> long) ../../lib/ts/Map.h:1516
> #5 0x411f36 in
> RefCountCachePartition::RefCountCachePartition(unsigned int,
> unsigned long, unsigned int, RecRawStatBlock*) P_RefCountCache.h:166
> #6 0x411f36 in RefCountCache::RefCountCache(unsigned int,
> int, int, VersionNumber, std::__cxx11::basic_string std::char_traits, std::allocator >) P_RefCountCache.h:441
> #7 0x415c46 in testRefcounting()
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:130
> #8 0x40f066 in main
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:206
> #9 0x7f5e3eadf730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Indirect leak of 832 byte(s) in 4 object(s) allocated from:
> #0 0x7f5e41866ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x411b79 in RefCountCache::RefCountCache(unsigned int,
> int, int, VersionNumber, std::__cxx11::basic_string std::char_traits, std::allocator >) P_RefCountCache.h:441
> #2 0x415c46 in testRefcounting()
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:130
> #3 0x40f066 in main
> /home/bcall/dev/apache/trafficserver/iocore/hostdb/test_RefCountCache.cc:206
> #4 0x7f5e3eadf730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Indirect leak of 64 byte(s) in 1 object(s) allocated from:
> #0 0x7f5e41865e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f5e4156cf85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x41253b in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x41253b in
[jira] [Updated] (TS-5051) Adds a new log tag, proxy server build_number
[ https://issues.apache.org/jira/browse/TS-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5051: --- Component/s: Build > Adds a new log tag, proxy server build_number > - > > Key: TS-5051 > URL: https://issues.apache.org/jira/browse/TS-5051 > Project: Traffic Server > Issue Type: Wish > Components: Build >Reporter: Masa Sekimura > > For A/B testing and such, it would be nice if we can log build_number (eg > "6.2.1-12.31"). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5053:
---
Fix Version/s: 7.1.0
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> See title. Typically **argv is null terminated in other systems. And who are
> we to question 1000 years of tradition?
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5054) url_sig plugin loads configuration inconsistently
[
https://issues.apache.org/jira/browse/TS-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5054:
---
Fix Version/s: 7.1.0
> url_sig plugin loads configuration inconsistently
> -
>
> Key: TS-5054
> URL: https://issues.apache.org/jira/browse/TS-5054
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
> Fix For: 7.1.0
>
>
> {noformat}
> const char *install_dir = TSInstallDirGet();
> snprintf(config_file, sizeof(config_file), "%s/%s/%s", install_dir,
> "etc/trafficserver", argv[2]);
> TSDebug(PLUGIN_NAME, "config file name: %s", config_file);
> FILE *file = fopen(config_file, "r");
> if (file == NULL) {
> snprintf(errbuf, errbuf_size - 1, "[TSRemapNewInstance] - Error opening
> file %s.", config_file);
> return TS_ERROR;
> }
> {noformat}
> The policy for plugins is to load absolute paths if specified, then treat is
> as a path relative to {{TSConfigDirGet}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5055) cache.config dest_domain/dest_host support regex
[ https://issues.apache.org/jira/browse/TS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5055: --- Affects Version/s: 5.3.2 > cache.config dest_domain/dest_host support regex > > > Key: TS-5055 > URL: https://issues.apache.org/jira/browse/TS-5055 > Project: Traffic Server > Issue Type: New Feature > Components: Cache, Configuration >Affects Versions: 5.3.2 >Reporter: zhxiaom5 > Fix For: sometime > > > My ats version is 5.3.2 > the dest_domain/dest_host in cache.config seems not support regex domain/host > when I fill like below > dest_domain=.* suffix=php action=never-cache > something really wired happend. > thinks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5055) cache.config dest_domain/dest_host support regex
[ https://issues.apache.org/jira/browse/TS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5055: --- Component/s: Cache > cache.config dest_domain/dest_host support regex > > > Key: TS-5055 > URL: https://issues.apache.org/jira/browse/TS-5055 > Project: Traffic Server > Issue Type: New Feature > Components: Cache, Configuration >Affects Versions: 5.3.2 >Reporter: zhxiaom5 > Fix For: sometime > > > My ats version is 5.3.2 > the dest_domain/dest_host in cache.config seems not support regex domain/host > when I fill like below > dest_domain=.* suffix=php action=never-cache > something really wired happend. > thinks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5055) cache.config dest_domain/dest_host support regex
[ https://issues.apache.org/jira/browse/TS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5055: --- Fix Version/s: sometime > cache.config dest_domain/dest_host support regex > > > Key: TS-5055 > URL: https://issues.apache.org/jira/browse/TS-5055 > Project: Traffic Server > Issue Type: New Feature > Components: Cache, Configuration >Affects Versions: 5.3.2 >Reporter: zhxiaom5 > Fix For: sometime > > > My ats version is 5.3.2 > the dest_domain/dest_host in cache.config seems not support regex domain/host > when I fill like below > dest_domain=.* suffix=php action=never-cache > something really wired happend. > thinks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5055) cache.config dest_domain/dest_host support regex
[ https://issues.apache.org/jira/browse/TS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5055: --- Component/s: Configuration > cache.config dest_domain/dest_host support regex > > > Key: TS-5055 > URL: https://issues.apache.org/jira/browse/TS-5055 > Project: Traffic Server > Issue Type: New Feature > Components: Cache, Configuration >Affects Versions: 5.3.2 >Reporter: zhxiaom5 > Fix For: sometime > > > My ats version is 5.3.2 > the dest_domain/dest_host in cache.config seems not support regex domain/host > when I fill like below > dest_domain=.* suffix=php action=never-cache > something really wired happend. > thinks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-5055) cache.config dest_domain/dest_host support regex
[ https://issues.apache.org/jira/browse/TS-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15669445#comment-15669445 ] Bryan Call commented on TS-5055: Have you tried host_regex? If you want to match all, it would be better to do host_regex=. > cache.config dest_domain/dest_host support regex > > > Key: TS-5055 > URL: https://issues.apache.org/jira/browse/TS-5055 > Project: Traffic Server > Issue Type: New Feature >Reporter: zhxiaom5 > > My ats version is 5.3.2 > the dest_domain/dest_host in cache.config seems not support regex domain/host > when I fill like below > dest_domain=.* suffix=php action=never-cache > something really wired happend. > thinks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4026) Remove clustering feature in 7.0.0 release
[ https://issues.apache.org/jira/browse/TS-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15669162#comment-15669162 ] Bryan Call commented on TS-4026: [~bknight] I talked about this with a couple other committers over breakfast this morning. The proposal to remove clustering for ATS 7.0.0 was made 3 months ago on August 20th and this ticket has been open for over a year to remove clustering. There have been open bugs for clustering for awhile and no one has been working on them. Are you willing to support the feature until we have a complete replacement that would meet your needs? The majority of the clustering code was left in and only the configuration parts to enable it were removed. I was able to cleanly revert 2474b33f6655e9d4fb6e4887797f77a0a957714b and it compiles. I don't have a setup to test clustering myself. > Remove clustering feature in 7.0.0 release > --- > > Key: TS-4026 > URL: https://issues.apache.org/jira/browse/TS-4026 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bryan Call >Assignee: Phil Sorber > Labels: incompatible > Fix For: 7.0.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > From the ATS Fall Summit 2015 no one said they where using the clustering > feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4026) Remove clustering feature in 7.0.0 release
[ https://issues.apache.org/jira/browse/TS-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15668503#comment-15668503 ] Bryan Call commented on TS-4026: [~bknight] We have opted to remove clustering in favor of using parent caching or the carp plugin. Committers on the project are running very large caches where there is only one object stored across servers using these two techniques. We felt it was easier to maintain using HTTP and consistent hashing to achieve what cache clustering was doing using a similar code path as the normal use case, standard proxying. We asked for input on features we were thinking of removing before the ATS 7.0.0 release and reversed the decision on two of these because people in the ATS Community voiced their opinion against removing these features. No one spoke up for keeping cache clustering and we believed no one was using it. We would have been very welcome to hear your input at that time. If you need help on moving to parent caching or using the carp plugin please email the users mailing list and we will help you. > Remove clustering feature in 7.0.0 release > --- > > Key: TS-4026 > URL: https://issues.apache.org/jira/browse/TS-4026 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bryan Call >Assignee: Phil Sorber > Labels: incompatible > Fix For: 7.0.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > From the ATS Fall Summit 2015 no one said they where using the clustering > feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4594) Convert plugins to use records.config
[
https://issues.apache.org/jira/browse/TS-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4594:
---
Summary: Convert plugins to use records.config (was: convert plugins to
use records.config)
> Convert plugins to use records.config
> -
>
> Key: TS-4594
> URL: https://issues.apache.org/jira/browse/TS-4594
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Plugins
>Reporter: James Peach
> Labels: newbie
> Fix For: sometime
>
>
> Since there is API to use {{records.config}}, consider whether plugins should
> use configuration from there instead of from the plugins. This makes
> configuration more consistent though you would not get per-plugin instance
> variables. There are a few a cases where we might be able to remove a
> plugin-specific config file.
> Note that this doesn't solve per-remap configuration, which is pretty
> essential.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5032) Assertion on current 6.2.x branch
[
https://issues.apache.org/jira/browse/TS-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5032:
---
Fix Version/s: 6.2.1
> Assertion on current 6.2.x branch
> -
>
> Key: TS-5032
> URL: https://issues.apache.org/jira/browse/TS-5032
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
> Fix For: 6.2.1
>
>
> {code}
> #0 0x2d6bc37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81d37 in crash_logger_invoke (signo=6, info=0x2aaab440a330,
> ctx=0x2aaab440a200) at Crash.cc:164
> #2
> #3 0x2e807625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #4 0x2e808e05 in *__GI_abort () at abort.c:92
> #5 0x2b996060 in ink_abort
> (message_format=message_format@entry=0x2b9a302f "%s:%d: failed assertion
> `%s`") at ink_error.cc:79
> #6 0x2b994165 in _ink_assert (expression=,
> file=, line=) at ink_assert.cc:37
> #7 0x2abcb8d0 in ProxyClientSession::state_api_callout
> (this=0x2aaabe73, event=) at ProxyClientSession.cc:147
> #8 0x2acf0883 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:480
> #10 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #11 0x2acf10a2 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #12 Http2ClientSession::state_start_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:448
> #13 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #14 0x2ae6868b in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 read_signal_and_update (vc=0x2aab37097820, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:148
> #16 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab37097820,
> event=event@entry=100) at UnixNetVConnection.cc:1030
> #17 0x2ae47e43 in SSLNetVConnection::net_read_io
> (this=0x2aab37097820, nh=0x2aaab2d0acc0, lthread=0x2aaab2d07000) at
> SSLNetVConnection.cc:598
> #18 0x2ae55d7c in NetHandler::mainNetEvent (this=0x2aaab2d0acc0,
> event=, e=) at UnixNet.cc:513
> #19 0x2ae8db76 in Continuation::handleEvent (data=0x2aaab0bfa1c0,
> event=5, this=) at I_Continuation.h:153
> #20 EThread::process_event (calling_code=5, e=0x2aaab0bfa1c0,
> this=0x2aaab2d07000) at UnixEThread.cc:148
> #21 EThread::execute (this=0x2aaab2d07000) at UnixEThread.cc:275
> #22 0x2ae8c976 in spawn_thread_internal (a=0x2aaab0b23d90) at
> Thread.cc:86
> #23 0x2d6b4aa1 in start_thread (arg=0x2aaab440b700) at
> pthread_create.c:301
> #24 0x2e8bd93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5032) Assertion on current 6.2.x branch
[
https://issues.apache.org/jira/browse/TS-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5032:
---
Affects Version/s: 6.2.0
> Assertion on current 6.2.x branch
> -
>
> Key: TS-5032
> URL: https://issues.apache.org/jira/browse/TS-5032
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
> Fix For: 6.2.1
>
>
> {code}
> #0 0x2d6bc37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81d37 in crash_logger_invoke (signo=6, info=0x2aaab440a330,
> ctx=0x2aaab440a200) at Crash.cc:164
> #2
> #3 0x2e807625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #4 0x2e808e05 in *__GI_abort () at abort.c:92
> #5 0x2b996060 in ink_abort
> (message_format=message_format@entry=0x2b9a302f "%s:%d: failed assertion
> `%s`") at ink_error.cc:79
> #6 0x2b994165 in _ink_assert (expression=,
> file=, line=) at ink_assert.cc:37
> #7 0x2abcb8d0 in ProxyClientSession::state_api_callout
> (this=0x2aaabe73, event=) at ProxyClientSession.cc:147
> #8 0x2acf0883 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:480
> #10 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #11 0x2acf10a2 in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=0x2aaabe73) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #12 Http2ClientSession::state_start_frame_read (this=0x2aaabe73,
> event=, edata=0x2aab37097938) at Http2ClientSession.cc:448
> #13 0x2acef082 in Http2ClientSession::main_event_handler
> (this=0x2aaabe73, event=100, edata=0x2aab37097938) at
> Http2ClientSession.cc:294
> #14 0x2ae6868b in Continuation::handleEvent (data=0x2aab37097938,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #15 read_signal_and_update (vc=0x2aab37097820, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:148
> #16 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab37097820,
> event=event@entry=100) at UnixNetVConnection.cc:1030
> #17 0x2ae47e43 in SSLNetVConnection::net_read_io
> (this=0x2aab37097820, nh=0x2aaab2d0acc0, lthread=0x2aaab2d07000) at
> SSLNetVConnection.cc:598
> #18 0x2ae55d7c in NetHandler::mainNetEvent (this=0x2aaab2d0acc0,
> event=, e=) at UnixNet.cc:513
> #19 0x2ae8db76 in Continuation::handleEvent (data=0x2aaab0bfa1c0,
> event=5, this=) at I_Continuation.h:153
> #20 EThread::process_event (calling_code=5, e=0x2aaab0bfa1c0,
> this=0x2aaab2d07000) at UnixEThread.cc:148
> #21 EThread::execute (this=0x2aaab2d07000) at UnixEThread.cc:275
> #22 0x2ae8c976 in spawn_thread_internal (a=0x2aaab0b23d90) at
> Thread.cc:86
> #23 0x2d6b4aa1 in start_thread (arg=0x2aaab440b700) at
> pthread_create.c:301
> #24 0x2e8bd93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5038) Integration tests for background_fetch
[ https://issues.apache.org/jira/browse/TS-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5038: --- Fix Version/s: 7.1.0 > Integration tests for background_fetch > -- > > Key: TS-5038 > URL: https://issues.apache.org/jira/browse/TS-5038 > Project: Traffic Server > Issue Type: Bug > Components: Plugins, Tests >Reporter: James Peach > Fix For: 7.1.0 > > > Following on from TS-5035, integration tests would have caught this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5038) Integration tests for background_fetch
[ https://issues.apache.org/jira/browse/TS-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5038: --- Summary: Integration tests for background_fetch (was: Integration tests for background_fetch.) > Integration tests for background_fetch > -- > > Key: TS-5038 > URL: https://issues.apache.org/jira/browse/TS-5038 > Project: Traffic Server > Issue Type: Bug > Components: Plugins, Tests >Reporter: James Peach > Fix For: 7.1.0 > > > Following on from TS-5035, integration tests would have caught this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5049) Parent.config keynames are confusing
[ https://issues.apache.org/jira/browse/TS-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5049: --- Fix Version/s: 7.1.0 > Parent.config keynames are confusing > > > Key: TS-5049 > URL: https://issues.apache.org/jira/browse/TS-5049 > Project: Traffic Server > Issue Type: Improvement > Components: Parent Proxy >Reporter: Miles Libbey > Fix For: 7.1.0 > > > In parent.config, we have a series of key names that are either confusing, or > have been expanded well beyond what the name implies: > - round_robin. This now describes a selection strategy. > - parent. Origins can be described here too. Not sure what a good descriptor > would be. > - parent_is_proxy describes how the request will be made from the child node > -- eg, 'true,' means the request will be a proxy style request (GET > http://example.com/foo); 'false' means a traditional style request (GET > /foo\n Host: example.com) > In addition, there are several options that only apply when other settings > are used. For instance, secondary_parent only applies to the consistent_hash > strategy. Similarly, today, "qstring" only applies to consistent_hash, as the > URI is not considered for any other existing selection strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5028) ATS 6.2.0 don't start with read-only /etc
[
https://issues.apache.org/jira/browse/TS-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5028:
---
Affects Version/s: 6.2.0
> ATS 6.2.0 don't start with read-only /etc
> -
>
> Key: TS-5028
> URL: https://issues.apache.org/jira/browse/TS-5028
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Reindl Harald
>
> can we *please* get rid of that nonsense after that many years - /etc is
> admin-area and software which tries to touch it at start is broken by design
> in general, until 6.2.0 at least it did start which is no longer the case
> [root@buildserver:/var/log/trafficserver]$ cat
> /etc/trafficserver/records.config | grep disable_configuration_modification
> CONFIG proxy.config.disable_configuration_modification 1
> [root@buildserver:/var/log/trafficserver]$ cat *
> [Aug 5 17:35:32.031] {0x2b6c81f2bf40} STATUS: opened
> /var/log/trafficserver/diags.log
> [Aug 5 17:35:32.032] {0x2b6c81f2bf40} NOTE: (reconfigure_diags)> updated diags config
> [Aug 5 17:35:32.038] Server {0x2b6c81f2bf40} NOTE:
> cache clustering disabled
> [Aug 5 17:35:32.044] Server {0x2b6c81f2bf40} NOTE: (reconfigure)> ip_allow.config updated, reloading
> [Aug 5 17:35:32.051] Server {0x2b6c81f2bf40} NOTE: (init)> cache clustering disabled
> [Aug 5 17:35:32.054] Server {0x2b6c81f2bf40} NOTE: (init_when_enabled)> logging initialized[3], logging_mode = 1
> [Aug 5 17:35:32.058] Server {0x2b6c81f2bf40} NOTE: (SSLParseCertificateConfiguration)> loading SSL certificate configuration
> from /etc/trafficserver/ssl_multicert.config
> [Aug 5 17:35:32.092] Server {0x2b6c81f2bf40} NOTE:
> traffic server running
> [Aug 5 17:35:32.113] Server {0x2b6c87312700} NOTE: (cacheInitialized)> cache enabled
> [Aug 5 17:35:27.934] {0x7f2183e76900} STATUS: opened
> /var/log/trafficserver/manager.log
> [Aug 5 17:35:27.934] {0x7f2183e76900} NOTE: (reconfigure_diags)> updated diags config
> [Aug 5 17:35:27.935] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of log_hosts.config failed: Permission denied
> [Aug 5 17:35:27.935] Manager {0x7f2183e76900} NOTE:
> [Rollback::internalUpdate] Unable to create new version of log_hosts.config :
> Permission denied
> [Aug 5 17:35:27.936] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Automatic Roll of Version 1 failed: log_hosts.config
> [Aug 5 17:35:27.936] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of log_hosts.config failed: Permission denied
> [Aug 5 17:35:27.936] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Config file is read-only : log_hosts.config
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of logs_xml.config failed: Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE:
> [Rollback::internalUpdate] Unable to create new version of logs_xml.config :
> Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Automatic Roll of Version 1 failed: logs_xml.config
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of logs_xml.config failed: Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Config file is read-only : logs_xml.config
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of storage.config failed: Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE:
> [Rollback::internalUpdate] Unable to create new version of storage.config :
> Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Automatic Roll of Version 1 failed: storage.config
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of storage.config failed: Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Config file is read-only : storage.config
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of socks.config failed: Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE:
> [Rollback::internalUpdate] Unable to create new version of socks.config :
> Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Automatic Roll of Version 1 failed: socks.config
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of socks.config failed: Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback]
> Config file is read-only : socks.config
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile]
> Open of records.config failed: Permission denied
> [Aug 5 17:35:27.937] Manager {0x7f2183e76900} NOTE:
> [Rollback::internalUpdate] Unable to create new
[jira] [Updated] (TS-5027) Replace readdir_r with readdir
[
https://issues.apache.org/jira/browse/TS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5027:
---
Summary: Replace readdir_r with readdir (was: Replace readdir_r with
readdir.)
> Replace readdir_r with readdir
> --
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*,
> dirent**)' is deprecated [-Werror=deprecated-declarations]
> while (readdir_r(dir, dirEntrySpace, ) == 0) {
> ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5027) Replace readdir_r with readdir.
[
https://issues.apache.org/jira/browse/TS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5027:
---
Backport to Version: 7.0.1
> Replace readdir_r with readdir.
> ---
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*,
> dirent**)' is deprecated [-Werror=deprecated-declarations]
> while (readdir_r(dir, dirEntrySpace, ) == 0) {
> ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4500) Add cookie-rewrite functionality into header-rewrite plugin
[ https://issues.apache.org/jira/browse/TS-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4500: --- Summary: Add cookie-rewrite functionality into header-rewrite plugin (was: add cookie-rewrite functionality into header-rewrite plugin) > Add cookie-rewrite functionality into header-rewrite plugin > --- > > Key: TS-4500 > URL: https://issues.apache.org/jira/browse/TS-4500 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Zhang Zizhong >Assignee: Zhang Zizhong > Fix For: 7.0.0 > > > add cookie-rewrite functionality into header-rewrite plugin. > There're three cookie handling operators added, including *add-cookie*, > *rm-cookie* and *update-cookie*. > *add-cookie* adds a key-value pair into Cookie. If the given key is already > in Cookie, do nothing. > *rm-cookie* remove a pair with the given key from Cookie. > *update-cookie* sets the value with the given key to the given value. If the > given key doesn't exist, add a new pair into Cookie. So the only difference > between *add-cookie* and *update-cookie* is overwriting an existing pair or > not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5034) Add a --enable-tsan configure option
[ https://issues.apache.org/jira/browse/TS-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5034: --- Fix Version/s: 7.1.0 > Add a --enable-tsan configure option > > > Key: TS-5034 > URL: https://issues.apache.org/jira/browse/TS-5034 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Add a --enable-tsan configure option -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5034) Add a --enable-tsan configure option
[ https://issues.apache.org/jira/browse/TS-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-5034: -- Assignee: Bryan Call > Add a --enable-tsan configure option > > > Key: TS-5034 > URL: https://issues.apache.org/jira/browse/TS-5034 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Add a --enable-tsan configure option -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5034) Add a --enable-tsan configure option
[ https://issues.apache.org/jira/browse/TS-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-5034. Resolution: Fixed > Add a --enable-tsan configure option > > > Key: TS-5034 > URL: https://issues.apache.org/jira/browse/TS-5034 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Add a --enable-tsan configure option -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5034) Add a --enable-tsan configure option
Bryan Call created TS-5034: -- Summary: Add a --enable-tsan configure option Key: TS-5034 URL: https://issues.apache.org/jira/browse/TS-5034 Project: Traffic Server Issue Type: New Feature Components: Build Reporter: Bryan Call Add a --enable-tsan configure option -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3939) Add a --enable-asan configure option
[ https://issues.apache.org/jira/browse/TS-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-3939. Resolution: Fixed > Add a --enable-asan configure option > > > Key: TS-3939 > URL: https://issues.apache.org/jira/browse/TS-3939 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Leif Hedstrom >Assignee: Bryan Call > Labels: newbie > Fix For: 7.1.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > It might be useful to make these options, to make it simpler / easier to add > a build that uses ASan (or TSan). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4994) PANIC: unprotected error in call to Lua API (not enough memory)
[
https://issues.apache.org/jira/browse/TS-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15634448#comment-15634448
]
Bryan Call commented on TS-4994:
[~kichan] [~ftarnell]
Is this going to be an issue in the ATS 7.0.0 release? Do we need to get this
fix and backport it?
> PANIC: unprotected error in call to Lua API (not enough memory)
> ---
>
> Key: TS-4994
> URL: https://issues.apache.org/jira/browse/TS-4994
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>
> We have a working installation of TS 6.1; when upgrading to 6.2, it
> repeatedly crashes almost immediately after startup with:
> {noformat}
> PANIC: unprotected error in call to Lua API (not enough memory)
> pure virtual method called
> terminate called without an active exception
> traffic_server: using root directory '/opt/tbx'
> traffic_server: Aborted (Signal sent by tkill() 11964 33)
> traffic_server - STACK TRACE:
> /opt/tbx/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ac16e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b2c43b828d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2b2c44b52067]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b2c44b53448]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x15d)[0x2b2c4435bb3d]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ebb6)[0x2b2c44359bb6]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ec01)[0x2b2c44359c01]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f6cf)[0x2b2c4435a6cf]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept18do_blocking_acceptEP7EThread+0x99)[0x74dd69]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept15acceptLoopEventEiP5Event+0x2b)[0x74e62b]
> /opt/tbx/bin/traffic_server(_ZN7EThread7executeEv+0x7f)[0x77ce1f]
> /opt/tbx/bin/traffic_server[0x77c315]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b2c43b7b0a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b2c44c0587d]
> {noformat}
> We have about 5000 lines of Lua, and one C module (lualdap), but nothing that
> should be approaching Lua's memory limit; it's mostly just access checks that
> don't allocate any memory at all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4994) PANIC: unprotected error in call to Lua API (not enough memory)
[
https://issues.apache.org/jira/browse/TS-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15634448#comment-15634448
]
Bryan Call edited comment on TS-4994 at 11/3/16 10:06 PM:
--
[~kichan] [~ftarnell]
Is this going to be an issue in the ATS 7.0.0 release? Do we need to get this
fixed and backport it?
was (Author: bcall):
[~kichan] [~ftarnell]
Is this going to be an issue in the ATS 7.0.0 release? Do we need to get this
fix and backport it?
> PANIC: unprotected error in call to Lua API (not enough memory)
> ---
>
> Key: TS-4994
> URL: https://issues.apache.org/jira/browse/TS-4994
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>
> We have a working installation of TS 6.1; when upgrading to 6.2, it
> repeatedly crashes almost immediately after startup with:
> {noformat}
> PANIC: unprotected error in call to Lua API (not enough memory)
> pure virtual method called
> terminate called without an active exception
> traffic_server: using root directory '/opt/tbx'
> traffic_server: Aborted (Signal sent by tkill() 11964 33)
> traffic_server - STACK TRACE:
> /opt/tbx/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ac16e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b2c43b828d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2b2c44b52067]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b2c44b53448]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x15d)[0x2b2c4435bb3d]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ebb6)[0x2b2c44359bb6]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ec01)[0x2b2c44359c01]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f6cf)[0x2b2c4435a6cf]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept18do_blocking_acceptEP7EThread+0x99)[0x74dd69]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept15acceptLoopEventEiP5Event+0x2b)[0x74e62b]
> /opt/tbx/bin/traffic_server(_ZN7EThread7executeEv+0x7f)[0x77ce1f]
> /opt/tbx/bin/traffic_server[0x77c315]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b2c43b7b0a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b2c44c0587d]
> {noformat}
> We have about 5000 lines of Lua, and one C module (lualdap), but nothing that
> should be approaching Lua's memory limit; it's mostly just access checks that
> don't allocate any memory at all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4999) Enable control of plugin callback invocation and ordering by plugin prioritization
[ https://issues.apache.org/jira/browse/TS-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4999: --- Summary: Enable control of plugin callback invocation and ordering by plugin prioritization (was: Enable control of plugin callback invocation and ordering by plugin piroritization.) > Enable control of plugin callback invocation and ordering by plugin > prioritization > -- > > Key: TS-4999 > URL: https://issues.apache.org/jira/browse/TS-4999 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > > Enable plugins to have priority values which affects both the order of plugin > invocation on a hook and whether the plugin is invoked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4996) Duplicate 'intercept' example plugins.
[
https://issues.apache.org/jira/browse/TS-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4996:
---
Fix Version/s: 7.1.0
> Duplicate 'intercept' example plugins.
> --
>
> Key: TS-4996
> URL: https://issues.apache.org/jira/browse/TS-4996
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
> Fix For: 7.1.0
>
>
> We have 2 different example plugins called {{intercept}}. They clobber each
> other at install time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4989) Don't add Age: header to requests not served from cache
[ https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4989: --- Component/s: HTTP > Don't add Age: header to requests not served from cache > --- > > Key: TS-4989 > URL: https://issues.apache.org/jira/browse/TS-4989 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 7.0.0 >Reporter: David Carlin > Labels: yahoo > Fix For: 7.1.0 > > > You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a > request - for requests not served from cache. Causes confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4989) Don't add Age: header to requests not served from cache
[ https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4989: --- Fix Version/s: 7.1.0 > Don't add Age: header to requests not served from cache > --- > > Key: TS-4989 > URL: https://issues.apache.org/jira/browse/TS-4989 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 7.0.0 >Reporter: David Carlin > Labels: yahoo > Fix For: 7.1.0 > > > You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a > request - for requests not served from cache. Causes confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4989) Don't add Age: header to requests not served from cache
[ https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4989: --- Affects Version/s: 7.0.0 > Don't add Age: header to requests not served from cache > --- > > Key: TS-4989 > URL: https://issues.apache.org/jira/browse/TS-4989 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 7.0.0 >Reporter: David Carlin > Labels: yahoo > Fix For: 7.1.0 > > > You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a > request - for requests not served from cache. Causes confusion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5026) Update keep_alive_no_activity_timeout_in document and default value in template
[ https://issues.apache.org/jira/browse/TS-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5026: --- Summary: Update keep_alive_no_activity_timeout_in document and default value in template (was: update keep_alive_no_activity_timeout_in document and default value in template) > Update keep_alive_no_activity_timeout_in document and default value in > template > --- > > Key: TS-5026 > URL: https://issues.apache.org/jira/browse/TS-5026 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Documentation >Reporter: Masa Sekimura >Assignee: Bryan Call > Fix For: 7.1.0 > > > TS-4700 made essential changes to update the default value. There are some > documents and a template for records.config need to be updated. > https://github.com/sekimura/trafficserver/commit/e6248331ae2f4a220e7cdaeadcd9214c1d860d1e > I'll make a pull request -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5026) update keep_alive_no_activity_timeout_in document and default value in template
[ https://issues.apache.org/jira/browse/TS-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5026: --- Fix Version/s: 7.1.0 > update keep_alive_no_activity_timeout_in document and default value in > template > --- > > Key: TS-5026 > URL: https://issues.apache.org/jira/browse/TS-5026 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Documentation >Reporter: Masa Sekimura >Assignee: Bryan Call > Fix For: 7.1.0 > > > TS-4700 made essential changes to update the default value. There are some > documents and a template for records.config need to be updated. > https://github.com/sekimura/trafficserver/commit/e6248331ae2f4a220e7cdaeadcd9214c1d860d1e > I'll make a pull request -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3474) HTTP/2 Server Push support in ATS
[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-3474.
Resolution: Fixed
> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've done some preliminary analysis/prototype of SPDY server push support in
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross
> origin resource push (which is sort of critical in the way, our CDN works).
> Wanted to open this Jira to share this info with the community and ask for
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy
> layer:
> - Origin Driven
> - Client Driven
> - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as
> special headers in the response to a base page, for instance. We are
> exploring making use of the HTTP LINK header for this purpose. The proxy
> would basically initiate PUSH streams to the client for the resources
> identified by the LINK headers in the base page response and at the same
> time, fetch those resources by initiating internal SPDY requests. There are a
> few things to consider such as whether the pushable resources should be
> limited to only cacheable resources? Whether non-https resources can be
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and
> ATS building dynamically a set of associated resources for a given base page
> request url. Once such a list is built, the rest of the mechanism is similar
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the
> proxy extracting/unzipping/parsing the response body and identifying pushable
> resources and initiating the push resources similar to the other approaches
> above. This is performance intensive and will need some optimizations in not
> having to parse every response, but doing it based on some sort of
> count/frequency of the access.
> I did some prototyping and was able to push resources, but, realized there
> are some stumbling blocks. For example, Chrome doesn't permit cross origin
> HTTPS resources to be pushed (even if certs were presented for both the
> original and push domain). See below email from Chrome indicating that they
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being
> rejected. The central reason is that the session isn't authenticated for the
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's
> declared associated stream. This is true even of a SPDY session which
> presented certs & authenticated for both the associated & push origins: you
> still need to arrange for an associated stream on the origin for which you'd
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though
> there are continuing conversations about how it might be done. It'd need to
> be done very carefully.
> "
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3474) HTTP/2 Server Push support in ATS
[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3474:
---
Fix Version/s: (was: 7.1.0)
7.0.0
> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> I've done some preliminary analysis/prototype of SPDY server push support in
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross
> origin resource push (which is sort of critical in the way, our CDN works).
> Wanted to open this Jira to share this info with the community and ask for
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy
> layer:
> - Origin Driven
> - Client Driven
> - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as
> special headers in the response to a base page, for instance. We are
> exploring making use of the HTTP LINK header for this purpose. The proxy
> would basically initiate PUSH streams to the client for the resources
> identified by the LINK headers in the base page response and at the same
> time, fetch those resources by initiating internal SPDY requests. There are a
> few things to consider such as whether the pushable resources should be
> limited to only cacheable resources? Whether non-https resources can be
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and
> ATS building dynamically a set of associated resources for a given base page
> request url. Once such a list is built, the rest of the mechanism is similar
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the
> proxy extracting/unzipping/parsing the response body and identifying pushable
> resources and initiating the push resources similar to the other approaches
> above. This is performance intensive and will need some optimizations in not
> having to parse every response, but doing it based on some sort of
> count/frequency of the access.
> I did some prototyping and was able to push resources, but, realized there
> are some stumbling blocks. For example, Chrome doesn't permit cross origin
> HTTPS resources to be pushed (even if certs were presented for both the
> original and push domain). See below email from Chrome indicating that they
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being
> rejected. The central reason is that the session isn't authenticated for the
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's
> declared associated stream. This is true even of a SPDY session which
> presented certs & authenticated for both the associated & push origins: you
> still need to arrange for an associated stream on the origin for which you'd
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though
> there are continuing conversations about how it might be done. It'd need to
> be done very carefully.
> "
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4732) Still seeing VC errors on master
[
https://issues.apache.org/jira/browse/TS-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15629536#comment-15629536
]
Bryan Call commented on TS-4732:
This was only an issue on master until 85c021123fd94c4d97a6015484eb1d8054bec9eb
was backported to 6.2.x, so now this needs to be backported to fix the other
backport.
Full details on the 85c021123fd94c4d97a6015484eb1d8054bec9eb backport:
{noformat}
commit 14caf6f964556603398dfdd88075a6c0eb28f5c9
Author: shinrich
AuthorDate: Fri Jul 15 15:52:09 2016 -0500
Commit: Phil Sorber
CommitDate: Wed Oct 26 17:38:52 2016 -0700
TS-4507: Fix SSN and TXN hook ordering.
(cherry picked from commit 85c021123fd94c4d97a6015484eb1d8054bec9eb)
Conflicts:
proxy/ProxyClientSession.h
proxy/http/HttpSM.cc
proxy/http2/Http2ClientSession.cc
proxy/http2/Http2Stream.cc
{noformat}
> Still seeing VC errors on master
>
>
> Key: TS-4732
> URL: https://issues.apache.org/jira/browse/TS-4732
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR:
> do_io_read invoked on closed vc
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR:
> do_io_write invoked on closed vc
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR:
> do_io_read invoked on closed vc
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR:
> do_io_write invoked on closed vc
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR:
> do_io_read invoked on closed vc
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR:
> do_io_write invoked on closed vc
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR:
> do_io_read invoked on closed vc
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR:
> do_io_write invoked on closed vc
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR:
> do_io_read invoked on closed vc
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR:
> do_io_write invoked on closed vc
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR:
> do_io_read invoked on closed vc
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR:
> do_io_write invoked on closed vc
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR:
> do_io_read invoked on closed vc
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR:
> do_io_write invoked on closed vc
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR:
> do_io_read invoked on closed vc
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR:
> do_io_write invoked on closed vc
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR:
> do_io_read invoked on closed vc
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR:
> do_io_write invoked on closed vc
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR:
> do_io_read invoked on closed vc
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR:
> do_io_write invoked on closed vc
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4732) Still seeing VC errors on master
[
https://issues.apache.org/jira/browse/TS-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4732:
---
Backport to Version: 6.2.1
> Still seeing VC errors on master
>
>
> Key: TS-4732
> URL: https://issues.apache.org/jira/browse/TS-4732
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Seeing this in the error logs *a lot*:
> {code}
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR:
> do_io_read invoked on closed vc
> 0x634000c186a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.606] Server {0x2b1a9f010700} ERROR:
> do_io_write invoked on closed vc
> 0x634000c186a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR:
> do_io_read invoked on closed vc
> 0x634000c0f220, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.631] Server {0x2b1a9e3eb700} ERROR:
> do_io_write invoked on closed vc
> 0x634000c0f220, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR:
> do_io_read invoked on closed vc
> 0x634000c13240, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.727] Server {0x2b1aa0433700} ERROR:
> do_io_write invoked on closed vc
> 0x634000c13240, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR:
> do_io_read invoked on closed vc
> 0x6340002364e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.765] Server {0x2b1aa083a700} ERROR:
> do_io_write invoked on closed vc
> 0x6340002364e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR:
> do_io_read invoked on closed vc
> 0x63400088c2e0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.914] Server {0x2b1a9e7f2700} ERROR:
> do_io_write invoked on closed vc
> 0x63400088c2e0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR:
> do_io_read invoked on closed vc
> 0x6340004f7fe0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:26.938] Server {0x2b1a9e3eb700} ERROR:
> do_io_write invoked on closed vc
> 0x6340004f7fe0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR:
> do_io_read invoked on closed vc
> 0x63400025a860, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.004] Server {0x2b1aa3487700} ERROR:
> do_io_write invoked on closed vc
> 0x63400025a860, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR:
> do_io_read invoked on closed vc
> 0x634000ad2820, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.048] Server {0x2b1aa144f700} ERROR:
> do_io_write invoked on closed vc
> 0x634000ad2820, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR:
> do_io_read invoked on closed vc
> 0x6340003fa1a0, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.248] Server {0x2b1a9dbdd700} ERROR:
> do_io_write invoked on closed vc
> 0x6340003fa1a0, cont (nil), nbytes 0, reader (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR:
> do_io_read invoked on closed vc
> 0x634000807f60, cont (nil), nbytes 0, buf (nil)
> [Jun 13 17:14:27.388] Server {0x2b1aa3080700} ERROR:
> do_io_write invoked on closed vc
> 0x634000807f60, cont (nil), nbytes 0, reader (nil)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-5013. Resolution: Fixed > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Assignee: Theo Schlossnagle > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Component/s: Build > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5004) CID 1021675 Structurally dead code
[ https://issues.apache.org/jira/browse/TS-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-5004. Resolution: Fixed > CID 1021675 Structurally dead code > -- > > Key: TS-5004 > URL: https://issues.apache.org/jira/browse/TS-5004 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Nathan Garabedian >Assignee: Nathan Garabedian > Fix For: 7.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Some lines of code exist after a return 1; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5016) TS should allow force reload, and may also check inclued files
[ https://issues.apache.org/jira/browse/TS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5016: --- Component/s: Configuration > TS should allow force reload, and may also check inclued files > --- > > Key: TS-5016 > URL: https://issues.apache.org/jira/browse/TS-5016 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Fang > Fix For: 7.1.0 > > > 1) on config change, if TS hasn't detect the changes yet - traffic_ctl config > status show "current", > reload seems skipped. so user may need to wait for the detection. > this happens if config file are generated by programs since the reload > is immediately. > 2) for included config files, such as .include from remap.config, > if included files changes, TS still seems configuration as current -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5002) No core files created at crash
[ https://issues.apache.org/jira/browse/TS-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5002: --- Fix Version/s: 7.1.0 > No core files created at crash > -- > > Key: TS-5002 > URL: https://issues.apache.org/jira/browse/TS-5002 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Roee Gil > Fix For: 7.1.0 > > > When trying to enable core dump creation on ATS 5.3.2 the crash log is > written to traffic.out, but no matter what change is done in record.config, > or in the sysctl the core file it self is not created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5004) CID 1021675 Structurally dead code
[ https://issues.apache.org/jira/browse/TS-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5004: --- Fix Version/s: 7.1.0 > CID 1021675 Structurally dead code > -- > > Key: TS-5004 > URL: https://issues.apache.org/jira/browse/TS-5004 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Nathan Garabedian >Assignee: Nathan Garabedian > Fix For: 7.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Some lines of code exist after a return 1; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5017) ip_allow.config seems use the first matched rule
[ https://issues.apache.org/jira/browse/TS-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5017: --- Fix Version/s: sometime > ip_allow.config seems use the first matched rule > > > Key: TS-5017 > URL: https://issues.apache.org/jira/browse/TS-5017 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Fang > Fix For: sometime > > > as title, rules are not merged, and the first matched rule take effect. > shall we update the doc for this ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5017) ip_allow.config seems use the first matched rule
[ https://issues.apache.org/jira/browse/TS-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5017: --- Fix Version/s: (was: sometime) Docs > ip_allow.config seems use the first matched rule > > > Key: TS-5017 > URL: https://issues.apache.org/jira/browse/TS-5017 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Fang > Fix For: Docs > > > as title, rules are not merged, and the first matched rule take effect. > shall we update the doc for this ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Fix Version/s: 7.1.0 > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5014) If ip_allow.config is missing all access is blocked
[
https://issues.apache.org/jira/browse/TS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5014:
---
Component/s: Security
> If ip_allow.config is missing all access is blocked
> ---
>
> Key: TS-5014
> URL: https://issues.apache.org/jira/browse/TS-5014
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Security
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> An empty {{ip_allow.config}} should block all traffic (default deny) but if
> the file does not exist it should disable IP allow (default allow). Currently
> if the file does not exist it acts as an empty file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5014) If ip_allow.config is missing all access is blocked
[
https://issues.apache.org/jira/browse/TS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5014:
---
Fix Version/s: 7.1.0
> If ip_allow.config is missing all access is blocked
> ---
>
> Key: TS-5014
> URL: https://issues.apache.org/jira/browse/TS-5014
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Security
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> An empty {{ip_allow.config}} should block all traffic (default deny) but if
> the file does not exist it should disable IP allow (default allow). Currently
> if the file does not exist it acts as an empty file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5016) TS should allow force reload, and may also check inclued files
[ https://issues.apache.org/jira/browse/TS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5016: --- Fix Version/s: 7.1.0 > TS should allow force reload, and may also check inclued files > --- > > Key: TS-5016 > URL: https://issues.apache.org/jira/browse/TS-5016 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Fang > Fix For: 7.1.0 > > > 1) on config change, if TS hasn't detect the changes yet - traffic_ctl config > status show "current", > reload seems skipped. so user may need to wait for the detection. > this happens if config file are generated by programs since the reload > is immediately. > 2) for included config files, such as .include from remap.config, > if included files changes, TS still seems configuration as current -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
[ https://issues.apache.org/jira/browse/TS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5023: --- Fix Version/s: 7.1.0 > Allow diags.log and traffic.out to be rotated by size or time > - > > Key: TS-5023 > URL: https://issues.apache.org/jira/browse/TS-5023 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > Fix For: 7.1.0 > > > Create a 3rd option for diags.log and traffic.out to be rolled by time OR > size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Summary: Master does not build on omnios (was: master does not build on omnios) > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4986) Memory leak in test_Map
[
https://issues.apache.org/jira/browse/TS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-4986:
--
Assignee: Bryan Call
> Memory leak in test_Map
> ---
>
> Key: TS-4986
> URL: https://issues.apache.org/jira/browse/TS-4986
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> =
> ==22202==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 3216 byte(s) in 134 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402df9 in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:76
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 112 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x406576 in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x406576 in Vec 2>::set_expand() ../../lib/ts/Vec.h:781
> #4 0x406576 in HashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:552
> #5 0x401d90 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:174
> #6 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f26 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:196
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d4a in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:73
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401efe in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:194
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f12 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:195
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf
[jira] [Updated] (TS-5022) Multiple Client Certificate to Origin
[ https://issues.apache.org/jira/browse/TS-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5022: --- Fix Version/s: 7.1.0 > Multiple Client Certificate to Origin > - > > Key: TS-5022 > URL: https://issues.apache.org/jira/browse/TS-5022 > Project: Traffic Server > Issue Type: Improvement > Components: Security, SSL, TLS >Reporter: Scott Beardsley >Assignee: Leif Hedstrom > Labels: yahoo > Fix For: 7.1.0 > > > Yahoo has a use case where the origin is doing mutual TLS authentication > which requires ATS to send a client certificate. This works fine (for now) > because ATS supports configuring *one* client cert but this feature should > really allow multiple client certificates to be configured which would depend > upon the origin being contacted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4986) Memory leak in test_Map
[
https://issues.apache.org/jira/browse/TS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-4986.
Resolution: Fixed
> Memory leak in test_Map
> ---
>
> Key: TS-4986
> URL: https://issues.apache.org/jira/browse/TS-4986
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> =
> ==22202==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 3216 byte(s) in 134 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402df9 in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:76
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 112 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x406576 in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x406576 in Vec 2>::set_expand() ../../lib/ts/Vec.h:781
> #4 0x406576 in HashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:552
> #5 0x401d90 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:174
> #6 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f26 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:196
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d4a in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:73
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401efe in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:194
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f12 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:195
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in
[jira] [Updated] (TS-4986) Memory leak in test_Map
[
https://issues.apache.org/jira/browse/TS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4986:
---
Fix Version/s: 7.1.0
> Memory leak in test_Map
> ---
>
> Key: TS-4986
> URL: https://issues.apache.org/jira/browse/TS-4986
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> =
> ==22202==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 3216 byte(s) in 134 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402df9 in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:76
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 112 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x406576 in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x406576 in Vec 2>::set_expand() ../../lib/ts/Vec.h:781
> #4 0x406576 in HashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:552
> #5 0x401d90 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:174
> #6 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f26 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:196
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d4a in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:73
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401efe in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:194
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f12 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:195
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in
[jira] [Updated] (TS-3939) Add a --enable-asan configure option
[ https://issues.apache.org/jira/browse/TS-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3939: --- Summary: Add a --enable-asan configure option (was: Add a --enable-asan configure options) > Add a --enable-asan configure option > > > Key: TS-3939 > URL: https://issues.apache.org/jira/browse/TS-3939 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Leif Hedstrom >Assignee: Bryan Call > Labels: newbie > Fix For: 7.1.0 > > > It might be useful to make these options, to make it simpler / easier to add > a build that uses ASan (or TSan). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3939) Add a --enable-asan configure options
[ https://issues.apache.org/jira/browse/TS-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3939: --- Summary: Add a --enable-asan configure options (was: Add a --with-asan (and perhaps --with-tsan) configure options) > Add a --enable-asan configure options > - > > Key: TS-3939 > URL: https://issues.apache.org/jira/browse/TS-3939 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Leif Hedstrom >Assignee: Bryan Call > Labels: newbie > Fix For: 7.1.0 > > > It might be useful to make these options, to make it simpler / easier to add > a build that uses ASan (or TSan). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5019) Add total header length checks in HPACK
[ https://issues.apache.org/jira/browse/TS-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-5019. Resolution: Fixed > Add total header length checks in HPACK > --- > > Key: TS-5019 > URL: https://issues.apache.org/jira/browse/TS-5019 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masaori Koshiba >Assignee: Masaori Koshiba > Fix For: 7.0.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5019) Add total header length checks in HPACK
[ https://issues.apache.org/jira/browse/TS-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5019: --- Backport to Version: 6.2.1 (was: 6.2.1, 7.0.0) > Add total header length checks in HPACK > --- > > Key: TS-5019 > URL: https://issues.apache.org/jira/browse/TS-5019 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masaori Koshiba >Assignee: Masaori Koshiba > Fix For: 7.0.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5019) Add total header length checks in HPACK
[ https://issues.apache.org/jira/browse/TS-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5019: --- Fix Version/s: (was: 7.1.0) 7.0.0 > Add total header length checks in HPACK > --- > > Key: TS-5019 > URL: https://issues.apache.org/jira/browse/TS-5019 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masaori Koshiba >Assignee: Masaori Koshiba > Fix For: 7.0.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5019) Add total header length checks in HPACK
[ https://issues.apache.org/jira/browse/TS-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5019: --- Assignee: Masaori Koshiba (was: Bryan Call) > Add total header length checks in HPACK > --- > > Key: TS-5019 > URL: https://issues.apache.org/jira/browse/TS-5019 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masaori Koshiba >Assignee: Masaori Koshiba > Fix For: 7.1.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5019) Add total header length checks in HPACK
[ https://issues.apache.org/jira/browse/TS-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-5019: -- Assignee: Bryan Call > Add total header length checks in HPACK > --- > > Key: TS-5019 > URL: https://issues.apache.org/jira/browse/TS-5019 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masaori Koshiba >Assignee: Bryan Call > Fix For: 7.1.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4993) Backslash/escape removed from header_rewrite rule when unquoted
[
https://issues.apache.org/jira/browse/TS-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4993:
---
Summary: Backslash/escape removed from header_rewrite rule when unquoted
(was: backslash/escape removed from header_rewrite rule when unquoted)
> Backslash/escape removed from header_rewrite rule when unquoted
> ---
>
> Key: TS-4993
> URL: https://issues.apache.org/jira/browse/TS-4993
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 7.0.0
>Reporter: Randall Meyer
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Loading up a configuration with a header_rewrite rule of:
> {noformat}
> cond %{READ_RESPONSE_HDR_HOOK} [AND]
> cond %{PATH} /(\.html|\.js|\.png)(?:\?(.*))*$/ [AND]
> cond %{STATUS} >199 [AND]
> cond %{STATUS} <300
> set-header Cache-Control "max-age=31536000, public
> {noformat}
> results in an call to abort() in matcher.h under ATS 7.0.0. This worked fine
> under ATS 6.x (and probably 5.3.x)
> {noformat}
> (gdb) where
> #0 0x74f64625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x74f65e05 in *__GI_abort () at abort.c:92
> #2 0x7fffe71dd3ff in Matchers::setRegex
> (this=this@entry=0x7fffe5ac0f80) at matcher.h:98
> #3 0x7fffe71d7baa in Matchers::set (d=...,
> this=0x7fffe5ac0f80) at matcher.h:119
> #4 ConditionPath::initialize (this=0x7fffe59a6d00, p=...) at
> conditions.cc:260
> {noformat}
> The string comes to matcher with the escapes removed:
> {noformat}
> Adding condition: %{PATH} with arg: /(.html|.js|.png)(?:?(.*))*$/
> {noformat}
> If I add quotes around the regex, this regex is passed through correctly
> escaped.
> Not sure if this is expected behavior or not.
> This also seems related to TS-4797 and TS-4940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4993) backslash/escape removed from header_rewrite rule when unquoted
[
https://issues.apache.org/jira/browse/TS-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4993:
---
Fix Version/s: (was: 7.1.0)
7.0.0
> backslash/escape removed from header_rewrite rule when unquoted
> ---
>
> Key: TS-4993
> URL: https://issues.apache.org/jira/browse/TS-4993
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 7.0.0
>Reporter: Randall Meyer
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Loading up a configuration with a header_rewrite rule of:
> {noformat}
> cond %{READ_RESPONSE_HDR_HOOK} [AND]
> cond %{PATH} /(\.html|\.js|\.png)(?:\?(.*))*$/ [AND]
> cond %{STATUS} >199 [AND]
> cond %{STATUS} <300
> set-header Cache-Control "max-age=31536000, public
> {noformat}
> results in an call to abort() in matcher.h under ATS 7.0.0. This worked fine
> under ATS 6.x (and probably 5.3.x)
> {noformat}
> (gdb) where
> #0 0x74f64625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x74f65e05 in *__GI_abort () at abort.c:92
> #2 0x7fffe71dd3ff in Matchers::setRegex
> (this=this@entry=0x7fffe5ac0f80) at matcher.h:98
> #3 0x7fffe71d7baa in Matchers::set (d=...,
> this=0x7fffe5ac0f80) at matcher.h:119
> #4 ConditionPath::initialize (this=0x7fffe59a6d00, p=...) at
> conditions.cc:260
> {noformat}
> The string comes to matcher with the escapes removed:
> {noformat}
> Adding condition: %{PATH} with arg: /(.html|.js|.png)(?:?(.*))*$/
> {noformat}
> If I add quotes around the regex, this regex is passed through correctly
> escaped.
> Not sure if this is expected behavior or not.
> This also seems related to TS-4797 and TS-4940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4993) Backslash/escape removed from header_rewrite rule when unquoted
[
https://issues.apache.org/jira/browse/TS-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4993:
---
Backport to Version: (was: 7.0.0)
> Backslash/escape removed from header_rewrite rule when unquoted
> ---
>
> Key: TS-4993
> URL: https://issues.apache.org/jira/browse/TS-4993
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 7.0.0
>Reporter: Randall Meyer
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Loading up a configuration with a header_rewrite rule of:
> {noformat}
> cond %{READ_RESPONSE_HDR_HOOK} [AND]
> cond %{PATH} /(\.html|\.js|\.png)(?:\?(.*))*$/ [AND]
> cond %{STATUS} >199 [AND]
> cond %{STATUS} <300
> set-header Cache-Control "max-age=31536000, public
> {noformat}
> results in an call to abort() in matcher.h under ATS 7.0.0. This worked fine
> under ATS 6.x (and probably 5.3.x)
> {noformat}
> (gdb) where
> #0 0x74f64625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x74f65e05 in *__GI_abort () at abort.c:92
> #2 0x7fffe71dd3ff in Matchers::setRegex
> (this=this@entry=0x7fffe5ac0f80) at matcher.h:98
> #3 0x7fffe71d7baa in Matchers::set (d=...,
> this=0x7fffe5ac0f80) at matcher.h:119
> #4 ConditionPath::initialize (this=0x7fffe59a6d00, p=...) at
> conditions.cc:260
> {noformat}
> The string comes to matcher with the escapes removed:
> {noformat}
> Adding condition: %{PATH} with arg: /(.html|.js|.png)(?:?(.*))*$/
> {noformat}
> If I add quotes around the regex, this regex is passed through correctly
> escaped.
> Not sure if this is expected behavior or not.
> This also seems related to TS-4797 and TS-4940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3939) Add a --with-asan (and perhaps --with-tsan) configure options
[ https://issues.apache.org/jira/browse/TS-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-3939: -- Assignee: Bryan Call (was: Randall Meyer) > Add a --with-asan (and perhaps --with-tsan) configure options > - > > Key: TS-3939 > URL: https://issues.apache.org/jira/browse/TS-3939 > Project: Traffic Server > Issue Type: New Feature > Components: Build >Reporter: Leif Hedstrom >Assignee: Bryan Call > Labels: newbie > Fix For: 7.1.0 > > > It might be useful to make these options, to make it simpler / easier to add > a build that uses ASan (or TSan). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4641) Change default for proxy.config.cache.hostdb.sync_frequency
[
https://issues.apache.org/jira/browse/TS-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4641:
---
Fix Version/s: (was: 7.1.0)
8.0.0
> Change default for proxy.config.cache.hostdb.sync_frequency
> ---
>
> Key: TS-4641
> URL: https://issues.apache.org/jira/browse/TS-4641
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Documentation, HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Labels: incompatible
> Fix For: 8.0.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I'd like to propose that we change this setting, to 0, which means disable
> HostDB Synchronization. This is an incompatible change, but nonetheless a
> step in the right direction away from persistent HostDB storage. People can
> of course still enable it.
> {code}
> diff --git a/mgmt/RecordsConfig.cc b/mgmt/RecordsConfig.cc
> index ed71b5c..7a7e1c7 100644
> --- a/mgmt/RecordsConfig.cc
> +++ b/mgmt/RecordsConfig.cc
> @@ -1078,7 +1078,7 @@ static const RecordElement RecordsConfig[] =
>{RECT_CONFIG, "proxy.config.hostdb.timed_round_robin", RECD_INT, "0",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
>// # how often should the hostdb be synced (seconds)
> - {RECT_CONFIG, "proxy.config.cache.hostdb.sync_frequency", RECD_INT, "120",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> + {RECT_CONFIG, "proxy.config.cache.hostdb.sync_frequency", RECD_INT, "0",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
>{RECT_CONFIG, "proxy.config.hostdb.host_file.path", RECD_STRING, NULL,
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
> {code}
> Note that changing it to 0, or changing it from 0 to something else,
> requires restart. It's only "dynamic" if it it's not 0 (which turns off the
> sync cont).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4167) Change default value of proxy.config.http2.active_timeout_in
[
https://issues.apache.org/jira/browse/TS-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4167:
---
Fix Version/s: (was: 7.1.0)
8.0.0
> Change default value of proxy.config.http2.active_timeout_in
>
>
> Key: TS-4167
> URL: https://issues.apache.org/jira/browse/TS-4167
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
> Labels: incompatible
> Fix For: 8.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {{proxy.config.http2.active_timeout_in}} is added by TS-4162. The default
> value is 0 for compatibility with existing 6.x code.
> We're going to choose suitable value and set it in 7.0.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3625) Some statistics not being gathered
[
https://issues.apache.org/jira/browse/TS-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3625:
---
Fix Version/s: (was: 7.2.0)
8.0.0
> Some statistics not being gathered
> --
>
> Key: TS-3625
> URL: https://issues.apache.org/jira/browse/TS-3625
> Project: Traffic Server
> Issue Type: Bug
> Components: Metrics
>Reporter: Jon Sime
>Assignee: Bryan Call
> Labels: incompatible
> Fix For: 8.0.0
>
>
> The following statistics appear to not have any data collected for them in
> recent versions of TS, instead only emitting a zero value. The list was put
> together by examining the stats_over_http output on a production instance
> which receives enough varied traffic that it should, in theory at least,
> cause most implemented statistics to go non-zero.
> {code}
> proxy.node.cache.contents.num_docs
> proxy.node.cache_hit_mem_ratio_avg_10s_int_pct
> proxy.node.cache_hit_mem_ratio_int_pct
> proxy.node.current_cache_connections
> proxy.node.dns.lookup_avg_time_ms
> proxy.node.dns.lookups_per_second
> proxy.node.dns.total_dns_lookups
> proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct
> proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct
> proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct
> proxy.node.log.bytes_flush_to_disk
> proxy.node.log.bytes_lost_before_flush_to_disk
> proxy.node.log.bytes_lost_before_preproc
> proxy.node.log.bytes_lost_before_sent_to_network
> proxy.node.log.bytes_lost_before_written_to_disk
> proxy.node.log.bytes_received_from_network
> proxy.node.log.bytes_received_from_network_avg_10s
> proxy.node.log.bytes_sent_to_network
> proxy.node.log.bytes_sent_to_network_avg_10s
> proxy.node.log.bytes_written_to_disk
> proxy.node.log.event_log_access_aggr
> proxy.node.log.event_log_access_fail
> proxy.node.log.event_log_access_full
> proxy.node.log.event_log_access_ok
> proxy.node.log.event_log_access_skip
> proxy.node.log.event_log_error_aggr
> proxy.node.log.event_log_error_fail
> proxy.node.log.event_log_error_full
> proxy.node.log.event_log_error_ok
> proxy.node.log.event_log_error_skip
> proxy.node.log.num_flush_to_disk
> proxy.node.log.num_lost_before_flush_to_disk
> proxy.node.log.num_lost_before_sent_to_network
> proxy.node.log.num_received_from_network
> proxy.node.log.num_sent_to_network
> proxy.process.cache.directory_collision
> proxy.process.cache.evacuate.active
> proxy.process.cache.evacuate.failure
> proxy.process.cache.evacuate.success
> proxy.process.cache.frags_per_doc.1
> proxy.process.cache.frags_per_doc.2
> proxy.process.cache.frags_per_doc.3+
> proxy.process.cache.gc_bytes_evacuated
> proxy.process.cache.gc_frags_evacuated
> proxy.process.cache.hdr_marshal_bytes
> proxy.process.cache.hdr_marshals
> proxy.process.cache.lookup.active
> proxy.process.cache.lookup.failure
> proxy.process.cache.lookup.success
> proxy.process.cache.percent_full
> proxy.process.cache.pread_count
> proxy.process.cache.read_busy.failure
> proxy.process.cache.read_busy.success
> proxy.process.cache.remove.active
> proxy.process.cache.remove.failure
> proxy.process.cache.remove.success
> proxy.process.cache.scan.active
> proxy.process.cache.scan.failure
> proxy.process.cache.scan.success
> proxy.process.cache.volume_0.directory_collision
> proxy.process.cache.volume_0.evacuate.active
> proxy.process.cache.volume_0.evacuate.failure
> proxy.process.cache.volume_0.evacuate.success
> proxy.process.cache.volume_0.frags_per_doc.1
> proxy.process.cache.volume_0.frags_per_doc.2
> proxy.process.cache.volume_0.frags_per_doc.3+
> proxy.process.cache.volume_0.gc_bytes_evacuated
> proxy.process.cache.volume_0.gc_frags_evacuated
> proxy.process.cache.volume_0.hdr_marshal_bytes
> proxy.process.cache.volume_0.hdr_marshals
> proxy.process.cache.volume_0.lookup.active
> proxy.process.cache.volume_0.lookup.failure
> proxy.process.cache.volume_0.lookup.success
> proxy.process.cache.volume_0.pread_count
> proxy.process.cache.volume_0.remove.active
>
[jira] [Updated] (TS-3399) Make a better default for proxy.config.proxy_name
[ https://issues.apache.org/jira/browse/TS-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3399: --- Fix Version/s: (was: 7.1.0) 8.0.0 > Make a better default for proxy.config.proxy_name > - > > Key: TS-3399 > URL: https://issues.apache.org/jira/browse/TS-3399 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: incompatible > Fix For: 8.0.0 > > > As of somewhere between 5.1.x and 5.2.x, we eliminated > proxy.config.proxy_name from records.config.in. It used to be set to the > build machine name, but now we default to the one in RecordsConfig.cc (which > is ). > I'd like to suggest we do one of two things (please voice your opinion): > 1) Restore the proxy.config.proxy_name into records.config.in, with the old > setting (@buildmachine@). > 2) Use the *hostname* from the Machine object. This is basically > gethostname(). > I think I prefer #2, but I'm also open for other suggestions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4826) Nuke deprecated TS APIs.
[
https://issues.apache.org/jira/browse/TS-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4826:
---
Fix Version/s: (was: 7.1.0)
8.0.0
> Nuke deprecated TS APIs.
>
>
> Key: TS-4826
> URL: https://issues.apache.org/jira/browse/TS-4826
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: James Peach
>Assignee: Bryan Call
> Labels: incompatible
> Fix For: 8.0.0
>
>
> Check {{ts..h}} for deprecated APIs that we should remove for 7.0.
> {{TSRedirectUrlSet}} and {{TSRedirectUrlGet}} at least.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3183) Clean up (and/or eliminate?) some proxy.node metrics
[ https://issues.apache.org/jira/browse/TS-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3183: --- Fix Version/s: (was: 7.1.0) 8.0.0 > Clean up (and/or eliminate?) some proxy.node metrics > > > Key: TS-3183 > URL: https://issues.apache.org/jira/browse/TS-3183 > Project: Traffic Server > Issue Type: Improvement > Components: Metrics >Reporter: Leif Hedstrom > Labels: incompatible > Fix For: 8.0.0 > > > There's two types of metrics it seems, proxy.node and proxy.process. > Unfortunately, in at least a few cases, the same metrics get duplicated into > both. I'm not sure why that makes sense, ever, so I think we should clean > that up. That would certainly make it less confusing. > Secondly, it seems proxy.node metrics, which are registered via > RecordsConfig.cc, are primarily used for computed metrics. These are metrics > synthesized via the stats.config.xml mechanism. Albeit being useful, what's > bad with the current design here is that adding new metrics to the XML config > file still requires a change to RecordsConfig.cc. This makes no sense to me, > so perhaps the proxy.node metrics should all be eliminated from > RecordsConfig.cc, and exclusively owned (registered and updated) via the XML > config format. > Elimination, or renaming, of any of these metrics would be an incompatible > change. Therefore, it would go into 6.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4992) We always create .a libraries now
[ https://issues.apache.org/jira/browse/TS-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4992: --- Backport to Version: (was: 7.0.0) > We always create .a libraries now > - > > Key: TS-4992 > URL: https://issues.apache.org/jira/browse/TS-4992 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > We noticed that the build produces .a files now (which ended up failing our > RPM build). So spoke with Bryan, and we both agree that we should disable the > build of .a's again. The suspicion is that it was a mistake to enable them > always as part of TS-3577: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4992) We always create .a libraries now
[ https://issues.apache.org/jira/browse/TS-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4992: --- Fix Version/s: (was: 7.1.0) 7.0.0 > We always create .a libraries now > - > > Key: TS-4992 > URL: https://issues.apache.org/jira/browse/TS-4992 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > We noticed that the build produces .a files now (which ended up failing our > RPM build). So spoke with Bryan, and we both agree that we should disable the > build of .a's again. The suspicion is that it was a mistake to enable them > always as part of TS-3577: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock
[
https://issues.apache.org/jira/browse/TS-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4916:
---
Fix Version/s: (was: 7.1.0)
7.0.0
> Http2ConnectionState::restart_streams infinite loop causes deadlock
>
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.0.0
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next”
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0 0x2acf3fee in Http2ConnectionState::restart_streams
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1 rcv_window_update_frame (cstate=..., frame=...) at
> Http2ConnectionState.cc:627
> #2 0x2acf9738 in Http2ConnectionState::main_event_handler
> (this=0x2ae6ba5284c8, event=, edata=) at
> Http2ConnectionState.cc:823
> #3 0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0,
> event=2253, this=0x2ae6ba5284c8) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #4 send_connection_event (cont=cont@entry=0x2ae6ba5284c8,
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at
> Http2ClientSession.cc:58
> #5 0x2acef462 in Http2ClientSession::state_complete_frame_read
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at
> Http2ClientSession.cc:426
> #6 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #7 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290,
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8 0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290,
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290,
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00,
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0,
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700,
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700,
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0 0x2acf3fee in Http2ConnectionState::restart_streams
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> --- count=3 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> . . .
> --- count=5560 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> . . .
> {code}
> Currently I am working on finding out why the list in question got into this
> “impossible” (broken) state and and
[jira] [Updated] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock
[
https://issues.apache.org/jira/browse/TS-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4916:
---
Backport to Version: 6.2.1 (was: 6.2.1, 7.0.0)
> Http2ConnectionState::restart_streams infinite loop causes deadlock
>
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.0.0
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next”
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0 0x2acf3fee in Http2ConnectionState::restart_streams
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1 rcv_window_update_frame (cstate=..., frame=...) at
> Http2ConnectionState.cc:627
> #2 0x2acf9738 in Http2ConnectionState::main_event_handler
> (this=0x2ae6ba5284c8, event=, edata=) at
> Http2ConnectionState.cc:823
> #3 0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0,
> event=2253, this=0x2ae6ba5284c8) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #4 send_connection_event (cont=cont@entry=0x2ae6ba5284c8,
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at
> Http2ClientSession.cc:58
> #5 0x2acef462 in Http2ClientSession::state_complete_frame_read
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at
> Http2ClientSession.cc:426
> #6 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #7 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290,
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8 0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #9 Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290,
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290,
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1,
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00,
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0,
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700,
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700,
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0 0x2acf3fee in Http2ConnectionState::restart_streams
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> --- count=3 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> . . .
> --- count=5560 ---
> id=19
> this=0x2ae5b6bbec00
> next=0x2ae5b6bbec00
> prev=0x2aaac05d8900
> . . .
> {code}
> Currently I am working on finding out why the list in question got into this
> “impossible” (broken) state and and eventually
[jira] [Comment Edited] (TS-4989) Don't add Age: header to requests not served from cache
[
https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589908#comment-15589908
]
Bryan Call edited comment on TS-4989 at 10/19/16 9:29 PM:
--
I agree, we should remove the Age header from responses that were not cached.
https://tools.ietf.org/html/rfc7234#section-5.1 :
{noformat}
The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request.
However, lack of an Age header field does not imply the origin was
contacted, since the response might have been received from an
HTTP/1.0 cache that does not implement Age.
{noformat}
https://tools.ietf.org/html/rfc7234#section-4.2.3 :
{noformat}
4.2.3. Calculating Age
The Age header field is used to convey an estimated age of the
response message when obtained from a cache. The Age field value is
the cache's estimate of the number of seconds since the response was
generated or validated by the origin server.
{noformat}
was (Author: bcall):
https://tools.ietf.org/html/rfc7234#section-5.1 :
{noformat}
The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request.
However, lack of an Age header field does not imply the origin was
contacted, since the response might have been received from an
HTTP/1.0 cache that does not implement Age.
{noformat}
https://tools.ietf.org/html/rfc7234#section-4.2.3 :
{noformat}
4.2.3. Calculating Age
The Age header field is used to convey an estimated age of the
response message when obtained from a cache. The Age field value is
the cache's estimate of the number of seconds since the response was
generated or validated by the origin server.
{noformat}
> Don't add Age: header to requests not served from cache
> ---
>
> Key: TS-4989
> URL: https://issues.apache.org/jira/browse/TS-4989
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: David Carlin
> Labels: yahoo
>
> You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a
> request - for requests not served from cache. Causes confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4989) Don't add Age: header to requests not served from cache
[
https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589908#comment-15589908
]
Bryan Call edited comment on TS-4989 at 10/19/16 9:27 PM:
--
https://tools.ietf.org/html/rfc7234#section-5.1 :
{noformat}
The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request.
However, lack of an Age header field does not imply the origin was
contacted, since the response might have been received from an
HTTP/1.0 cache that does not implement Age.
{noformat}
https://tools.ietf.org/html/rfc7234#section-4.2.3 :
{noformat}
4.2.3. Calculating Age
The Age header field is used to convey an estimated age of the
response message when obtained from a cache. The Age field value is
the cache's estimate of the number of seconds since the response was
generated or validated by the origin server.
{noformat}
was (Author: bcall):
https://tools.ietf.org/html/rfc7234#section-5.1 :
{noformat}
The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request.
However, lack of an Age header field does not imply the origin was
contacted, since the response might have been received from an
HTTP/1.0 cache that does not implement Age.
{noformat}
> Don't add Age: header to requests not served from cache
> ---
>
> Key: TS-4989
> URL: https://issues.apache.org/jira/browse/TS-4989
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: David Carlin
> Labels: yahoo
>
> You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a
> request - for requests not served from cache. Causes confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4989) Don't add Age: header to requests not served from cache
[
https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589908#comment-15589908
]
Bryan Call edited comment on TS-4989 at 10/19/16 9:25 PM:
--
https://tools.ietf.org/html/rfc7234#section-5.1 :
{noformat}
The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request.
However, lack of an Age header field does not imply the origin was
contacted, since the response might have been received from an
HTTP/1.0 cache that does not implement Age.
{noformat}
was (Author: bcall):
https://tools.ietf.org/html/rfc7234#section-5.1 :
{noformat}
The "Age" header field conveys the sender's estimate of the amount of
time since the response was generated or successfully validated at
the origin server. Age values are calculated as specified in
Section 4.2.3.
{noformat}
> Don't add Age: header to requests not served from cache
> ---
>
> Key: TS-4989
> URL: https://issues.apache.org/jira/browse/TS-4989
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: David Carlin
> Labels: yahoo
>
> You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a
> request - for requests not served from cache. Causes confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4989) Don't add Age: header to requests not served from cache
[
https://issues.apache.org/jira/browse/TS-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589908#comment-15589908
]
Bryan Call commented on TS-4989:
https://tools.ietf.org/html/rfc7234#section-5.1 :
{noformat}
The "Age" header field conveys the sender's estimate of the amount of
time since the response was generated or successfully validated at
the origin server. Age values are calculated as specified in
Section 4.2.3.
{noformat}
> Don't add Age: header to requests not served from cache
> ---
>
> Key: TS-4989
> URL: https://issues.apache.org/jira/browse/TS-4989
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: David Carlin
> Labels: yahoo
>
> You can sometimes see Ages of 0,1,2,etc.. - the time it took to process a
> request - for requests not served from cache. Causes confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4909) Throttling based on resident memory usage
[ https://issues.apache.org/jira/browse/TS-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-4909. Resolution: Fixed > Throttling based on resident memory usage > - > > Key: TS-4909 > URL: https://issues.apache.org/jira/browse/TS-4909 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Add a feature to stop accepting connections if the resident memory is over a > certain limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4947) Collation Server is broken?
[
https://issues.apache.org/jira/browse/TS-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-4947.
Resolution: Fixed
Fix Version/s: (was: 7.1.0)
7.0.0
> Collation Server is broken?
> ---
>
> Key: TS-4947
> URL: https://issues.apache.org/jira/browse/TS-4947
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 7.0.0
>Reporter: bettydramit
>Assignee: James Peach
>Priority: Critical
> Fix For: 7.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> from gitmaster(github.com/apache/trafficserver)
> config Collation Client
> {code:xml}
> CONFIG proxy.config.url_remap.filename STRING remap.config
> CONFIG proxy.config.log.config.filename STRING logging.config
> CONFIG proxy.config.log.collation_host STRING 192.168.2.33
> CONFIG proxy.config.log.collation_secret STRING testlog
> LOCAL proxy.local.log.collation_mode INT 2
> CONFIG proxy.config.log.collation_port INT 8085
> {code}
> config Collation Server
> {code:xml}
> CONFIG proxy.local.log.collation_mode INT 1
> CONFIG proxy.config.log.collation_port INT 8085
> CONFIG proxy.config.log.collation_secret STRING testlog
> {code}
> logging.config
> {code:xml}
> w3c = format {
> Format='% %<{Cdn-Real-Ip}cqh> - % [%] \"% %
> %\" % % \"%<{Referer}cqh>\" \"%<{user-agent}cqh>\" %
> % % % % % %'
> }
> log.ascii {
> Filename = 'c11',
> Format = w3c,
> CollationHosts = { '192.168.2.33:8085' }
> }
> {code}
> It still flush log to local disk not to remote collation server
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4947) Collation Server is broken?
[
https://issues.apache.org/jira/browse/TS-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4947:
---
Backport to Version: (was: 7.0.0)
> Collation Server is broken?
> ---
>
> Key: TS-4947
> URL: https://issues.apache.org/jira/browse/TS-4947
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 7.0.0
>Reporter: bettydramit
>Assignee: James Peach
>Priority: Critical
> Fix For: 7.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> from gitmaster(github.com/apache/trafficserver)
> config Collation Client
> {code:xml}
> CONFIG proxy.config.url_remap.filename STRING remap.config
> CONFIG proxy.config.log.config.filename STRING logging.config
> CONFIG proxy.config.log.collation_host STRING 192.168.2.33
> CONFIG proxy.config.log.collation_secret STRING testlog
> LOCAL proxy.local.log.collation_mode INT 2
> CONFIG proxy.config.log.collation_port INT 8085
> {code}
> config Collation Server
> {code:xml}
> CONFIG proxy.local.log.collation_mode INT 1
> CONFIG proxy.config.log.collation_port INT 8085
> CONFIG proxy.config.log.collation_secret STRING testlog
> {code}
> logging.config
> {code:xml}
> w3c = format {
> Format='% %<{Cdn-Real-Ip}cqh> - % [%] \"% %
> %\" % % \"%<{Referer}cqh>\" \"%<{user-agent}cqh>\" %
> % % % % % %'
> }
> log.ascii {
> Filename = 'c11',
> Format = w3c,
> CollationHosts = { '192.168.2.33:8085' }
> }
> {code}
> It still flush log to local disk not to remote collation server
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4835) Stale while revalidate plugin should only ignore its own requests
[
https://issues.apache.org/jira/browse/TS-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4835:
---
Summary: Stale while revalidate plugin should only ignore its own requests
(was: stale while revalidate plugin should only ignore its own requests)
> Stale while revalidate plugin should only ignore its own requests
> -
>
> Key: TS-4835
> URL: https://issues.apache.org/jira/browse/TS-4835
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently the {{stale_while_revalidate}} plugin ignores all internal
> requests, which makes it a no-op for protocol plugins. It should use the
> {{TSHttpTxnPluginTagGet}} to only ignore requests that it issues itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4709) Separate LogFilter parser
[ https://issues.apache.org/jira/browse/TS-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4709: --- Summary: Separate LogFilter parser (was: separate LogFilter parser) > Separate LogFilter parser > - > > Key: TS-4709 > URL: https://issues.apache.org/jira/browse/TS-4709 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: James Peach >Assignee: James Peach > Fix For: 7.0.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Separate the LogFilter parser from the XML configuration parser so that it > can be tested and reused by the Lua configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4794) Fix memory leaks with DNS and Net tests
[ https://issues.apache.org/jira/browse/TS-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-4794: --- Summary: Fix memory leaks with DNS and Net tests (was: Fix memory leaks) > Fix memory leaks with DNS and Net tests > --- > > Key: TS-4794 > URL: https://issues.apache.org/jira/browse/TS-4794 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Network >Reporter: Bryon Gloden, CISSP® >Assignee: James Peach > Fix For: 7.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > With reference to (WRT) https://github.com/apache/trafficserver/pull/855, on > line no. 74 of 'test_P_DNS.cc' there is a memory leak and on line no. 72 of > 'test_P_Net.cc' there is memory leak -- both memory leaks are errors. > Ping [~zwoop] > Found by https://github.com/bryongloden/cppcheck -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4458) Disabling configuration modification breaks reloading
[
https://issues.apache.org/jira/browse/TS-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4458:
---
Summary: Disabling configuration modification breaks reloading (was:
disabling configuration modification breaks reloading)
> Disabling configuration modification breaks reloading
> -
>
> Key: TS-4458
> URL: https://issues.apache.org/jira/browse/TS-4458
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> If you set {{proxy.config.disable_configuration_modification}} to 1, records
> configuration callbacks are never registered, so if you update
> {{records.config}} and then reload with {{traffic_ctl config reload}}, the
> new configuration is not actually applied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4619) Intermediate certificate chain loading can miss certificates
[
https://issues.apache.org/jira/browse/TS-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4619:
---
Summary: Intermediate certificate chain loading can miss certificates
(was: intermediate certificate chain loading can miss certificates)
> Intermediate certificate chain loading can miss certificates
>
>
> Key: TS-4619
> URL: https://issues.apache.org/jira/browse/TS-4619
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When loading intermediate SSL certificates, the original code used
> {{SSL_CTX_add_extra_chain_cert_file}} which adds all the certificates in the
> file.
> The new code uses {{SSL_CTX_add0_chain_cert}} and passes it a single {{X509
> *}}, so it only ends up loading the first intermediate rather than all of
> them.
> This code occurs in 3 places with ugly {{#ifdefs}}. The right thing to do
> here is to call {{SSL_CTX_add_extra_chain_cert_file}} in every place and
> inside {{SSL_CTX_add_extra_chain_cert_file}} use {{SSL_CTX_add0_chain_cert}}
> if it is available.
> Also take a look at the place where the server certificate is loaded. This is
> also allowed to be a bundle, so we can call
> {{SSL_CTX_add_extra_chain_cert_file}} again to avoid the code duplication,
> though at this point we already have a {{BIO}} in hand that we would need to
> use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4521) Compile error on build proxy/http2/test_HPACK
[
https://issues.apache.org/jira/browse/TS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4521:
---
Summary: Compile error on build proxy/http2/test_HPACK (was: compile error
on build proxy/http2/test_HPACK)
> Compile error on build proxy/http2/test_HPACK
> -
>
> Key: TS-4521
> URL: https://issues.apache.org/jira/browse/TS-4521
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Oknet Xu
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> OS: Debian 7 (wheezy)
> ATS Branch: master
> GCC: 4.7.2(Debian 4.7.2-5)
> {code}
> /usr/bin/ld: ../../proxy/hdrs/libhdrs.a(HttpCompat.o): undefined reference to
> symbol 'Tcl_NextHashEntry'
> /usr/bin/ld: note: 'Tcl_NextHashEntry' is defined in DSO
> /usr/lib/libtcl8.5.so.0 so try adding it to the linker command line
> /usr/lib/libtcl8.5.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
