[GitHub] trafficserver issue #1130: TS-4991 jtest should handle Range request
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1130 TS-4991 jtest should handle Range request Jtest will support random range by "--range_model 1" args. And it uses the dran48 to generate 2 numbers as the range boundary. Range size should be larger than 100 Bytes to contains the verified data(Although we do not verify this content ). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4991) jtest should handle Range request
[ https://issues.apache.org/jira/browse/TS-4991?focusedWorklogId=31027&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31027 ] ASF GitHub Bot logged work on TS-4991: -- Author: ASF GitHub Bot Created on: 25/Oct/16 08:58 Start Date: 25/Oct/16 08:58 Worklog Time Spent: 10m Work Description: Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1130 TS-4991 jtest should handle Range request Jtest will support random range by "--range_model 1" args. And it uses the dran48 to generate 2 numbers as the range boundary. Range size should be larger than 100 Bytes to contains the verified data(Although we do not verify this content ). Issue Time Tracking --- Worklog Id: (was: 31027) Time Spent: 20m (was: 10m) > jtest should handle Range request > - > > Key: TS-4991 > URL: https://issues.apache.org/jira/browse/TS-4991 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP, Tests, Tools >Reporter: Zhao Yongming >Assignee: song > Time Spent: 20m > Remaining Estimate: 0h > > jtest is not able to generate Range requests and handle Range requests, we > should make it > I'd like to see the SIMPLE "Range: bytes=100-200/1000" works first, then > maybe some other Range syntax oven multiple Range should be consider later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4994) PANIC: unprotected error in call to Lua API (not enough memory)
[
https://issues.apache.org/jira/browse/TS-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15604734#comment-15604734
]
Felicity Tarnell commented on TS-4994:
--
We've been running this on staging for 24 hours now without any problems, so it
looks like it's fixed it.
> PANIC: unprotected error in call to Lua API (not enough memory)
> ---
>
> Key: TS-4994
> URL: https://issues.apache.org/jira/browse/TS-4994
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>
> We have a working installation of TS 6.1; when upgrading to 6.2, it
> repeatedly crashes almost immediately after startup with:
> {noformat}
> PANIC: unprotected error in call to Lua API (not enough memory)
> pure virtual method called
> terminate called without an active exception
> traffic_server: using root directory '/opt/tbx'
> traffic_server: Aborted (Signal sent by tkill() 11964 33)
> traffic_server - STACK TRACE:
> /opt/tbx/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ac16e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b2c43b828d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2b2c44b52067]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b2c44b53448]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x15d)[0x2b2c4435bb3d]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ebb6)[0x2b2c44359bb6]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ec01)[0x2b2c44359c01]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f6cf)[0x2b2c4435a6cf]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept18do_blocking_acceptEP7EThread+0x99)[0x74dd69]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept15acceptLoopEventEiP5Event+0x2b)[0x74e62b]
> /opt/tbx/bin/traffic_server(_ZN7EThread7executeEv+0x7f)[0x77ce1f]
> /opt/tbx/bin/traffic_server[0x77c315]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b2c43b7b0a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b2c44c0587d]
> {noformat}
> We have about 5000 lines of Lua, and one C module (lualdap), but nothing that
> should be approaching Lua's memory limit; it's mostly just access checks that
> don't allocate any memory at all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #1133: TS-4993: Disables escaping and quotes insi...
Github user igalic commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1133#discussion_r84887560
--- Diff: plugins/header_rewrite/header_rewrite_test.cc ---
@@ -31,274 +33,395 @@ const char PLUGIN_NAME_DBG[] =
"TEST_dbg_header_rewrite";
extern "C" void
TSError(const char *fmt, ...)
{
- char buf[2048];
- int bytes = 0;
- va_list args;
- va_start(args, fmt);
- if ((bytes = vsnprintf(buf, sizeof(buf), fmt, args)) > 0) {
-fprintf(stderr, "TSError: %s: %.*s\n", PLUGIN_NAME, bytes, buf);
- }
- va_end(args);
--- End diff --
you may want to replace the functions content then with this ^ `/* comment
*/`
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Work logged] (TS-4993) backslash/escape removed from header_rewrite rule when unquoted
[
https://issues.apache.org/jira/browse/TS-4993?focusedWorklogId=31028&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31028
]
ASF GitHub Bot logged work on TS-4993:
--
Author: ASF GitHub Bot
Created on: 25/Oct/16 12:11
Start Date: 25/Oct/16 12:11
Worklog Time Spent: 10m
Work Description: Github user igalic commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1133#discussion_r84887560
--- Diff: plugins/header_rewrite/header_rewrite_test.cc ---
@@ -31,274 +33,395 @@ const char PLUGIN_NAME_DBG[] =
"TEST_dbg_header_rewrite";
extern "C" void
TSError(const char *fmt, ...)
{
- char buf[2048];
- int bytes = 0;
- va_list args;
- va_start(args, fmt);
- if ((bytes = vsnprintf(buf, sizeof(buf), fmt, args)) > 0) {
-fprintf(stderr, "TSError: %s: %.*s\n", PLUGIN_NAME, bytes, buf);
- }
- va_end(args);
--- End diff --
you may want to replace the functions content then with this ^ `/* comment
*/`
Issue Time Tracking
---
Worklog Id: (was: 31028)
Time Spent: 1h 50m (was: 1h 40m)
> backslash/escape removed from header_rewrite rule when unquoted
> ---
>
> Key: TS-4993
> URL: https://issues.apache.org/jira/browse/TS-4993
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 7.0.0
>Reporter: Randall Meyer
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Loading up a configuration with a header_rewrite rule of:
> {noformat}
> cond %{READ_RESPONSE_HDR_HOOK} [AND]
> cond %{PATH} /(\.html|\.js|\.png)(?:\?(.*))*$/ [AND]
> cond %{STATUS} >199 [AND]
> cond %{STATUS} <300
> set-header Cache-Control "max-age=31536000, public
> {noformat}
> results in an call to abort() in matcher.h under ATS 7.0.0. This worked fine
> under ATS 6.x (and probably 5.3.x)
> {noformat}
> (gdb) where
> #0 0x74f64625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x74f65e05 in *__GI_abort () at abort.c:92
> #2 0x7fffe71dd3ff in Matchers::setRegex
> (this=this@entry=0x7fffe5ac0f80) at matcher.h:98
> #3 0x7fffe71d7baa in Matchers::set (d=...,
> this=0x7fffe5ac0f80) at matcher.h:119
> #4 ConditionPath::initialize (this=0x7fffe59a6d00, p=...) at
> conditions.cc:260
> {noformat}
> The string comes to matcher with the escapes removed:
> {noformat}
> Adding condition: %{PATH} with arg: /(.html|.js|.png)(?:?(.*))*$/
> {noformat}
> If I add quotes around the regex, this regex is passed through correctly
> escaped.
> Not sure if this is expected behavior or not.
> This also seems related to TS-4797 and TS-4940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4640) Create ts_is_localhost() in lib/ts to unify "localhost" comparisons
[
https://issues.apache.org/jira/browse/TS-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605363#comment-15605363
]
Alan M. Carroll commented on TS-4640:
-
If it is an address, it should use the existing {{ats_is_ip_loopback}} which
works for both IPv4 and IPv6. I suppose we could overload that with {{const
char*}} and {{std::string const&}} to do the name / string comparisons.
> Create ts_is_localhost() in lib/ts to unify "localhost" comparisons
> ---
>
> Key: TS-4640
> URL: https://issues.apache.org/jira/browse/TS-4640
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Tyler Stroh
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> ATS currently has multiple places where a comparison of a host is made to
> localhost. We should create one function that does it and replace all the
> various implementations with this function.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4999) Enable control of plugin callback invocation and ordering by plugin piroritization.
Alan M. Carroll created TS-4999: --- Summary: Enable control of plugin callback invocation and ordering by plugin piroritization. Key: TS-4999 URL: https://issues.apache.org/jira/browse/TS-4999 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Alan M. Carroll Enable plugins to have priority values which affects both the order of plugin invocation on a hook and whether the plugin is invoked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4999) Enable control of plugin callback invocation and ordering by plugin piroritization.
[ https://issues.apache.org/jira/browse/TS-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4999: --- Assignee: Alan M. Carroll > Enable control of plugin callback invocation and ordering by plugin > piroritization. > --- > > Key: TS-4999 > URL: https://issues.apache.org/jira/browse/TS-4999 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > > Enable plugins to have priority values which affects both the order of plugin > invocation on a hook and whether the plugin is invoked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1133: TS-4993: Disables escaping and quotes inside rege...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1133 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/1075/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4993) backslash/escape removed from header_rewrite rule when unquoted
[
https://issues.apache.org/jira/browse/TS-4993?focusedWorklogId=31040&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31040
]
ASF GitHub Bot logged work on TS-4993:
--
Author: ASF GitHub Bot
Created on: 25/Oct/16 16:25
Start Date: 25/Oct/16 16:25
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/1133
FreeBSD build *successful*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1075/ for details.
Issue Time Tracking
---
Worklog Id: (was: 31040)
Time Spent: 2h (was: 1h 50m)
> backslash/escape removed from header_rewrite rule when unquoted
> ---
>
> Key: TS-4993
> URL: https://issues.apache.org/jira/browse/TS-4993
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 7.0.0
>Reporter: Randall Meyer
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Loading up a configuration with a header_rewrite rule of:
> {noformat}
> cond %{READ_RESPONSE_HDR_HOOK} [AND]
> cond %{PATH} /(\.html|\.js|\.png)(?:\?(.*))*$/ [AND]
> cond %{STATUS} >199 [AND]
> cond %{STATUS} <300
> set-header Cache-Control "max-age=31536000, public
> {noformat}
> results in an call to abort() in matcher.h under ATS 7.0.0. This worked fine
> under ATS 6.x (and probably 5.3.x)
> {noformat}
> (gdb) where
> #0 0x74f64625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x74f65e05 in *__GI_abort () at abort.c:92
> #2 0x7fffe71dd3ff in Matchers::setRegex
> (this=this@entry=0x7fffe5ac0f80) at matcher.h:98
> #3 0x7fffe71d7baa in Matchers::set (d=...,
> this=0x7fffe5ac0f80) at matcher.h:119
> #4 ConditionPath::initialize (this=0x7fffe59a6d00, p=...) at
> conditions.cc:260
> {noformat}
> The string comes to matcher with the escapes removed:
> {noformat}
> Adding condition: %{PATH} with arg: /(.html|.js|.png)(?:?(.*))*$/
> {noformat}
> If I add quotes around the regex, this regex is passed through correctly
> escaped.
> Not sure if this is expected behavior or not.
> This also seems related to TS-4797 and TS-4940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4993) backslash/escape removed from header_rewrite rule when unquoted
[
https://issues.apache.org/jira/browse/TS-4993?focusedWorklogId=31041&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31041
]
ASF GitHub Bot logged work on TS-4993:
--
Author: ASF GitHub Bot
Created on: 25/Oct/16 16:29
Start Date: 25/Oct/16 16:29
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/1133
Linux build *successful*! See
https://ci.trafficserver.apache.org/job/Github-Linux/967/ for details.
Issue Time Tracking
---
Worklog Id: (was: 31041)
Time Spent: 2h 10m (was: 2h)
> backslash/escape removed from header_rewrite rule when unquoted
> ---
>
> Key: TS-4993
> URL: https://issues.apache.org/jira/browse/TS-4993
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 7.0.0
>Reporter: Randall Meyer
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Loading up a configuration with a header_rewrite rule of:
> {noformat}
> cond %{READ_RESPONSE_HDR_HOOK} [AND]
> cond %{PATH} /(\.html|\.js|\.png)(?:\?(.*))*$/ [AND]
> cond %{STATUS} >199 [AND]
> cond %{STATUS} <300
> set-header Cache-Control "max-age=31536000, public
> {noformat}
> results in an call to abort() in matcher.h under ATS 7.0.0. This worked fine
> under ATS 6.x (and probably 5.3.x)
> {noformat}
> (gdb) where
> #0 0x74f64625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x74f65e05 in *__GI_abort () at abort.c:92
> #2 0x7fffe71dd3ff in Matchers::setRegex
> (this=this@entry=0x7fffe5ac0f80) at matcher.h:98
> #3 0x7fffe71d7baa in Matchers::set (d=...,
> this=0x7fffe5ac0f80) at matcher.h:119
> #4 ConditionPath::initialize (this=0x7fffe59a6d00, p=...) at
> conditions.cc:260
> {noformat}
> The string comes to matcher with the escapes removed:
> {noformat}
> Adding condition: %{PATH} with arg: /(.html|.js|.png)(?:?(.*))*$/
> {noformat}
> If I add quotes around the regex, this regex is passed through correctly
> escaped.
> Not sure if this is expected behavior or not.
> This also seems related to TS-4797 and TS-4940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1133: TS-4993: Disables escaping and quotes inside rege...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1133 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/967/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work started] (TS-4994) PANIC: unprotected error in call to Lua API (not enough memory)
[
https://issues.apache.org/jira/browse/TS-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-4994 started by Kit Chan.
> PANIC: unprotected error in call to Lua API (not enough memory)
> ---
>
> Key: TS-4994
> URL: https://issues.apache.org/jira/browse/TS-4994
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>
> We have a working installation of TS 6.1; when upgrading to 6.2, it
> repeatedly crashes almost immediately after startup with:
> {noformat}
> PANIC: unprotected error in call to Lua API (not enough memory)
> pure virtual method called
> terminate called without an active exception
> traffic_server: using root directory '/opt/tbx'
> traffic_server: Aborted (Signal sent by tkill() 11964 33)
> traffic_server - STACK TRACE:
> /opt/tbx/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ac16e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b2c43b828d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2b2c44b52067]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b2c44b53448]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x15d)[0x2b2c4435bb3d]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ebb6)[0x2b2c44359bb6]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ec01)[0x2b2c44359c01]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f6cf)[0x2b2c4435a6cf]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept18do_blocking_acceptEP7EThread+0x99)[0x74dd69]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept15acceptLoopEventEiP5Event+0x2b)[0x74e62b]
> /opt/tbx/bin/traffic_server(_ZN7EThread7executeEv+0x7f)[0x77ce1f]
> /opt/tbx/bin/traffic_server[0x77c315]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b2c43b7b0a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b2c44c0587d]
> {noformat}
> We have about 5000 lines of Lua, and one C module (lualdap), but nothing that
> should be approaching Lua's memory limit; it's mostly just access checks that
> don't allocate any memory at all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #1134: TS-4997: Move the C++ API to lib/cppapi.
Github user jpeach closed the pull request at: https://github.com/apache/trafficserver/pull/1134 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4997) Move C++ API to plugins.
[
https://issues.apache.org/jira/browse/TS-4997?focusedWorklogId=31049&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31049
]
ASF GitHub Bot logged work on TS-4997:
--
Author: ASF GitHub Bot
Created on: 25/Oct/16 18:43
Start Date: 25/Oct/16 18:43
Worklog Time Spent: 10m
Work Description: Github user jpeach closed the pull request at:
https://github.com/apache/trafficserver/pull/1134
Issue Time Tracking
---
Worklog Id: (was: 31049)
Time Spent: 2h (was: 1h 50m)
> 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
> 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-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] [Commented] (TS-4993) backslash/escape removed from header_rewrite rule when unquoted
[
https://issues.apache.org/jira/browse/TS-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606157#comment-15606157
]
Randall Meyer commented on TS-4993:
---
I've tested the patch locally, and it seems to fix this particular issue!
> backslash/escape removed from header_rewrite rule when unquoted
> ---
>
> Key: TS-4993
> URL: https://issues.apache.org/jira/browse/TS-4993
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 7.0.0
>Reporter: Randall Meyer
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Loading up a configuration with a header_rewrite rule of:
> {noformat}
> cond %{READ_RESPONSE_HDR_HOOK} [AND]
> cond %{PATH} /(\.html|\.js|\.png)(?:\?(.*))*$/ [AND]
> cond %{STATUS} >199 [AND]
> cond %{STATUS} <300
> set-header Cache-Control "max-age=31536000, public
> {noformat}
> results in an call to abort() in matcher.h under ATS 7.0.0. This worked fine
> under ATS 6.x (and probably 5.3.x)
> {noformat}
> (gdb) where
> #0 0x74f64625 in *__GI_raise (sig=) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x74f65e05 in *__GI_abort () at abort.c:92
> #2 0x7fffe71dd3ff in Matchers::setRegex
> (this=this@entry=0x7fffe5ac0f80) at matcher.h:98
> #3 0x7fffe71d7baa in Matchers::set (d=...,
> this=0x7fffe5ac0f80) at matcher.h:119
> #4 ConditionPath::initialize (this=0x7fffe59a6d00, p=...) at
> conditions.cc:260
> {noformat}
> The string comes to matcher with the escapes removed:
> {noformat}
> Adding condition: %{PATH} with arg: /(.html|.js|.png)(?:?(.*))*$/
> {noformat}
> If I add quotes around the regex, this regex is passed through correctly
> escaped.
> Not sure if this is expected behavior or not.
> This also seems related to TS-4797 and TS-4940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4796) ATS not closing origin connections on first RST from client
[
https://issues.apache.org/jira/browse/TS-4796?focusedWorklogId=31063&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31063
]
ASF GitHub Bot logged work on TS-4796:
--
Author: ASF GitHub Bot
Created on: 25/Oct/16 21:48
Start Date: 25/Oct/16 21:48
Worklog Time Spent: 10m
Work Description: Github user jacksontj commented on the issue:
https://github.com/apache/trafficserver/pull/947
After doing some testing with this patch, I see crashes where write_to_net
is being called with a null vc lock.
```
(gdb) list
416 }
417 while ((vc = write_ready_list.dequeue())) {
418 if (vc->closed)
419 close_UnixNetVConnection(vc, trigger_event->ethread);
420 else if ((vc->write.enabled && vc->write.triggered) ||
vc->write.error)
421 write_to_net(this, vc, trigger_event->ethread);
422 else if (!vc->write.enabled) {
423 write_ready_list.remove(vc);
```
Seems that vc->write.error forces write_to_net to be called, but nothing is
checking that the vc is non-null.
Specifically:
```
(gdb) p lock
$1 = {m = {m_ptr = 0x0}, lock_acquired = 157}
(gdb) list
382 write_to_net_io(NetHandler *nh, UnixNetVConnection *vc, EThread *thread)
383 {
384 NetState *s = &vc->write;
385 ProxyMutex *mutex = thread->mutex;
386
387 MUTEX_TRY_LOCK_FOR(lock, s->vio.mutex, thread, s->vio._cont); // <--
this line, specifically the s->vio.mutex
388
389 if (!lock.is_locked() || lock.get_mutex() != s->vio.mutex.m_ptr) {
390 write_reschedule(nh, vc);
391 return;
```
Issue Time Tracking
---
Worklog Id: (was: 31063)
Time Spent: 8h 50m (was: 8h 40m)
> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never
> closing*
> As a continuation of TS-4720, while testing that the session is closed when
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we
> should. In this client abort case we expect the client to abort, and ATS
> should initially continue to send bytes to the client-- as we are in the
> half-open state. After the first set of bytes are sent to the client-- the
> client will send an RST-- which should signal ATS to stop sending the request
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG: (state_watch_for_client_abort)> (http) [0]
> [&HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: (producer_handler)> (http_tunnel) [0] producer_handler [http server
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: (producer_handler)> (http_redirect) [HttpTunnel::producer_handler]
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG: (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather
> on the next set of bytes from the origin to send-- which end up tripping a
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event --
> which the HTTPTunnel consumer ignores completely. It seems then that when we
> recieve the WRITE_READY event we need to determine if we are already in the
> writing state-- and if so, then we should stop the transaction (since we are
> already edge-triggered).
--
This message was sent by Atlassian JIRA
[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...
Github user jacksontj commented on the issue:
https://github.com/apache/trafficserver/pull/947
After doing some testing with this patch, I see crashes where write_to_net
is being called with a null vc lock.
```
(gdb) list
416 }
417 while ((vc = write_ready_list.dequeue())) {
418 if (vc->closed)
419 close_UnixNetVConnection(vc, trigger_event->ethread);
420 else if ((vc->write.enabled && vc->write.triggered) ||
vc->write.error)
421 write_to_net(this, vc, trigger_event->ethread);
422 else if (!vc->write.enabled) {
423 write_ready_list.remove(vc);
```
Seems that vc->write.error forces write_to_net to be called, but nothing is
checking that the vc is non-null.
Specifically:
```
(gdb) p lock
$1 = {m = {m_ptr = 0x0}, lock_acquired = 157}
(gdb) list
382 write_to_net_io(NetHandler *nh, UnixNetVConnection *vc, EThread *thread)
383 {
384 NetState *s = &vc->write;
385 ProxyMutex *mutex = thread->mutex;
386
387 MUTEX_TRY_LOCK_FOR(lock, s->vio.mutex, thread, s->vio._cont); // <--
this line, specifically the s->vio.mutex
388
389 if (!lock.is_locked() || lock.get_mutex() != s->vio.mutex.m_ptr) {
390 write_reschedule(nh, vc);
391 return;
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Updated] (TS-3183) Clean up (and/or eliminate?) some proxy.node metrics
[ https://issues.apache.org/jira/browse/TS-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3183: --- Fix Version/s: (was: 7.1.0) 8.0.0 > Clean up (and/or eliminate?) some proxy.node metrics > > > Key: TS-3183 > URL: https://issues.apache.org/jira/browse/TS-3183 > Project: Traffic Server > Issue Type: Improvement > Components: Metrics >Reporter: Leif Hedstrom > Labels: incompatible > Fix For: 8.0.0 > > > There's two types of metrics it seems, proxy.node and proxy.process. > Unfortunately, in at least a few cases, the same metrics get duplicated into > both. I'm not sure why that makes sense, ever, so I think we should clean > that up. That would certainly make it less confusing. > Secondly, it seems proxy.node metrics, which are registered via > RecordsConfig.cc, are primarily used for computed metrics. These are metrics > synthesized via the stats.config.xml mechanism. Albeit being useful, what's > bad with the current design here is that adding new metrics to the XML config > file still requires a change to RecordsConfig.cc. This makes no sense to me, > so perhaps the proxy.node metrics should all be eliminated from > RecordsConfig.cc, and exclusively owned (registered and updated) via the XML > config format. > Elimination, or renaming, of any of these metrics would be an incompatible > change. Therefore, it would go into 6.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3399) Make a better default for proxy.config.proxy_name
[ https://issues.apache.org/jira/browse/TS-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3399: --- Fix Version/s: (was: 7.1.0) 8.0.0 > Make a better default for proxy.config.proxy_name > - > > Key: TS-3399 > URL: https://issues.apache.org/jira/browse/TS-3399 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: incompatible > Fix For: 8.0.0 > > > As of somewhere between 5.1.x and 5.2.x, we eliminated > proxy.config.proxy_name from records.config.in. It used to be set to the > build machine name, but now we default to the one in RecordsConfig.cc (which > is ). > I'd like to suggest we do one of two things (please voice your opinion): > 1) Restore the proxy.config.proxy_name into records.config.in, with the old > setting (@buildmachine@). > 2) Use the *hostname* from the Machine object. This is basically > gethostname(). > I think I prefer #2, but I'm also open for other suggestions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4826) Nuke deprecated TS APIs.
[
https://issues.apache.org/jira/browse/TS-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4826:
---
Fix Version/s: (was: 7.1.0)
8.0.0
> Nuke deprecated TS APIs.
>
>
> Key: TS-4826
> URL: https://issues.apache.org/jira/browse/TS-4826
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: James Peach
>Assignee: Bryan Call
> Labels: incompatible
> Fix For: 8.0.0
>
>
> Check {{ts..h}} for deprecated APIs that we should remove for 7.0.
> {{TSRedirectUrlSet}} and {{TSRedirectUrlGet}} at least.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3625) Some statistics not being gathered
[
https://issues.apache.org/jira/browse/TS-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-3625:
---
Fix Version/s: (was: 7.2.0)
8.0.0
> Some statistics not being gathered
> --
>
> Key: TS-3625
> URL: https://issues.apache.org/jira/browse/TS-3625
> Project: Traffic Server
> Issue Type: Bug
> Components: Metrics
>Reporter: Jon Sime
>Assignee: Bryan Call
> Labels: incompatible
> Fix For: 8.0.0
>
>
> The following statistics appear to not have any data collected for them in
> recent versions of TS, instead only emitting a zero value. The list was put
> together by examining the stats_over_http output on a production instance
> which receives enough varied traffic that it should, in theory at least,
> cause most implemented statistics to go non-zero.
> {code}
> proxy.node.cache.contents.num_docs
> proxy.node.cache_hit_mem_ratio_avg_10s_int_pct
> proxy.node.cache_hit_mem_ratio_int_pct
> proxy.node.current_cache_connections
> proxy.node.dns.lookup_avg_time_ms
> proxy.node.dns.lookups_per_second
> proxy.node.dns.total_dns_lookups
> proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct
> proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct
> proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct
> proxy.node.log.bytes_flush_to_disk
> proxy.node.log.bytes_lost_before_flush_to_disk
> proxy.node.log.bytes_lost_before_preproc
> proxy.node.log.bytes_lost_before_sent_to_network
> proxy.node.log.bytes_lost_before_written_to_disk
> proxy.node.log.bytes_received_from_network
> proxy.node.log.bytes_received_from_network_avg_10s
> proxy.node.log.bytes_sent_to_network
> proxy.node.log.bytes_sent_to_network_avg_10s
> proxy.node.log.bytes_written_to_disk
> proxy.node.log.event_log_access_aggr
> proxy.node.log.event_log_access_fail
> proxy.node.log.event_log_access_full
> proxy.node.log.event_log_access_ok
> proxy.node.log.event_log_access_skip
> proxy.node.log.event_log_error_aggr
> proxy.node.log.event_log_error_fail
> proxy.node.log.event_log_error_full
> proxy.node.log.event_log_error_ok
> proxy.node.log.event_log_error_skip
> proxy.node.log.num_flush_to_disk
> proxy.node.log.num_lost_before_flush_to_disk
> proxy.node.log.num_lost_before_sent_to_network
> proxy.node.log.num_received_from_network
> proxy.node.log.num_sent_to_network
> proxy.process.cache.directory_collision
> proxy.process.cache.evacuate.active
> proxy.process.cache.evacuate.failure
> proxy.process.cache.evacuate.success
> proxy.process.cache.frags_per_doc.1
> proxy.process.cache.frags_per_doc.2
> proxy.process.cache.frags_per_doc.3+
> proxy.process.cache.gc_bytes_evacuated
> proxy.process.cache.gc_frags_evacuated
> proxy.process.cache.hdr_marshal_bytes
> proxy.process.cache.hdr_marshals
> proxy.process.cache.lookup.active
> proxy.process.cache.lookup.failure
> proxy.process.cache.lookup.success
> proxy.process.cache.percent_full
> proxy.process.cache.pread_count
> proxy.process.cache.read_busy.failure
> proxy.process.cache.read_busy.success
> proxy.process.cache.remove.active
> proxy.process.cache.remove.failure
> proxy.process.cache.remove.success
> proxy.process.cache.scan.active
> proxy.process.cache.scan.failure
> proxy.process.cache.scan.success
> proxy.process.cache.volume_0.directory_collision
> proxy.process.cache.volume_0.evacuate.active
> proxy.process.cache.volume_0.evacuate.failure
> proxy.process.cache.volume_0.evacuate.success
> proxy.process.cache.volume_0.frags_per_doc.1
> proxy.process.cache.volume_0.frags_per_doc.2
> proxy.process.cache.volume_0.frags_per_doc.3+
> proxy.process.cache.volume_0.gc_bytes_evacuated
> proxy.process.cache.volume_0.gc_frags_evacuated
> proxy.process.cache.volume_0.hdr_marshal_bytes
> proxy.process.cache.volume_0.hdr_marshals
> proxy.process.cache.volume_0.lookup.active
> proxy.process.cache.volume_0.lookup.failure
> proxy.process.cache.volume_0.lookup.success
> proxy.process.cache.volume_0.pread_count
> proxy.process.cache.volume_0.remove.active
> proxy.process.cache.volume_0.remove.fa
[jira] [Updated] (TS-4167) Change default value of proxy.config.http2.active_timeout_in
[
https://issues.apache.org/jira/browse/TS-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4167:
---
Fix Version/s: (was: 7.1.0)
8.0.0
> Change default value of proxy.config.http2.active_timeout_in
>
>
> Key: TS-4167
> URL: https://issues.apache.org/jira/browse/TS-4167
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
> Labels: incompatible
> Fix For: 8.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {{proxy.config.http2.active_timeout_in}} is added by TS-4162. The default
> value is 0 for compatibility with existing 6.x code.
> We're going to choose suitable value and set it in 7.0.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4641) Change default for proxy.config.cache.hostdb.sync_frequency
[
https://issues.apache.org/jira/browse/TS-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4641:
---
Fix Version/s: (was: 7.1.0)
8.0.0
> Change default for proxy.config.cache.hostdb.sync_frequency
> ---
>
> Key: TS-4641
> URL: https://issues.apache.org/jira/browse/TS-4641
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Documentation, HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Labels: incompatible
> Fix For: 8.0.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I'd like to propose that we change this setting, to 0, which means disable
> HostDB Synchronization. This is an incompatible change, but nonetheless a
> step in the right direction away from persistent HostDB storage. People can
> of course still enable it.
> {code}
> diff --git a/mgmt/RecordsConfig.cc b/mgmt/RecordsConfig.cc
> index ed71b5c..7a7e1c7 100644
> --- a/mgmt/RecordsConfig.cc
> +++ b/mgmt/RecordsConfig.cc
> @@ -1078,7 +1078,7 @@ static const RecordElement RecordsConfig[] =
>{RECT_CONFIG, "proxy.config.hostdb.timed_round_robin", RECD_INT, "0",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
>// # how often should the hostdb be synced (seconds)
> - {RECT_CONFIG, "proxy.config.cache.hostdb.sync_frequency", RECD_INT, "120",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> + {RECT_CONFIG, "proxy.config.cache.hostdb.sync_frequency", RECD_INT, "0",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
>{RECT_CONFIG, "proxy.config.hostdb.host_file.path", RECD_STRING, NULL,
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
> {code}
> Note that changing it to 0, or changing it from 0 to something else,
> requires restart. It's only "dynamic" if it it's not 0 (which turns off the
> sync cont).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5000) Change experimental plugins to use the new Makefile includes
Leif Hedstrom created TS-5000: - Summary: Change experimental plugins to use the new Makefile includes Key: TS-5000 URL: https://issues.apache.org/jira/browse/TS-5000 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Leif Hedstrom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5000) Change experimental plugins to use the new Makefile includes
[ https://issues.apache.org/jira/browse/TS-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-5000: - Assignee: Leif Hedstrom > Change experimental plugins to use the new Makefile includes > > > Key: TS-5000 > URL: https://issues.apache.org/jira/browse/TS-5000 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5000) Change experimental plugins to use the new Makefile include mechanism
[ https://issues.apache.org/jira/browse/TS-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-5000: -- Fix Version/s: 7.1.0 > Change experimental plugins to use the new Makefile include mechanism > - > > Key: TS-5000 > URL: https://issues.apache.org/jira/browse/TS-5000 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5000) Change experimental plugins to use the new Makefile include mechanism
[ https://issues.apache.org/jira/browse/TS-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-5000: -- Summary: Change experimental plugins to use the new Makefile include mechanism (was: Change experimental plugins to use the new Makefile includes) > Change experimental plugins to use the new Makefile include mechanism > - > > Key: TS-5000 > URL: https://issues.apache.org/jira/browse/TS-5000 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5001) Rename ts_lua/tslua to just lua (plugin)
[ https://issues.apache.org/jira/browse/TS-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-5001: -- Fix Version/s: 8.0.0 > Rename ts_lua/tslua to just lua (plugin) > > > Key: TS-5001 > URL: https://issues.apache.org/jira/browse/TS-5001 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Leif Hedstrom > Fix For: 8.0.0 > > > I find it rather confusing that we are naming the Lua plugin talus.so, while > the tree in the source is ts_lua. I think we should just rename this to "lua" > consistently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5001) Rename ts_lua/tslua to just lua (plugin)
[ https://issues.apache.org/jira/browse/TS-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-5001: - Assignee: Leif Hedstrom > Rename ts_lua/tslua to just lua (plugin) > > > Key: TS-5001 > URL: https://issues.apache.org/jira/browse/TS-5001 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 8.0.0 > > > I find it rather confusing that we are naming the Lua plugin talus.so, while > the tree in the source is ts_lua. I think we should just rename this to "lua" > consistently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5001) Rename ts_lua/tslua to just lua (plugin)
Leif Hedstrom created TS-5001: - Summary: Rename ts_lua/tslua to just lua (plugin) Key: TS-5001 URL: https://issues.apache.org/jira/browse/TS-5001 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Leif Hedstrom I find it rather confusing that we are naming the Lua plugin talus.so, while the tree in the source is ts_lua. I think we should just rename this to "lua" consistently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5000) Change experimental plugins to use the new Makefile include mechanism
[ https://issues.apache.org/jira/browse/TS-5000?focusedWorklogId=31073&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31073 ] ASF GitHub Bot logged work on TS-5000: -- Author: ASF GitHub Bot Created on: 26/Oct/16 06:10 Start Date: 26/Oct/16 06:10 Worklog Time Spent: 10m Work Description: GitHub user zwoop opened a pull request: https://github.com/apache/trafficserver/pull/1136 TS-5000: Moves experimental plugins to the new include mechanism You can merge this pull request into a Git repository by running: $ git pull https://github.com/zwoop/trafficserver TS-5000 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1136.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1136 commit e77ea8ee6228df3925f40ff160f56055a00697a3 Author: Leif Hedstrom Date: 2016-10-26T04:22:27Z TS-5000: Moves experimental plugins to the new include mechanism Issue Time Tracking --- Worklog Id: (was: 31073) Time Spent: 10m Remaining Estimate: 0h > Change experimental plugins to use the new Makefile include mechanism > - > > Key: TS-5000 > URL: https://issues.apache.org/jira/browse/TS-5000 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #1136: TS-5000: Moves experimental plugins to the...
GitHub user zwoop opened a pull request: https://github.com/apache/trafficserver/pull/1136 TS-5000: Moves experimental plugins to the new include mechanism You can merge this pull request into a Git repository by running: $ git pull https://github.com/zwoop/trafficserver TS-5000 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1136.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1136 commit e77ea8ee6228df3925f40ff160f56055a00697a3 Author: Leif Hedstrom Date: 2016-10-26T04:22:27Z TS-5000: Moves experimental plugins to the new include mechanism --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1136: TS-5000: Moves experimental plugins to the new in...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1136 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/1076/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-5000) Change experimental plugins to use the new Makefile include mechanism
[ https://issues.apache.org/jira/browse/TS-5000?focusedWorklogId=31074&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31074 ] ASF GitHub Bot logged work on TS-5000: -- Author: ASF GitHub Bot Created on: 26/Oct/16 06:20 Start Date: 26/Oct/16 06:20 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1136 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/1076/ for details. Issue Time Tracking --- Worklog Id: (was: 31074) Time Spent: 20m (was: 10m) > Change experimental plugins to use the new Makefile include mechanism > - > > Key: TS-5000 > URL: https://issues.apache.org/jira/browse/TS-5000 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1136: TS-5000: Moves experimental plugins to the new in...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1136 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/968/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-5000) Change experimental plugins to use the new Makefile include mechanism
[ https://issues.apache.org/jira/browse/TS-5000?focusedWorklogId=31075&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31075 ] ASF GitHub Bot logged work on TS-5000: -- Author: ASF GitHub Bot Created on: 26/Oct/16 06:23 Start Date: 26/Oct/16 06:23 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1136 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/968/ for details. Issue Time Tracking --- Worklog Id: (was: 31075) Time Spent: 0.5h (was: 20m) > Change experimental plugins to use the new Makefile include mechanism > - > > Key: TS-5000 > URL: https://issues.apache.org/jira/browse/TS-5000 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
