[jira] [Work stopped] (TS-4952) Improve mutex error checking.
[
https://issues.apache.org/jira/browse/TS-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-4952 stopped by James Peach.
---
> Improve mutex error checking.
> -
>
> Key: TS-4952
> URL: https://issues.apache.org/jira/browse/TS-4952
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> If any {{ink_mutex}} operations fail, we just abort. Use {{ink_abort}} so
> that we can log an error if this happens.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work started] (TS-4952) Improve mutex error checking.
[
https://issues.apache.org/jira/browse/TS-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-4952 started by James Peach.
---
> Improve mutex error checking.
> -
>
> Key: TS-4952
> URL: https://issues.apache.org/jira/browse/TS-4952
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> If any {{ink_mutex}} operations fail, we just abort. Use {{ink_abort}} so
> that we can log an error if this happens.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TS-5096) Lua metrics crashes if the prefix is missing
[
https://issues.apache.org/jira/browse/TS-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747393#comment-15747393
]
James Peach commented on TS-5096:
-
The problem here is that you can't "eval" a user data object in Lua. There's no
metamethod to do that, so in metrics we depend on triggering "__index" on a
prefix user data object.
> Lua metrics crashes if the prefix is missing
>
>
> Key: TS-5096
> URL: https://issues.apache.org/jira/browse/TS-5096
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Metrics
>Reporter: James Peach
>
> Using the example from the {{tslua.so}} documentation:
> {noformat}
> local test_stat;
> function __init__(args)
> test_stat = ts.stat_create("test_stat",
> TS_LUA_RECORDDATATYPE_INT,
> TS_LUA_STAT_PERSISTENT,
> TS_LUA_STAT_SYNC_COUNT)
> end
> {noformat}
> {{traffic_manager}} crashes in metrics update:
> {noformat}
> (gdb) where
> #0 0x75c964ad in __cxa_throw () from /lib64/libstdc++.so.6
> #1 0x75cbfdcf in std::__throw_length_error(char const*) () from
> /lib64/libstdc++.so.6
> #2 0x75d2a7ec in std::__cxx11::basic_string std::char_traits, std::allocator >::_M_create(unsigned long&,
> unsigned long) () from /lib64/libstdc++.so.6
> #3 0x004bbcf4 in std::__cxx11::basic_string std::char_traits, std::allocator >::_M_construct
> (this=0x7fffdc10, __beg=0x92ec30 "test_stat", __end=0x0) at
> /usr/include/c++/6.2.1/bits/basic_string.tcc:219
> #4 0x75d2d515 in std::__cxx11::basic_string std::char_traits, std::allocator >::basic_string(char const*,
> unsigned long, std::allocator const&) () from /lib64/libstdc++.so.6
> #5 0x004bd228 in install_metrics_object (rec_type=RECT_PLUGIN,
> edata=0x7fffdcf0, registered=1,
> name=0x92ec30 "test_stat", data_type=1, datum=0x77f7dc48) at
> metrics.cc:214
> #6 0x004a51a1 in RecDumpRecords (rec_type=46,
> callback=0x4bd1a3 int, RecData*)>, edata=0x7fffdcf0)
> at RecCore.cc:1020
> #7 0x004bd2dd in lua_metrics_install (L=0x4378) at metrics.cc:229
> #8 0x00449209 in update_metrics_namespace (L=0x4378) at
> metrics.cc:167
> #9 0x00449944 in metrics_binding_evaluate (binding=...) at
> metrics.cc:377
> #10 0x0044844d in main (argc=1, argv=0x7fffe578) at
> traffic_manager.cc:772
> (gdb)
> #5 0x004bd228 in install_metrics_object (rec_type=RECT_PLUGIN,
> edata=0x7fffdcf0, registered=1,
> name=0x92ec30 "test_stat", data_type=1, datum=0x77f7dc48) at
> metrics.cc:214
> 214 prefixes->insert(std::string(name, len));
> (gdb) p len
> $1 = -9628720
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5096) Lua metrics crashes if the prefix is missing
[
https://issues.apache.org/jira/browse/TS-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747388#comment-15747388
]
James Peach commented on TS-5096:
-
Root cause for this is that we assumed all metrics have a prefix and try to
install a metrics object. We can fix the crash by not doing an pointer
arithmetic, but you can't reference this metric from Lua. The Lua metrics code
works for metrics that are arranged in a tree, but if a root node in the tree
is a metric itself, there is no way to implement that in Lua. All we can do is
update a value with that name.
/cc [~kichan]
> Lua metrics crashes if the prefix is missing
>
>
> Key: TS-5096
> URL: https://issues.apache.org/jira/browse/TS-5096
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua, Metrics
>Reporter: James Peach
>
> Using the example from the {{tslua.so}} documentation:
> {noformat}
> local test_stat;
> function __init__(args)
> test_stat = ts.stat_create("test_stat",
> TS_LUA_RECORDDATATYPE_INT,
> TS_LUA_STAT_PERSISTENT,
> TS_LUA_STAT_SYNC_COUNT)
> end
> {noformat}
> {{traffic_manager}} crashes in metrics update:
> {noformat}
> (gdb) where
> #0 0x75c964ad in __cxa_throw () from /lib64/libstdc++.so.6
> #1 0x75cbfdcf in std::__throw_length_error(char const*) () from
> /lib64/libstdc++.so.6
> #2 0x75d2a7ec in std::__cxx11::basic_string std::char_traits, std::allocator >::_M_create(unsigned long&,
> unsigned long) () from /lib64/libstdc++.so.6
> #3 0x004bbcf4 in std::__cxx11::basic_string std::char_traits, std::allocator >::_M_construct
> (this=0x7fffdc10, __beg=0x92ec30 "test_stat", __end=0x0) at
> /usr/include/c++/6.2.1/bits/basic_string.tcc:219
> #4 0x75d2d515 in std::__cxx11::basic_string std::char_traits, std::allocator >::basic_string(char const*,
> unsigned long, std::allocator const&) () from /lib64/libstdc++.so.6
> #5 0x004bd228 in install_metrics_object (rec_type=RECT_PLUGIN,
> edata=0x7fffdcf0, registered=1,
> name=0x92ec30 "test_stat", data_type=1, datum=0x77f7dc48) at
> metrics.cc:214
> #6 0x004a51a1 in RecDumpRecords (rec_type=46,
> callback=0x4bd1a3 int, RecData*)>, edata=0x7fffdcf0)
> at RecCore.cc:1020
> #7 0x004bd2dd in lua_metrics_install (L=0x4378) at metrics.cc:229
> #8 0x00449209 in update_metrics_namespace (L=0x4378) at
> metrics.cc:167
> #9 0x00449944 in metrics_binding_evaluate (binding=...) at
> metrics.cc:377
> #10 0x0044844d in main (argc=1, argv=0x7fffe578) at
> traffic_manager.cc:772
> (gdb)
> #5 0x004bd228 in install_metrics_object (rec_type=RECT_PLUGIN,
> edata=0x7fffdcf0, registered=1,
> name=0x92ec30 "test_stat", data_type=1, datum=0x77f7dc48) at
> metrics.cc:214
> 214 prefixes->insert(std::string(name, len));
> (gdb) p len
> $1 = -9628720
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5096) Lua metrics crashes if the prefix is missing
James Peach created TS-5096:
---
Summary: Lua metrics crashes if the prefix is missing
Key: TS-5096
URL: https://issues.apache.org/jira/browse/TS-5096
Project: Traffic Server
Issue Type: Bug
Components: Lua, Metrics
Reporter: James Peach
Using the example from the {{tslua.so}} documentation:
{noformat}
local test_stat;
function __init__(args)
test_stat = ts.stat_create("test_stat",
TS_LUA_RECORDDATATYPE_INT,
TS_LUA_STAT_PERSISTENT,
TS_LUA_STAT_SYNC_COUNT)
end
{noformat}
{{traffic_manager}} crashes in metrics update:
{noformat}
(gdb) where
#0 0x75c964ad in __cxa_throw () from /lib64/libstdc++.so.6
#1 0x75cbfdcf in std::__throw_length_error(char const*) () from
/lib64/libstdc++.so.6
#2 0x75d2a7ec in std::__cxx11::basic_string::_M_create(unsigned long&,
unsigned long) () from /lib64/libstdc++.so.6
#3 0x004bbcf4 in std::__cxx11::basic_string::_M_construct
(this=0x7fffdc10, __beg=0x92ec30 "test_stat", __end=0x0) at
/usr/include/c++/6.2.1/bits/basic_string.tcc:219
#4 0x75d2d515 in std::__cxx11::basic_string::basic_string(char const*,
unsigned long, std::allocator const&) () from /lib64/libstdc++.so.6
#5 0x004bd228 in install_metrics_object (rec_type=RECT_PLUGIN,
edata=0x7fffdcf0, registered=1,
name=0x92ec30 "test_stat", data_type=1, datum=0x77f7dc48) at
metrics.cc:214
#6 0x004a51a1 in RecDumpRecords (rec_type=46,
callback=0x4bd1a3 , edata=0x7fffdcf0)
at RecCore.cc:1020
#7 0x004bd2dd in lua_metrics_install (L=0x4378) at metrics.cc:229
#8 0x00449209 in update_metrics_namespace (L=0x4378) at
metrics.cc:167
#9 0x00449944 in metrics_binding_evaluate (binding=...) at
metrics.cc:377
#10 0x0044844d in main (argc=1, argv=0x7fffe578) at
traffic_manager.cc:772
(gdb)
#5 0x004bd228 in install_metrics_object (rec_type=RECT_PLUGIN,
edata=0x7fffdcf0, registered=1,
name=0x92ec30 "test_stat", data_type=1, datum=0x77f7dc48) at
metrics.cc:214
214 prefixes->insert(std::string(name, len));
(gdb) p len
$1 = -9628720
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-2917) luajit ignores --disable-silent-rules
[
https://issues.apache.org/jira/browse/TS-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2917.
-
Resolution: Fixed
Assignee: James Peach (was: Jason Kenny)
> luajit ignores --disable-silent-rules
> -
>
> Key: TS-2917
> URL: https://issues.apache.org/jira/browse/TS-2917
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Arno Toell
>Assignee: James Peach
>Priority: Minor
> Fix For: 7.1.0
>
>
> When compiling ATS with --disable-silent-rules the luajit tree ignores that
> configure flag. Excerpt:
> {code}
> ./configure --enable-layout=Debian --sysconfdir=/etc/trafficserver
> --libdir=/usr/lib/trafficserver --with-user=root --with-group=root
> --disable-silent-rules --enable-experimental-plugins
> --enable-reclaimable-freelist CFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> CPPFLAGS="-D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security" FCFLAGS="-g -O2
> -fstack-protector --param=ssp-buffer-size=4" FFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4" GCJFLAGS="-g -O2 -fstack-protector
> --param=ssp-buffer-size=4" LDFLAGS="-Wl,-z,relro" OBJCFLAGS="-g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> OBJCXXFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security" --enable-wccp --enable-linux-native-aio
> ...
> make[3]: Entering directory
> '/home/arno/trafficserver/trafficserver/iocore/eventsystem'
> depbase=`echo EventSystem.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -I../../lib/records
> -I../../lib/ts -D_FORTIFY_SOURCE=2 -Dlinux -D_LARGEFILE64_SOURCE=1
> -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/tcl8.6
> -I/usr/include/libxml2 -Wunused-parameter -g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++11 -pipe
> -Wall -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -mcx16 -MT EventSystem.o -MD -MP -MF $depbase.Tpo -c -o
> EventSystem.o EventSystem.cc &&\
> mv -f $depbase.Tpo $depbase.Po
> ...
> make[4]: Entering directory
> '/home/arno/trafficserver/trafficserver/lib/luajit'
> Building LuaJIT 2.0.3
> make -C src
> make[5]: Entering directory
> '/home/arno/trafficserver/trafficserver/lib/luajit/src'
> HOSTCChost/minilua.o
> HOSTLINK host/minilua
> DYNASMhost/buildvm_arch.h
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5080) log when remap.config is done reloading
[
https://issues.apache.org/jira/browse/TS-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15723635#comment-15723635
]
James Peach commented on TS-5080:
-
[~randall] Can you look at making all the config file reload operations log a
{{Note}} in a consistent format?
> log when remap.config is done reloading
> ---
>
> Key: TS-5080
> URL: https://issues.apache.org/jira/browse/TS-5080
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Randall Meyer
>Assignee: Randall Meyer
>
> Currently, ATS does not log when remap.config successfully reloads, only if
> it fails. I'd like to know when the rewrite_table has successfully swapped to
> the new version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5065) Use after free clearing HostDB.
[
https://issues.apache.org/jira/browse/TS-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15704162#comment-15704162
]
James Peach commented on TS-5065:
-
{noformat}
commit 23672db4f1e6b3d7b633a82666955abe6ca86950
Author: James Peach
AuthorDate: Fri Nov 25 23:09:47 2016 -0800
TS-5065: Fix RefCountCache iterator invalidation.
Removing items from the TSHashMap invalidates the iterator because the
linked list pointers are embedded in the hash node, so we can't do that
while clearing. Instead, deallocate and remove each entry explicitly.
{noformat}
> Use after free clearing HostDB.
> ---
>
> Key: TS-5065
> URL: https://issues.apache.org/jira/browse/TS-5065
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ASAN points out that clearing the HostDB on startup results in a use after
> free since we are iterating at the same time as we are freeing hash entries
> (which contain the iterator links).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5066) HostDB serialization leaks on error path.
[
https://issues.apache.org/jira/browse/TS-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15704161#comment-15704161
]
James Peach commented on TS-5066:
-
{noformat}
commit 4a380d9d683d425cb7b2af30e1d57f0260ab829a
Author: James Peach
AuthorDate: Sat Nov 26 11:47:04 2016 -0800
TS-5066: Fix HostDB memory leaks on serialization failure.
If the serializer fails to write the partition, the copied entries were
being leaked. Clean up the cache entry allocation to centralize the
pain of it and allow both the cache and the serializer to share the same
allocation and free helpers.
{noformat}
> HostDB serialization leaks on error path.
> -
>
> Key: TS-5066
> URL: https://issues.apache.org/jira/browse/TS-5066
> Project: Traffic Server
> Issue Type: Bug
> Components: HostDB
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>
> If the RefCountCacheSerializer hits an IO error, it leaks the copied cache
> entries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5065) Use after free clearing HostDB.
[ https://issues.apache.org/jira/browse/TS-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-5065. - Resolution: Fixed > Use after free clearing HostDB. > --- > > Key: TS-5065 > URL: https://issues.apache.org/jira/browse/TS-5065 > Project: Traffic Server > Issue Type: Bug > Components: HostDB >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > ASAN points out that clearing the HostDB on startup results in a use after > free since we are iterating at the same time as we are freeing hash entries > (which contain the iterator links). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5066) HostDB serialization leaks on error path.
[ https://issues.apache.org/jira/browse/TS-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-5066. - Resolution: Fixed > HostDB serialization leaks on error path. > - > > Key: TS-5066 > URL: https://issues.apache.org/jira/browse/TS-5066 > Project: Traffic Server > Issue Type: Bug > Components: HostDB >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > > If the RefCountCacheSerializer hits an IO error, it leaks the copied cache > entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5066) HostDB serialization leaks on error path.
[ https://issues.apache.org/jira/browse/TS-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-5066: Assignee: James Peach Fix Version/s: 7.1.0 > HostDB serialization leaks on error path. > - > > Key: TS-5066 > URL: https://issues.apache.org/jira/browse/TS-5066 > Project: Traffic Server > Issue Type: Bug > Components: HostDB >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > > If the RefCountCacheSerializer hits an IO error, it leaks the copied cache > entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5065) Use after free clearing HostDB.
[ https://issues.apache.org/jira/browse/TS-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-5065: Assignee: James Peach Fix Version/s: 7.1.0 > Use after free clearing HostDB. > --- > > Key: TS-5065 > URL: https://issues.apache.org/jira/browse/TS-5065 > Project: Traffic Server > Issue Type: Bug > Components: HostDB >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > ASAN points out that clearing the HostDB on startup results in a use after > free since we are iterating at the same time as we are freeing hash entries > (which contain the iterator links). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5066) HostDB serialization leaks on error path.
James Peach created TS-5066: --- Summary: HostDB serialization leaks on error path. Key: TS-5066 URL: https://issues.apache.org/jira/browse/TS-5066 Project: Traffic Server Issue Type: Bug Components: HostDB Reporter: James Peach If the RefCountCacheSerializer hits an IO error, it leaks the copied cache entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5065) Use after free clearing HostDB.
James Peach created TS-5065: --- Summary: Use after free clearing HostDB. Key: TS-5065 URL: https://issues.apache.org/jira/browse/TS-5065 Project: Traffic Server Issue Type: Bug Components: HostDB Reporter: James Peach ASAN points out that clearing the HostDB on startup results in a use after free since we are iterating at the same time as we are freeing hash entries (which contain the iterator links). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5058) Broken HTTPS connect on forward proxy
[ https://issues.apache.org/jira/browse/TS-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-5058. - Resolution: Fixed > Broken HTTPS connect on forward proxy > - > > Key: TS-5058 > URL: https://issues.apache.org/jira/browse/TS-5058 > Project: Traffic Server > Issue Type: Bug > Components: Parent Proxy, TLS >Reporter: Craig B >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Commit cf58a91ccd3048f3f0a540463ad8609ae2ce1209 (TS-5040) broke forward > proxy connectivity to HTTPS sites. > Previous behaviour: ATS would create a TLS connection to origin server > Current behaviour: ATS issues a "CONNECT host:port" command (in the clear) to > the server, which is rejected by the server. > (Tested against commit 79ef0d5980b168c5d3292e180ba15f458fe5bea9 as one > example of "previous") > Both values for proxy.config.http.forward_connect_method (0 and 1) exhibit > this behaviour. > Using default configuration, plus forward proxy: > #https://docs.trafficserver.apache.org/records.config#url-remap-rules > # > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/remap.config.en.html > > ## > -CONFIG proxy.config.url_remap.remap_required INT 1 > +CONFIG proxy.config.url_remap.remap_required INT 0 > # > https://docs.trafficserver.apache.org/records.config#proxy-config-url-remap-pristine-host-hdr > CONFIG proxy.config.url_remap.pristine_host_hdr INT 0 > # https://docs.trafficserver.apache.org/records.config#reverse-proxy > -CONFIG proxy.config.reverse_proxy.enabled INT 1 > +CONFIG proxy.config.reverse_proxy.enabled INT 0 > Behaviour can be viewed by logging network traffic (tcpdump port 443). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5058) Broken HTTPS connect on forward proxy
[ https://issues.apache.org/jira/browse/TS-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-5058: Assignee: James Peach Fix Version/s: 7.1.0 Component/s: Parent Proxy > Broken HTTPS connect on forward proxy > - > > Key: TS-5058 > URL: https://issues.apache.org/jira/browse/TS-5058 > Project: Traffic Server > Issue Type: Bug > Components: Parent Proxy, TLS >Reporter: Craig B >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Commit cf58a91ccd3048f3f0a540463ad8609ae2ce1209 (TS-5040) broke forward > proxy connectivity to HTTPS sites. > Previous behaviour: ATS would create a TLS connection to origin server > Current behaviour: ATS issues a "CONNECT host:port" command (in the clear) to > the server, which is rejected by the server. > (Tested against commit 79ef0d5980b168c5d3292e180ba15f458fe5bea9 as one > example of "previous") > Both values for proxy.config.http.forward_connect_method (0 and 1) exhibit > this behaviour. > Using default configuration, plus forward proxy: > #https://docs.trafficserver.apache.org/records.config#url-remap-rules > # > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/remap.config.en.html > > ## > -CONFIG proxy.config.url_remap.remap_required INT 1 > +CONFIG proxy.config.url_remap.remap_required INT 0 > # > https://docs.trafficserver.apache.org/records.config#proxy-config-url-remap-pristine-host-hdr > CONFIG proxy.config.url_remap.pristine_host_hdr INT 0 > # https://docs.trafficserver.apache.org/records.config#reverse-proxy > -CONFIG proxy.config.reverse_proxy.enabled INT 1 > +CONFIG proxy.config.reverse_proxy.enabled INT 0 > Behaviour can be viewed by logging network traffic (tcpdump port 443). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TS-5039) Crash when connecting to downed parent.
[
https://issues.apache.org/jira/browse/TS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reopened TS-5039:
-
I was able to reproduce by sending a CONNECT method. Stack trace:
{noformat}
Thread 9 "[ET_NET 6]" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x728a0700 (LWP 17636)]
0x00516898 in Mutex_trylock (location=..., ahandler=0x0, m=0x0,
t=0x733b3010)
at /home/jpeach/src/trafficserver.git/iocore/eventsystem/I_Lock.h:289
289 if (m->thread_holding != t) {
(gdb)
(gdb) where
#0 0x00516898 in Mutex_trylock (location=..., ahandler=0x0, m=0x0,
t=0x733b3010)
at /home/jpeach/src/trafficserver.git/iocore/eventsystem/I_Lock.h:289
#1 0x00516c15 in MutexTryLock::MutexTryLock (this=0x7289fae0,
location=..., ahandler=0x0, am=...,
t=0x733b3010) at
/home/jpeach/src/trafficserver.git/iocore/eventsystem/I_Lock.h:555
#2 0x007e6a4f in read_from_net (nh=0x733b6cf0, vc=0x7fffa8017480,
thread=0x733b3010)
at UnixNetVConnection.cc:251
#3 0x007e9453 in UnixNetVConnection::net_read_io (this=0x7fffa8017480,
nh=0x733b6cf0,
lthread=0x733b3010) at UnixNetVConnection.cc:987
#4 0x007deba0 in NetHandler::mainNetEvent (this=0x733b6cf0,
event=5, e=0x11fe8e0) at UnixNet.cc:509
#5 0x00516d1a in Continuation::handleEvent (this=0x733b6cf0,
event=5, data=0x11fe8e0)
at
/home/jpeach/src/trafficserver.git/iocore/eventsystem/I_Continuation.h:153
#6 0x0080a4b0 in EThread::process_event (this=0x733b3010,
e=0x11fe8e0, calling_code=5)
at UnixEThread.cc:143
#7 0x0080aace in EThread::execute (this=0x733b3010) at
UnixEThread.cc:270
#8 0x00809aca in spawn_thread_internal (a=0x11887c0) at Thread.cc:84
#9 0x763d65ca in start_thread () from /lib64/libpthread.so.0
#10 0x756640ed in clone () from /lib64/libc.so.6
{noformat}
> Crash when connecting to downed parent.
> ---
>
> Key: TS-5039
> URL: https://issues.apache.org/jira/browse/TS-5039
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>
> If you configure a parent proxy on {{127.0.0.1:}} and never start the
> service, Traffic Server will crash when it fails to connect. Looks like this
> regression was introduced in TS-4796.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4956) Memory leaks in hostdb test
[
https://issues.apache.org/jira/browse/TS-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680073#comment-15680073
]
James Peach commented on TS-4956:
-
The PR is closed; is this done [~bcall]?
> 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)
[jira] [Commented] (TS-5058) Broken HTTPS connect on forward proxy
[ https://issues.apache.org/jira/browse/TS-5058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15677094#comment-15677094 ] James Peach commented on TS-5058: - Thanks [~craigba], I'll take a look over the weekend. > Broken HTTPS connect on forward proxy > - > > Key: TS-5058 > URL: https://issues.apache.org/jira/browse/TS-5058 > Project: Traffic Server > Issue Type: Bug > Components: TLS >Reporter: Craig B > > Commit cf58a91ccd3048f3f0a540463ad8609ae2ce1209 (TS-5040) broke forward > proxy connectivity to HTTPS sites. > Previous behaviour: ATS would create a TLS connection to origin server > Current behaviour: ATS issues a "CONNECT host:port" command (in the clear) to > the server, which is rejected by the server. > (Tested against commit 79ef0d5980b168c5d3292e180ba15f458fe5bea9 as one > example of "previous") > Both values for proxy.config.http.forward_connect_method (0 and 1) exhibit > this behaviour. > Using default configuration, plus forward proxy: > #https://docs.trafficserver.apache.org/records.config#url-remap-rules > # > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/remap.config.en.html > > ## > -CONFIG proxy.config.url_remap.remap_required INT 1 > +CONFIG proxy.config.url_remap.remap_required INT 0 > # > https://docs.trafficserver.apache.org/records.config#proxy-config-url-remap-pristine-host-hdr > CONFIG proxy.config.url_remap.pristine_host_hdr INT 0 > # https://docs.trafficserver.apache.org/records.config#reverse-proxy > -CONFIG proxy.config.reverse_proxy.enabled INT 1 > +CONFIG proxy.config.reverse_proxy.enabled INT 0 > Behaviour can be viewed by logging network traffic (tcpdump port 443). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4399.
-
Resolution: Fixed
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4400) TSProxyStateSet persist cache clearing across restart
[
https://issues.apache.org/jira/browse/TS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4400.
-
Resolution: Duplicate
Fixed as part of TS-4399.
> TSProxyStateSet persist cache clearing across restart
> -
>
> Key: TS-4400
> URL: https://issues.apache.org/jira/browse/TS-4400
> Project: Traffic Server
> Issue Type: Sub-task
> Components: Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> If you use {{TSProxyStateSet}} and and pass the options to clear the cache,
> these options are persisted so that subsequent restarts will also clear the
> cache. This seems pretty bad and likely to cause accidents. The options
> should be one-shot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5039) Crash when connecting to downed parent.
[
https://issues.apache.org/jira/browse/TS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15675911#comment-15675911
]
James Peach commented on TS-5039:
-
Well, I can't reproduce either :(
> Crash when connecting to downed parent.
> ---
>
> Key: TS-5039
> URL: https://issues.apache.org/jira/browse/TS-5039
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>
> If you configure a parent proxy on {{127.0.0.1:}} and never start the
> service, Traffic Server will crash when it fails to connect. Looks like this
> regression was introduced in TS-4796.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5056) Implement nonrecoverable error mechanism
[
https://issues.apache.org/jira/browse/TS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674115#comment-15674115
]
James Peach commented on TS-5056:
-
So you'd need to have {{Traffic Server}} do some detection of the frequency at
which is it crashing then exit with the special status. You could also enhance
{{traffic_crashlog}} to the point where you didn't need core dumps so much ;)
> Implement nonrecoverable error mechanism
>
>
> Key: TS-5056
> URL: https://issues.apache.org/jira/browse/TS-5056
> Project: Traffic Server
> Issue Type: Improvement
> Components: Manager
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There should be a mechanism for {{traffic_server}} to signal to
> {{traffic_manager}} that {{traffic_server}} cannot be recovered with any
> amount of restarting.
> For example, if TS sees a bad log file, then no amount of restarting will fix
> TS. Thus, it would be better for TM to just sit tight and wait for human
> intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (TS-5056) Implement nonrecoverable error mechanism
[
https://issues.apache.org/jira/browse/TS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-5056:
Comment: was deleted
(was: I'm struggling to think of any harm that can come from continuing to
restart even though it doesn't get any better. There are no calls to
{{Emergency()}} and the PR doesn't add any, so what is the use case for this?)
> Implement nonrecoverable error mechanism
>
>
> Key: TS-5056
> URL: https://issues.apache.org/jira/browse/TS-5056
> Project: Traffic Server
> Issue Type: Improvement
> Components: Manager
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There should be a mechanism for {{traffic_server}} to signal to
> {{traffic_manager}} that {{traffic_server}} cannot be recovered with any
> amount of restarting.
> For example, if TS sees a bad log file, then no amount of restarting will fix
> TS. Thus, it would be better for TM to just sit tight and wait for human
> intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5056) Implement nonrecoverable error mechanism
[
https://issues.apache.org/jira/browse/TS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673274#comment-15673274
]
James Peach commented on TS-5056:
-
I'm struggling to think of any harm that can come from continuing to restart
even though it doesn't get any better. There are no calls to {{Emergency()}}
and the PR doesn't add any, so what is the use case for this?
> Implement nonrecoverable error mechanism
>
>
> Key: TS-5056
> URL: https://issues.apache.org/jira/browse/TS-5056
> Project: Traffic Server
> Issue Type: Improvement
> Components: Manager
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There should be a mechanism for {{traffic_server}} to signal to
> {{traffic_manager}} that {{traffic_server}} cannot be recovered with any
> amount of restarting.
> For example, if TS sees a bad log file, then no amount of restarting will fix
> TS. Thus, it would be better for TM to just sit tight and wait for human
> intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5056) Implement nonrecoverable error mechanism
[
https://issues.apache.org/jira/browse/TS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15673273#comment-15673273
]
James Peach commented on TS-5056:
-
I'm struggling to think of any harm that can come from continuing to restart
even though it doesn't get any better. There are no calls to {{Emergency()}}
and the PR doesn't add any, so what is the use case for this?
> Implement nonrecoverable error mechanism
>
>
> Key: TS-5056
> URL: https://issues.apache.org/jira/browse/TS-5056
> Project: Traffic Server
> Issue Type: Improvement
> Components: Manager
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There should be a mechanism for {{traffic_server}} to signal to
> {{traffic_manager}} that {{traffic_server}} cannot be recovered with any
> amount of restarting.
> For example, if TS sees a bad log file, then no amount of restarting will fix
> TS. Thus, it would be better for TM to just sit tight and wait for human
> intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel=15673267#comment-15673267
]
James Peach commented on TS-5051:
-
You can already do this with {{logging.config}}. Just read the version from
{{trafficserver-release}}, the package version, or wherever else it might be
available and add it into the logging format.
> 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, Logging
>Reporter: Masa Sekimura
> Fix For: 7.1.0
>
>
> 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] [Commented] (TS-5039) Crash when connecting to downed parent.
[
https://issues.apache.org/jira/browse/TS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15671095#comment-15671095
]
James Peach commented on TS-5039:
-
I don't have the crash since I hit this on my linux box and that doesn't have
access to any accounts. IIRC I set the parent proxy to a closed port, so
`parent.config` something like this:
{noformat}
dest_domain=* parent=127.0.0.1:
{noformat}
> Crash when connecting to downed parent.
> ---
>
> Key: TS-5039
> URL: https://issues.apache.org/jira/browse/TS-5039
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>
> If you configure a parent proxy on {{127.0.0.1:}} and never start the
> service, Traffic Server will crash when it fails to connect. Looks like this
> regression was introduced in TS-4796.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5054) url_sig plugin loads configuration inconsistently
James Peach created TS-5054:
---
Summary: 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
{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] [Commented] (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:comment-tabpanel=15664549#comment-15664549
]
James Peach commented on TS-5053:
-
Seems reasonable to fix this, but plugins must not use {{ink_args.cc}}. It's
not a plugin API.
> 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
>
> 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] [Resolved] (TS-5040) Forward CONNECT methods without parent proxying.
[
https://issues.apache.org/jira/browse/TS-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-5040.
-
Resolution: Fixed
Fix Version/s: 7.1.0
> Forward CONNECT methods without parent proxying.
>
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the
> normal remap path cannot. Bring this capability to the remap state machine so
> that plugins can do the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5045) Add ws and wss scheme constants.
[ https://issues.apache.org/jira/browse/TS-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-5045. - Resolution: Fixed Fix Version/s: 7.1.0 > Add ws and wss scheme constants. > > > Key: TS-5045 > URL: https://issues.apache.org/jira/browse/TS-5045 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > We have well known strings for "ws" and "wss" schemes, but no TS API > constants. Let's add these for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write
[ https://issues.apache.org/jira/browse/TS-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-4872. - Resolution: Fixed > clang-analyzer: Memory leak LogObject.cc _checkout_write > > > Key: TS-4872 > URL: https://issues.apache.org/jira/browse/TS-4872 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: James Peach > Labels: clang-analyzer > Fix For: 7.1.0 > > Time Spent: 2h > Remaining Estimate: 0h > > We could not quite figure out why it reports this (smells almost like a bug > in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids > the warning, and cleans up the code overall. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4927) Coverity issues in passthru example plugin
[
https://issues.apache.org/jira/browse/TS-4927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4927.
-
Resolution: Fixed
> Coverity issues in passthru example plugin
> --
>
> Key: TS-4927
> URL: https://issues.apache.org/jira/browse/TS-4927
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.1.0
>
>
> {code}
> *** CID 1363659: Null pointer dereferences (REVERSE_INULL)
> /example/passthru/passthru.cc: 214 in PassthruSessionEvent(tsapi_cont *,
> TSEvent, void *)()
> 208
> 209 // Start the server end of the IO before we write any data.
> 210 sp->server.readio.read(sp->server.vconn, sp->contp);
> 211 sp->server.writeio.write(sp->server.vconn, sp->contp);
> 212 }
> 213
>CID 1363659: Null pointer dereferences (REVERSE_INULL)
>Null-checking "sp->server.vconn" suggests that it may be null, but it has
> already been dereferenced on all paths leading to the check.
> 214 if (sp->server.vconn != nullptr) {
> 215 int64_t nbytes;
> 216
> 217 nbytes = sp->client.readio.transfer_to(sp->server.writeio);
> 218 PassthruSessionDebug(sp, "proxied %" PRId64 " bytes from client
> vconn=%p to server vconn=%p", nbytes, sp->client.vconn,
> 219sp->server.vconn);
> ** CID 1363658: Incorrect expression (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *,
> tsapi_cont *)()
>
> *** CID 1363658: Incorrect expression (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *,
> tsapi_cont *)()
> 91 void
> 92 write(TSVConn vconn, TSCont contp)
> 93 {
> 94 TSReleaseAssert(this->vio == NULL);
> 95
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
>CID 1363658: Incorrect expression (ASSERT_SIDE_EFFECT)
>Assignment "this->reader = TSIOBufferReaderAlloc(this->iobuf)" has a side
> effect. This code will work differently in a non-debug build.
> 97 TSReleaseAssert((this->reader =
> TSIOBufferReaderAlloc(this->iobuf)));
> 98
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100 }
> 101
> 102 // Transfer data from this IO object to the target IO object.
> ** CID 1363657: Incorrect expression (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *,
> tsapi_cont *)()
>
> *** CID 1363657: Incorrect expression (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *,
> tsapi_cont *)()
> 78 // Start a read operation.
> 79 void
> 80 read(TSVConn vconn, TSCont contp)
> 81 {
> 82 TSReleaseAssert(this->vio == NULL);
> 83
>CID 1363657: Incorrect expression (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect. This
> code will work differently in a non-debug build.
> 84 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 85 TSReleaseAssert((this->reader =
> TSIOBufferReaderAlloc(this->iobuf)));
> 86
> 87 this->vio = TSVConnRead(vconn, contp, this->iobuf, INT64_MAX);
> 88 }
> 89
> ** CID 1363656: Incorrect expression (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *,
> tsapi_cont *)()
>
> *** CID 1363656: Incorrect expression (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *,
> tsapi_cont *)()
> 90 // Start a write operation.
> 91 void
> 92 write(TSVConn vconn, TSCont contp)
> 93 {
> 94 TSReleaseAssert(this->vio == NULL);
> 95
>CID 1363656: Incorrect expression (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect. This
> code will work differently in a non-debug build.
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 97 TSReleaseAssert((this->reader =
> TSIOBufferReaderAlloc(this->iobuf)));
> 98
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100 }
> 101
> ** CID 1363655: Incorrect expression (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 85 in PassthruIO::read(tsapi_cont *,
> tsapi_cont *)()
>
[jira] [Resolved] (TS-4840) Crash when reattaching to C++ API Stats.
[
https://issues.apache.org/jira/browse/TS-4840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4840.
-
Resolution: Fixed
> Crash when reattaching to C++ API Stats.
>
>
> Key: TS-4840
> URL: https://issues.apache.org/jira/browse/TS-4840
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API, Metrics
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> 0x007f733c in ink_atomic_swap (mem=0x0, value=1) at
> ../../lib/ts/ink_atomic.h:76
> 76 return __sync_lock_test_and_set(mem, value);
> (gdb) where
> #0 0x007f733c in ink_atomic_swap (mem=0x0, value=1) at
> ../../lib/ts/ink_atomic.h:76
> #1 0x007f6e56 in RecSetGlobalRawStatSum (rsb=0x2f16290, id=6,
> data=1) at RecRawStats.cc:482
> #2 0x005372c9 in TSStatIntSet (the_stat=6, value=1) at InkAPI.cc:6944
> #3 0x2ae6d3398bb1 in atscppapi::Stat::set (this=0x2ae6d37c2890 <...>,
> value=1) at Stat.cc:78
> #4 0x2ae6d35bb826 in TSPluginInit (argc=1, argv=0x7ffd0613bfe0) at
> /home/jpeach/n/cc:753
> #5 0x005550e5 in plugin_load (argc=1, argv=0x7ffd0613bfe0,
> validateOnly=false) at Plugin.cc:137
> {noformat}
> The change in TS-4793 regressed the C++ API Stat object. What happens is that
> if you restart {{traffic_server}} without {{traffic_manager}}, the
> {{TSStatFindName}} call finds the metric in the records hash table, but
> {{traffic_server}} has not set up the RSB entry so actually incrementing it
> crashes.
> If you call {{TSStatCreate}} twice for the same metric, you will end up with
> multiple RSB slots being consumed which is almost as bad.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5045) Add ws and wss scheme constants.
[ https://issues.apache.org/jira/browse/TS-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-5045: --- Assignee: James Peach > Add ws and wss scheme constants. > > > Key: TS-5045 > URL: https://issues.apache.org/jira/browse/TS-5045 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: James Peach >Assignee: James Peach > > We have well known strings for "ws" and "wss" schemes, but no TS API > constants. Let's add these for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5045) Add ws and wss scheme constants.
James Peach created TS-5045: --- Summary: Add ws and wss scheme constants. Key: TS-5045 URL: https://issues.apache.org/jira/browse/TS-5045 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: James Peach We have well known strings for "ws" and "wss" schemes, but no TS API constants. Let's add these for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5040) Forward CONNECT methods without parent proxying.
[
https://issues.apache.org/jira/browse/TS-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-5040:
---
Assignee: James Peach
> Forward CONNECT methods without parent proxying.
>
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>Assignee: James Peach
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the
> normal remap path cannot. Bring this capability to the remap state machine so
> that plugins can do the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5040) Forward CONNECT methods without parent proxying.
James Peach created TS-5040:
---
Summary: Forward CONNECT methods without parent proxying.
Key: TS-5040
URL: https://issues.apache.org/jira/browse/TS-5040
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, Core, Parent Proxy
Reporter: James Peach
Parent proxy can forward {{CONNECT}} method requests to the next hop, but the
normal remap path cannot. Bring this capability to the remap state machine so
that plugins can do the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5039) Crash when connecting to downed parent.
[
https://issues.apache.org/jira/browse/TS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-5039:
Priority: Blocker (was: Major)
> Crash when connecting to downed parent.
> ---
>
> Key: TS-5039
> URL: https://issues.apache.org/jira/browse/TS-5039
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: Thomas Jackson
>Priority: Blocker
>
> If you configure a parent proxy on {{127.0.0.1:}} and never start the
> service, Traffic Server will crash when it fails to connect. Looks like this
> regression was introduced in TS-4796.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5037) LogFormat object leak in log configuration.
[
https://issues.apache.org/jira/browse/TS-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-5037.
-
Resolution: Fixed
> LogFormat object leak in log configuration.
> ---
>
> Key: TS-5037
> URL: https://issues.apache.org/jira/browse/TS-5037
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We are leaking a {{LogFormat}} object in {{LogConfig::init()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5039) Crash when connecting to downed parent.
[
https://issues.apache.org/jira/browse/TS-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-5039:
Assignee: Thomas Jackson
> Crash when connecting to downed parent.
> ---
>
> Key: TS-5039
> URL: https://issues.apache.org/jira/browse/TS-5039
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: Thomas Jackson
>
> If you configure a parent proxy on {{127.0.0.1:}} and never start the
> service, Traffic Server will crash when it fails to connect. Looks like this
> regression was introduced in TS-4796.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5039) Crash when connecting to downed parent.
James Peach created TS-5039:
---
Summary: Crash when connecting to downed parent.
Key: TS-5039
URL: https://issues.apache.org/jira/browse/TS-5039
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
If you configure a parent proxy on {{127.0.0.1:}} and never start the
service, Traffic Server will crash when it fails to connect. Looks like this
regression was introduced in TS-4796.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5036) Can not use 'rdnetto/YCM-Generator` plugin of VIM to generate the correct .ycm_extra_conf.py.
[ https://issues.apache.org/jira/browse/TS-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-5036. - Resolution: Fixed Assignee: James Peach Fix Version/s: 7.1.0 > Can not use 'rdnetto/YCM-Generator` plugin of VIM to generate the correct > .ycm_extra_conf.py. > - > > Key: TS-5036 > URL: https://issues.apache.org/jira/browse/TS-5036 > Project: Traffic Server > Issue Type: Improvement >Reporter: YunWen >Assignee: James Peach >Priority: Minor > Fix For: 7.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Some VIMers wish to use YCM(http://valloric.github.io/YouCompleteMe/) to read > code, because the codebase is so large. But when using > YCM-Generator(https://github.com/rdnetto/YCM-Generator), the > .ycm_extra_conf.py will get many relative path, which causes it to fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5035) Some code file of plugin `background_fetch' has not be compiled.
[ https://issues.apache.org/jira/browse/TS-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-5035. - Resolution: Fixed Assignee: James Peach Fix Version/s: 7.1.0 > Some code file of plugin `background_fetch' has not be compiled. > > > Key: TS-5035 > URL: https://issues.apache.org/jira/browse/TS-5035 > Project: Traffic Server > Issue Type: Bug > Components: Build, Plugins >Reporter: YunWen >Assignee: James Peach >Priority: Minor > Fix For: 7.1.0 > > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5038) Integration tests for background_fetch.
James Peach created TS-5038: --- Summary: 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 Following on from TS-5035, integration tests would have caught this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5037) LogFormat object leak in log configuration.
James Peach created TS-5037:
---
Summary: LogFormat object leak in log configuration.
Key: TS-5037
URL: https://issues.apache.org/jira/browse/TS-5037
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: James Peach
We are leaking a {{LogFormat}} object in {{LogConfig::init()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5037) LogFormat object leak in log configuration.
[
https://issues.apache.org/jira/browse/TS-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-5037:
---
Assignee: James Peach
> LogFormat object leak in log configuration.
> ---
>
> Key: TS-5037
> URL: https://issues.apache.org/jira/browse/TS-5037
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>
> We are leaking a {{LogFormat}} object in {{LogConfig::init()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5027) Replace readdir_r with readdir.
[
https://issues.apache.org/jira/browse/TS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-5027.
-
Resolution: Fixed
Fix Version/s: 7.1.0
> 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
]
James Peach updated TS-5027:
Description:
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}
was:glibc deprecated {{readdir_r}} for reasons explained in the [man
page|http://man7.org/linux/man-pages/man3/readdir_r.3.html]
> 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
>
> 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] [Created] (TS-5027) Replace readdir_r with reader.
James Peach created TS-5027:
---
Summary: Replace readdir_r with reader.
Key: TS-5027
URL: https://issues.apache.org/jira/browse/TS-5027
Project: Traffic Server
Issue Type: Bug
Components: Cleanup, Core
Reporter: James Peach
glibc deprecated {{readdir_r}} for reasons explained in the [man
page|http://man7.org/linux/man-pages/man3/readdir_r.3.html]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5027) Replace readdir_r with readdir.
[
https://issues.apache.org/jira/browse/TS-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-5027:
---
Assignee: James Peach
> 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
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html]
--
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
]
James Peach updated TS-5027:
Summary: Replace readdir_r with readdir. (was: Replace readdir_r with
reader.)
> 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
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4977) Adopt nullptr
[
https://issues.apache.org/jira/browse/TS-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4977.
-
Resolution: Fixed
> Adopt nullptr
> -
>
> Key: TS-4977
> URL: https://issues.apache.org/jira/browse/TS-4977
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Adopt {{nullptr}} to replace {{NULL}} in all C++ files.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5020) Move ts_lua out of experimental
[ https://issues.apache.org/jira/browse/TS-5020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-5020: Component/s: (was: gins) > Move ts_lua out of experimental > --- > > Key: TS-5020 > URL: https://issues.apache.org/jira/browse/TS-5020 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Kit Chan >Assignee: Kit Chan > Fix For: 7.1.0 > > > From the 2016 Fall Summit, we agree to move ts_lua out of experimental -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4855) Make const char vs char const consistent in TS API
[ https://issues.apache.org/jira/browse/TS-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-4855. - Resolution: Fixed Assignee: David Calavera > Make const char vs char const consistent in TS API > -- > > Key: TS-4855 > URL: https://issues.apache.org/jira/browse/TS-4855 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Susan Hinrichs >Assignee: David Calavera > Fix For: 7.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Noted by [~jpe...@apache.org] while reviewing PR for TS-4703. We use both > "const char" and "char const" in the TS API prototypes. Should pick one and > be consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4858) Global session ticket key block leaks.
[ https://issues.apache.org/jira/browse/TS-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-4858. - Resolution: Fixed > Global session ticket key block leaks. > -- > > Key: TS-4858 > URL: https://issues.apache.org/jira/browse/TS-4858 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: James Peach >Assignee: Syeda Persia Aziz > Fix For: 7.1.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > From source inspection, ``global_default_keyblock`` is always assigned so it > will leak on configuration reload. > Have not reproduced this since I wasn't able to get SSL config reload to work > :-( -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4997) Move C++ API to plugins.
[
https://issues.apache.org/jira/browse/TS-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4997.
-
Resolution: Fixed
Fix Version/s: 7.1.0
> Move C++ API to plugins.
>
>
> Key: TS-4997
> URL: https://issues.apache.org/jira/browse/TS-4997
> Project: Traffic Server
> Issue Type: Task
> Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Move the C++ API to the {{plugins}} directory. Although the C++ API is a
> dependency of some plugins, it is itself a consumer of the TS plugin API, so
> the best place from a build ordering POV is {{plugins}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4998) Build plugins non-recursively.
[ https://issues.apache.org/jira/browse/TS-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-4998. - Resolution: Fixed Assignee: James Peach Fix Version/s: 7.1.0 > Build plugins non-recursively. > -- > > Key: TS-4998 > URL: https://issues.apache.org/jira/browse/TS-4998 > Project: Traffic Server > Issue Type: Bug > Components: Build, Plugins >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Build the top-level plugins non-recursively to remove build configuration > duplication and increase parallelism. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4998) Build plugins non-recursively.
James Peach created TS-4998: --- Summary: Build plugins non-recursively. Key: TS-4998 URL: https://issues.apache.org/jira/browse/TS-4998 Project: Traffic Server Issue Type: Bug Components: Build, Plugins Reporter: James Peach Build the top-level plugins non-recursively to remove build configuration duplication and increase parallelism. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4995) Consolidate C++ API example plugins.
[ https://issues.apache.org/jira/browse/TS-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-4995. - Resolution: Fixed Assignee: James Peach (was: Brian Geffon) Fix Version/s: 7.1.0 > Consolidate C++ API example plugins. > > > Key: TS-4995 > URL: https://issues.apache.org/jira/browse/TS-4995 > Project: Traffic Server > Issue Type: Bug > Components: CPP API, Plugins >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Move the C++ API examples to colocate them with the rest of the examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4997) Move C++ API to plugins.
[
https://issues.apache.org/jira/browse/TS-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-4997:
---
Assignee: James Peach (was: Brian Geffon)
> Move C++ API to plugins.
>
>
> Key: TS-4997
> URL: https://issues.apache.org/jira/browse/TS-4997
> Project: Traffic Server
> Issue Type: Task
> Components: CPP API
>Reporter: James Peach
>Assignee: James Peach
>
> Move the C++ API to the {{plugins}} directory. Although the C++ API is a
> dependency of some plugins, it is itself a consumer of the TS plugin API, so
> the best place from a build ordering POV is {{plugins}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4997) Move C++ API to plugins.
James Peach created TS-4997:
---
Summary: Move C++ API to plugins.
Key: TS-4997
URL: https://issues.apache.org/jira/browse/TS-4997
Project: Traffic Server
Issue Type: Task
Components: CPP API
Reporter: James Peach
Assignee: Brian Geffon
Move the C++ API to the {{plugins}} directory. Although the C++ API is a
dependency of some plugins, it is itself a consumer of the TS plugin API, so
the best place from a build ordering POV is {{plugins}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4996) Duplicate 'intercept' example plugins.
James Peach created TS-4996:
---
Summary: 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
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] [Created] (TS-4995) Consolidate C++ API example plugins.
James Peach created TS-4995: --- Summary: Consolidate C++ API example plugins. Key: TS-4995 URL: https://issues.apache.org/jira/browse/TS-4995 Project: Traffic Server Issue Type: Bug Components: CPP API, Plugins Reporter: James Peach Assignee: Brian Geffon Move the C++ API examples to colocate them with the rest of the examples. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4977) Adopt nullptr
James Peach created TS-4977:
---
Summary: Adopt nullptr
Key: TS-4977
URL: https://issues.apache.org/jira/browse/TS-4977
Project: Traffic Server
Issue Type: Bug
Components: Cleanup, Core
Reporter: James Peach
Adopt {{nullptr}} to replace {{NULL}} in all C++ files.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4963) Option to allow keepalive for PluginVC.
[ https://issues.apache.org/jira/browse/TS-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-4963. - Resolution: Fixed Assignee: James Peach Fix Version/s: 7.1.0 > Option to allow keepalive for PluginVC. > --- > > Key: TS-4963 > URL: https://issues.apache.org/jira/browse/TS-4963 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Core, Plugins >Reporter: James Peach >Assignee: James Peach > Fix For: 7.1.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Since it will take some time to explore and test a fix for TS-4960, add a > configuration knob to allow keepalive on internal connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4947) Collation Server is broken?
[
https://issues.apache.org/jira/browse/TS-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572503#comment-15572503
]
James Peach commented on TS-4947:
-
Can you check [this pull
request|https://github.com/apache/trafficserver/pull/1104]?
> 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.1.0
>
> Time Spent: 10m
> 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] [Commented] (TS-4964) max_unavailable_server_retries can't be 5
[ https://issues.apache.org/jira/browse/TS-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15570748#comment-15570748 ] James Peach commented on TS-4964: - Why limit to 5? > max_unavailable_server_retries can't be 5 > - > > Key: TS-4964 > URL: https://issues.apache.org/jira/browse/TS-4964 > Project: Traffic Server > Issue Type: Bug > Components: Parent Proxy >Reporter: Miles Libbey > > Don't know if this is a documentation bug or a code bug. > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/parent.config.en.html > says, > "By default the value for max_unavailable_server_retries is 1. It may be set > to any value in the range 1 to 5" > Testing with 6.2, when we set max_unavailable_server_retries=5, the setting > is ignored (used parent debug tag to see this). When set to <=4, the > max_unavailable_server_retries is set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4961) Plugin accept should use default thread counts.
[
https://issues.apache.org/jira/browse/TS-4961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4961.
-
Resolution: Fixed
Assignee: James Peach
Fix Version/s: 7.1.0
> Plugin accept should use default thread counts.
> ---
>
> Key: TS-4961
> URL: https://issues.apache.org/jira/browse/TS-4961
> Project: Traffic Server
> Issue Type: Bug
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{TSPortDescriptorAccept}} and {{TSPluginDescriptorAccept}} both explicity
> pass a 0 thread count to {{make_net_accept}}. Since there is no API for the
> plugin to specify what is needed (unlike {{TSNetAccept}}), the principle of
> least surprise would suggest we use the default config from
> {{proxy.config.accept_threads}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4955) Remove the global mutex from the plugin session acceptor
[
https://issues.apache.org/jira/browse/TS-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4955.
-
Resolution: Fixed
Assignee: James Peach
Fix Version/s: 7.1.0
> Remove the global mutex from the plugin session acceptor
>
>
> Key: TS-4955
> URL: https://issues.apache.org/jira/browse/TS-4955
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, Performance
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{plugin_http_accept}} has a global mutex which gets contended by protocol
> plugins. We don't require locking on {{HttpSessionAccept}} objects and the
> normal server port accept objects are not locked.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (TS-4963) Option to allow keepalive for PluginVC.
[ https://issues.apache.org/jira/browse/TS-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-4963: Comment: was deleted (was: cc [~shinrich] [~jacksontj]) > Option to allow keepalive for PluginVC. > --- > > Key: TS-4963 > URL: https://issues.apache.org/jira/browse/TS-4963 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Core, Plugins >Reporter: James Peach > > Since it will take some time to explore and test a fix for TS-4960, add a > configuration knob to allow keepalive on internal connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4963) Option to allow keepalive for PluginVC.
[ https://issues.apache.org/jira/browse/TS-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569860#comment-15569860 ] James Peach commented on TS-4963: - cc [~shinrich] [~jacksontj] > Option to allow keepalive for PluginVC. > --- > > Key: TS-4963 > URL: https://issues.apache.org/jira/browse/TS-4963 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Core, Plugins >Reporter: James Peach > > Since it will take some time to explore and test a fix for TS-4960, add a > configuration knob to allow keepalive on internal connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4963) Option to allow keepalive for PluginVC.
[ https://issues.apache.org/jira/browse/TS-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569861#comment-15569861 ] James Peach commented on TS-4963: - cc [~shinrich] [~jacksontj] > Option to allow keepalive for PluginVC. > --- > > Key: TS-4963 > URL: https://issues.apache.org/jira/browse/TS-4963 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Core, Plugins >Reporter: James Peach > > Since it will take some time to explore and test a fix for TS-4960, add a > configuration knob to allow keepalive on internal connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4963) Option to allow keepalive for PluginVC.
James Peach created TS-4963: --- Summary: Option to allow keepalive for PluginVC. Key: TS-4963 URL: https://issues.apache.org/jira/browse/TS-4963 Project: Traffic Server Issue Type: Improvement Components: Configuration, Core, Plugins Reporter: James Peach Since it will take some time to explore and test a fix for TS-4960, add a configuration knob to allow keepalive on internal connections. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4962) Restructure and simplify connection acceptance
James Peach created TS-4962:
---
Summary: Restructure and simplify connection acceptance
Key: TS-4962
URL: https://issues.apache.org/jira/browse/TS-4962
Project: Traffic Server
Issue Type: Improvement
Reporter: James Peach
The connection acceptance code {{NetAccept}}, etc. is overly complex and
contains a lot of variants that are not used. For example,
{{NetAccept::accept_fn}} is always a fixed value.
This should be cleaned up and restructured to make it simpler and easier to
follow. While we are at it, we can make some changes to improve accept
performance by {{dup}}ing the listen sockets or using {{SO_REUSEADDR}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4960) Undo internal request tunnelling hacks
[
https://issues.apache.org/jira/browse/TS-4960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569456#comment-15569456
]
James Peach commented on TS-4960:
-
AFAICT TS-3777 doesn't fix the underlying problem, which I expect is related to
the way PluginVC works. It looks to me like TS-3777 works around the lack of
event delivery probably caused by TS-3404?
> Undo internal request tunnelling hacks
> --
>
> Key: TS-4960
> URL: https://issues.apache.org/jira/browse/TS-4960
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>
> {noformat}
> proxy/http/HttpSM.cc:is_eligible_post_request &=
> !vc->get_is_internal_request();
> {noformat}
> {{HttpSM::tunnel_handler_ua}} does shenanigans based on whether this is an
> internal transaction or not. This is a complete hack. Internal transactions
> are no supposed to behave differently.
> AFAICT, this hack from TS-3404 led to TS-3777, which led to TS-4924, which
> makes it impossible for protocol plugins to use keepalive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4961) Plugin accept should use default thread counts.
James Peach created TS-4961:
---
Summary: Plugin accept should use default thread counts.
Key: TS-4961
URL: https://issues.apache.org/jira/browse/TS-4961
Project: Traffic Server
Issue Type: Bug
Reporter: James Peach
{{TSPortDescriptorAccept}} and {{TSPluginDescriptorAccept}} both explicity pass
a 0 thread count to {{make_net_accept}}. Since there is no API for the plugin
to specify what is needed (unlike {{TSNetAccept}}), the principle of least
surprise would suggest we use the default config from
{{proxy.config.accept_threads}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4960) Undo internal request tunnelling hacks
James Peach created TS-4960:
---
Summary: Undo internal request tunnelling hacks
Key: TS-4960
URL: https://issues.apache.org/jira/browse/TS-4960
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
{noformat}
proxy/http/HttpSM.cc:is_eligible_post_request &=
!vc->get_is_internal_request();
{noformat}
{{HttpSM::tunnel_handler_ua}} does shenanigans based on whether this is an
internal transaction or not. This is a complete hack. Internal transactions are
no supposed to behave differently.
AFAICT, this hack from TS-3404 led to TS-3777, which led to TS-4924, which
makes it impossible for protocol plugins to use keepalive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4924) Protocol plugin performance penalty
[
https://issues.apache.org/jira/browse/TS-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569267#comment-15569267
]
James Peach commented on TS-4924:
-
Keepalive was disabled for internal sessions in TS-3777.
> Protocol plugin performance penalty
> ---
>
> Key: TS-4924
> URL: https://issues.apache.org/jira/browse/TS-4924
> Project: Traffic Server
> Issue Type: Bug
> Components: Performance, Plugins
>Reporter: James Peach
> Fix For: sometime
>
>
> It looks like protocol plugins take a significant performance penalty
> compared to doing the same work in the code.
> *Configuratation:*
> {noformat}
> [root@fedora-23 ~]# cat /opt/ats/etc/trafficserver/remap.config
> map http://generator.jpeach.org/ http://127.0.0.1/ \
> @plugin=generator.so
> [root@fedora-23 ~]# cat /opt/ats/etc/trafficserver/plugin.config
> passthru.so
> [root@fedora-23 ~]# tail /opt/ats/etc/trafficserver/records.config
> ...
> CONFIG config.plugin.passthru.server_ports STRING 9090
> {noformat}
> *http_load:*
> {noformat}
> http://generator.jpeach.org/cache/1024/1934f6c8-2cd6-46ea-9077-0532528fb1c9
> [vagrant@fedora-23 ~]$ http_load -proxy 127.0.0.1:8080 -parallel 50 -seconds
> 20 -keep_alive 4 url.lst
> {noformat}
> We are using a generator URL of 1K that gets served from cache.
--
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
]
James Peach updated TS-4947:
Assignee: James Peach
Backport to Version: 7.0.0
Priority: Critical (was: Major)
> 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.1.0
>
>
> 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] [Commented] (TS-4947) Collation Server is broken?
[
https://issues.apache.org/jira/browse/TS-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569235#comment-15569235
]
James Peach commented on TS-4947:
-
[~bettydreamit] can you please try this patch:
{noformat}
diff --git a/proxy/logging/LogBindings.cc b/proxy/logging/LogBindings.cc
index ce263a1..cc83919 100644
--- a/proxy/logging/LogBindings.cc
+++ b/proxy/logging/LogBindings.cc
@@ -211,7 +211,10 @@ log_object_add_hosts(lua_State *L, LogObject *log, int
value, bool top)
lua_pop(L, 1); // Pop the element.
}
-log->add_loghost(lh, false /* take ownership */);
+if (lh) {
+ log->add_loghost(lh, false /* take ownership */);
+ return true;
+}
}
return false;
{noformat}
> 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
> Fix For: 7.1.0
>
>
> 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] [Commented] (TS-4958) Inconsistent advise flags on IO buffers
[
https://issues.apache.org/jira/browse/TS-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569149#comment-15569149
]
James Peach commented on TS-4958:
-
The latter. Freelists are only used for certain sizes, for example
{{IOBufferData::alloc}}.
> Inconsistent advise flags on IO buffers
> ---
>
> Key: TS-4958
> URL: https://issues.apache.org/jira/browse/TS-4958
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: Phil Sorber
> Fix For: sometime
>
>
> IO buffers from the free list will get {{madvise}} flags applied, but those
> from {{malloc}} don't. This probably contributes to memory region
> fragmentation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4924) Protocol plugin performance penalty
[
https://issues.apache.org/jira/browse/TS-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15569110#comment-15569110
]
James Peach commented on TS-4924:
-
See {{HttpTransact::initialize_state_variables_from_request}} where we always
disable keepalive for internal requests. This means that any protocol plugin
will have keepalive disabled. {{wrk}} is extremely aggressive about using
keepalive (always sends all requests on keepalive), so the non-protocol plugin
results are unrealistically high.
> Protocol plugin performance penalty
> ---
>
> Key: TS-4924
> URL: https://issues.apache.org/jira/browse/TS-4924
> Project: Traffic Server
> Issue Type: Bug
> Components: Performance, Plugins
>Reporter: James Peach
> Fix For: sometime
>
>
> It looks like protocol plugins take a significant performance penalty
> compared to doing the same work in the code.
> *Configuratation:*
> {noformat}
> [root@fedora-23 ~]# cat /opt/ats/etc/trafficserver/remap.config
> map http://generator.jpeach.org/ http://127.0.0.1/ \
> @plugin=generator.so
> [root@fedora-23 ~]# cat /opt/ats/etc/trafficserver/plugin.config
> passthru.so
> [root@fedora-23 ~]# tail /opt/ats/etc/trafficserver/records.config
> ...
> CONFIG config.plugin.passthru.server_ports STRING 9090
> {noformat}
> *http_load:*
> {noformat}
> http://generator.jpeach.org/cache/1024/1934f6c8-2cd6-46ea-9077-0532528fb1c9
> [vagrant@fedora-23 ~]$ http_load -proxy 127.0.0.1:8080 -parallel 50 -seconds
> 20 -keep_alive 4 url.lst
> {noformat}
> We are using a generator URL of 1K that gets served from cache.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4958) Inconsistent advise flags on IO buffers.
[
https://issues.apache.org/jira/browse/TS-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568873#comment-15568873
]
James Peach commented on TS-4958:
-
Ping [~jrushford] [~psudaemon]
> Inconsistent advise flags on IO buffers.
>
>
> Key: TS-4958
> URL: https://issues.apache.org/jira/browse/TS-4958
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>
> IO buffers from the free list will get {{madvise}} flags applied, but those
> from {{malloc}} don't. This probably contributes to memory region
> fragmentation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4958) Inconsistent advise flags on IO buffers.
James Peach created TS-4958:
---
Summary: Inconsistent advise flags on IO buffers.
Key: TS-4958
URL: https://issues.apache.org/jira/browse/TS-4958
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
IO buffers from the free list will get {{madvise}} flags applied, but those
from {{malloc}} don't. This probably contributes to memory region fragmentation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4957) Make the use of madvise() with MADV_DONTDUMP configurable.
[ https://issues.apache.org/jira/browse/TS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15566705#comment-15566705 ] James Peach commented on TS-4957: - This triggers a kernel problem right? Which kernel versions (approx) would need this? > Make the use of madvise() with MADV_DONTDUMP configurable. > -- > > Key: TS-4957 > URL: https://issues.apache.org/jira/browse/TS-4957 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: John Rushford >Assignee: John Rushford > > We have run into problems with ATS 5.3.x when using madvise() with the > MADV_DONTDUMP option to exclude IO buffers from core files. Under load, we > have seen high cpu loads and very slow time to serve times when allocating IO > buffers and marking them with this flag. We have had to disable calls to > madvise() in ats_madvise(), rebuild and redeploy to fix this problem. We'd > like to make the use of madvise() with the MADV_DONTDUMP option configurable. > The PR associated with this ticket uses a patch from TS-3417 that implements > making MADV_DONTDUMP configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4954) Use TSIOBufferCopy in the passthru example.
[
https://issues.apache.org/jira/browse/TS-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4954.
-
Resolution: Fixed
Assignee: James Peach
Fix Version/s: 7.1.0
> Use TSIOBufferCopy in the passthru example.
> ---
>
> Key: TS-4954
> URL: https://issues.apache.org/jira/browse/TS-4954
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The {{passthru.so}} example should yse {{TSIOBufferCopy}} to reduce the
> overhead of copying data and IO buffer usage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4955) Remove the global mutex from the plugin session acceptor.
James Peach created TS-4955:
---
Summary: Remove the global mutex from the plugin session acceptor.
Key: TS-4955
URL: https://issues.apache.org/jira/browse/TS-4955
Project: Traffic Server
Issue Type: Improvement
Components: Core, Performance
Reporter: James Peach
{{plugin_http_accept}} has a global mutex which gets contended by protocol
plugins. We don't require locking on {{HttpSessionAccept}} objects and the
normal server port accept objects are not locked.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4954) Use TSIOBufferCopy in the passthru example.
James Peach created TS-4954:
---
Summary: Use TSIOBufferCopy in the passthru example.
Key: TS-4954
URL: https://issues.apache.org/jira/browse/TS-4954
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: James Peach
The {{passthru.so}} example should yse {{TSIOBufferCopy}} to reduce the
overhead of copying data and IO buffer usage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4952) Improve mutex error checking.
James Peach created TS-4952:
---
Summary: Improve mutex error checking.
Key: TS-4952
URL: https://issues.apache.org/jira/browse/TS-4952
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
If any {{ink_mutex}} operations fail, we just abort. Use {{ink_abort}} so that
we can log an error if this happens.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4950) parent proxy test coverage
[ https://issues.apache.org/jira/browse/TS-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15565871#comment-15565871 ] James Peach commented on TS-4950: - ping [~jrushford] [~psudaemon] [~zwoop] > parent proxy test coverage > -- > > Key: TS-4950 > URL: https://issues.apache.org/jira/browse/TS-4950 > Project: Traffic Server > Issue Type: Bug > Components: Tests >Reporter: James Peach > > Currently, test coverage of the parent proxy subsystem is minimal. We need > additional coverage to guard against regressions like TS-4942. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4950) parent proxy test coverage
James Peach created TS-4950: --- Summary: parent proxy test coverage Key: TS-4950 URL: https://issues.apache.org/jira/browse/TS-4950 Project: Traffic Server Issue Type: Bug Components: Tests Reporter: James Peach Currently, test coverage of the parent proxy subsystem is minimal. We need additional coverage to guard against regressions like TS-4942. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4920) Consolidate accept socket options
[
https://issues.apache.org/jira/browse/TS-4920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4920.
-
Resolution: Fixed
> Consolidate accept socket options
> -
>
> Key: TS-4920
> URL: https://issues.apache.org/jira/browse/TS-4920
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have an object {{AcceptOptions}} that contains the options to apply to
> listening sockets, but in many places, the individual options are passed
> around. Consolidate this so that we pass a {{AcceptOptions}} to provide
> better guarantees that all listening sockets are created equal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4942) simple retry is not working correctly.
[ https://issues.apache.org/jira/browse/TS-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15556395#comment-15556395 ] James Peach commented on TS-4942: - [~jrushford] please file another jira for parent proxy integration tests. > simple retry is not working correctly. > -- > > Key: TS-4942 > URL: https://issues.apache.org/jira/browse/TS-4942 > Project: Traffic Server > Issue Type: Bug > Components: Parent Proxy >Reporter: John Rushford >Assignee: John Rushford > Time Spent: 1h 10m > Remaining Estimate: 0h > > While regression testing, I found that when enabling simple retry in > parent.config that a transaction would not retry the request when a 404 was > received from the parent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4940) header_rewrite in 6.2.0 doesn't expand variables properly
[
https://issues.apache.org/jira/browse/TS-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-4940:
Description:
We have a header_rewrite.config configured to add some headers for original
IP address of requestor.
{noformat}
cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip %
{noformat}
In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly
and for the header we get a literal %.
6.2.0: HTTP_X_BOX_ORIGINAL_IP=%
5.1.2: HTTP_X_BOX_ORIGINAL_IP=10.3.18.50
was:
We have a header_rewrite.config configured to add some headers for original
IP address of requestor.
cond %{SEND_REQUEST_HDR_HOOK}
rm-header X-Box-Original-Ip
add-header X-Box-Original-Ip %
In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly
and for the header we get a literal %.
6.2.0: HTTP_X_BOX_ORIGINAL_IP=%
5.1.2: HTTP_X_BOX_ORIGINAL_IP=10.3.18.50
> header_rewrite in 6.2.0 doesn't expand variables properly
> -
>
> Key: TS-4940
> URL: https://issues.apache.org/jira/browse/TS-4940
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Phillip Moore
>
> We have a header_rewrite.config configured to add some headers for original
> IP address of requestor.
> {noformat}
> cond %{SEND_REQUEST_HDR_HOOK}
> rm-header X-Box-Original-Ip
> add-header X-Box-Original-Ip %
> {noformat}
> In 5.1.2 this worked fine. With 6.2.0 the expansion is not happening properly
> and for the header we get a literal %.
> 6.2.0: HTTP_X_BOX_ORIGINAL_IP=%
> 5.1.2: HTTP_X_BOX_ORIGINAL_IP=10.3.18.50
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4939) Diags doesn't print the tag name anymore
[ https://issues.apache.org/jira/browse/TS-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-4939: Assignee: James Peach Fix Version/s: 7.1.0 > Diags doesn't print the tag name anymore > > > Key: TS-4939 > URL: https://issues.apache.org/jira/browse/TS-4939 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 7.0.0 >Reporter: Bryan Call >Assignee: James Peach > Fix For: 7.1.0 > > > Diags used to print the tag name in the output before. It looks like it was > broken in ec631b1feabf6684e0519fcd34d5ddc639f23b5a. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4925) Manager puking EBADF everywhere
[
https://issues.apache.org/jira/browse/TS-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-4925:
Backport to Version: 7.0.0
> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
> Issue Type: Bug
> Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> [Oct 3 20:19:53.824] Manager {0x7f7b699a2800} ERROR:
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4925) Manager puking EBADF everywhere
[
https://issues.apache.org/jira/browse/TS-4925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4925.
-
Resolution: Fixed
> Manager puking EBADF everywhere
> ---
>
> Key: TS-4925
> URL: https://issues.apache.org/jira/browse/TS-4925
> Project: Traffic Server
> Issue Type: Bug
> Components: Manager
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> [Oct 3 20:19:53.824] Manager {0x7f7b699a2800} ERROR:
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (9)
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
