[jira] [Work logged] (TS-4775) Better cache error debugging.
[
https://issues.apache.org/jira/browse/TS-4775?focusedWorklogId=26864&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26864
]
ASF GitHub Bot logged work on TS-4775:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 05:48
Start Date: 23/Aug/16 05:48
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/904
Linux build *successful*! See
https://ci.trafficserver.apache.org/job/Github-Linux/483/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26864)
Time Spent: 0.5h (was: 20m)
> Better cache error debugging.
> -
>
> Key: TS-4775
> URL: https://issues.apache.org/jira/browse/TS-4775
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In {{HttpSM::state_cache_open_read}} log a better error when a cache read
> fails.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #904: TS-4775: Log a better debug error when a cache ope...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/904 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/483/ 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-4775) Better cache error debugging.
[
https://issues.apache.org/jira/browse/TS-4775?focusedWorklogId=26863&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26863
]
ASF GitHub Bot logged work on TS-4775:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 05:44
Start Date: 23/Aug/16 05:44
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/904
FreeBSD build *successful*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/587/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26863)
Time Spent: 20m (was: 10m)
> Better cache error debugging.
> -
>
> Key: TS-4775
> URL: https://issues.apache.org/jira/browse/TS-4775
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In {{HttpSM::state_cache_open_read}} log a better error when a cache read
> fails.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #904: TS-4775: Log a better debug error when a cache ope...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/904 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/587/ 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-4775) Better cache error debugging.
[
https://issues.apache.org/jira/browse/TS-4775?focusedWorklogId=26862&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26862
]
ASF GitHub Bot logged work on TS-4775:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 05:34
Start Date: 23/Aug/16 05:34
Worklog Time Spent: 10m
Work Description: GitHub user jpeach opened a pull request:
https://github.com/apache/trafficserver/pull/904
TS-4775: Log a better debug error when a cache open fails.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jpeach/trafficserver fix/4775
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/904.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 #904
commit 85401c8813c70b310c2c3a7935ed3a72e52fe8ae
Author: James Peach
Date: 2016-08-23T05:33:01Z
TS-4775: Log a better debug error when a cache open fails.
Issue Time Tracking
---
Worklog Id: (was: 26862)
Time Spent: 10m
Remaining Estimate: 0h
> Better cache error debugging.
> -
>
> Key: TS-4775
> URL: https://issues.apache.org/jira/browse/TS-4775
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In {{HttpSM::state_cache_open_read}} log a better error when a cache read
> fails.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #904: TS-4775: Log a better debug error when a ca...
GitHub user jpeach opened a pull request: https://github.com/apache/trafficserver/pull/904 TS-4775: Log a better debug error when a cache open fails. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jpeach/trafficserver fix/4775 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/904.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 #904 commit 85401c8813c70b310c2c3a7935ed3a72e52fe8ae Author: James Peach Date: 2016-08-23T05:33:01Z TS-4775: Log a better debug error when a cache open fails. --- 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] [Created] (TS-4775) Better cache error debugging.
James Peach created TS-4775:
---
Summary: Better cache error debugging.
Key: TS-4775
URL: https://issues.apache.org/jira/browse/TS-4775
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
In {{HttpSM::state_cache_open_read}} log a better error when a cache read fails.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4774) proxy.config.http.cache.open_write_fail_action=2 doesn't work
[
https://issues.apache.org/jira/browse/TS-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432123#comment-15432123
]
James Peach commented on TS-4774:
-
Ping [~sudheerv] [~amc] [~zwoop]
> proxy.config.http.cache.open_write_fail_action=2 doesn't work
> -
>
> Key: TS-4774
> URL: https://issues.apache.org/jira/browse/TS-4774
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>
> If you set {{proxy.config.http.cache.open_write_fail_action=2}} there is no
> change of behaviour.
> If you just do a {{GET}} on a stale object, the root cause of this is that
> {{OverridableHttpConfigParams::cache_open_write_fail_action}} is never copied
> to {{HttpTransact::State::cache_open_write_fail_action}} when this is
> checked. If you fix this, then it always returns a stale object without
> revalidating.
> If you cause the object to be locked in the cache by doing a {{GET}} that
> takes a long time to return, a second lookup goes direct to origin and the
> {{cache_open_write_fail_action}} is never checked.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4774) proxy.config.http.cache.open_write_fail_action=2 doesn't work
James Peach created TS-4774:
---
Summary: proxy.config.http.cache.open_write_fail_action=2 doesn't
work
Key: TS-4774
URL: https://issues.apache.org/jira/browse/TS-4774
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
If you set {{proxy.config.http.cache.open_write_fail_action=2}} there is no
change of behaviour.
If you just do a {{GET}} on a stale object, the root cause of this is that
{{OverridableHttpConfigParams::cache_open_write_fail_action}} is never copied
to {{HttpTransact::State::cache_open_write_fail_action}} when this is checked.
If you fix this, then it always returns a stale object without revalidating.
If you cause the object to be locked in the cache by doing a {{GET}} that takes
a long time to return, a second lookup goes direct to origin and the
{{cache_open_write_fail_action}} is never checked.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4738) Document Lua logging configuration
[
https://issues.apache.org/jira/browse/TS-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-4738:
Fix Version/s: 7.0.0
> Document Lua logging configuration
> --
>
> Key: TS-4738
> URL: https://issues.apache.org/jira/browse/TS-4738
> Project: Traffic Server
> Issue Type: Improvement
> Components: Documentation
>Reporter: James Peach
>Assignee: Jon Sime
> Fix For: 7.0.0, Docs
>
>
> Update the logging documentation to document {{logging.config}} and remove
> the XML logging config documentation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4737) Remove XML log configuration
[ https://issues.apache.org/jira/browse/TS-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-4737. - Resolution: Fixed > Remove XML log configuration > > > Key: TS-4737 > URL: https://issues.apache.org/jira/browse/TS-4737 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: James Peach >Assignee: James Peach > Labels: compatibility > Fix For: 7.0.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Remove all the XML log configuration code. Remove XML library dependencies. > Clean up and relevant LogConfig code that is not needed any more (eg, the > filters map, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4737) Remove XML log configuration
[ https://issues.apache.org/jira/browse/TS-4737?focusedWorklogId=26861&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26861 ] ASF GitHub Bot logged work on TS-4737: -- Author: ASF GitHub Bot Created on: 23/Aug/16 04:01 Start Date: 23/Aug/16 04:01 Worklog Time Spent: 10m Work Description: Github user jpeach closed the pull request at: https://github.com/apache/trafficserver/pull/884 Issue Time Tracking --- Worklog Id: (was: 26861) Time Spent: 2h (was: 1h 50m) > Remove XML log configuration > > > Key: TS-4737 > URL: https://issues.apache.org/jira/browse/TS-4737 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: James Peach >Assignee: James Peach > Labels: compatibility > Fix For: 7.0.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Remove all the XML log configuration code. Remove XML library dependencies. > Clean up and relevant LogConfig code that is not needed any more (eg, the > filters map, etc). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #884: TS-4737: Remove XML log configuration.
Github user jpeach closed the pull request at: https://github.com/apache/trafficserver/pull/884 --- 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] [Resolved] (TS-4773) AM_EXTRA_RECURSIVE_TARGETS not available in CentOS automake
[
https://issues.apache.org/jira/browse/TS-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-4773.
-
Resolution: Fixed
Assignee: James Peach
Fixed in cc82eec78c14dbe993c66d91f0901b9f373a80bf.
> AM_EXTRA_RECURSIVE_TARGETS not available in CentOS automake
> ---
>
> Key: TS-4773
> URL: https://issues.apache.org/jira/browse/TS-4773
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 7.0.0
>Reporter: Steven Feltner
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Trying to build master branch on CentOS 6.7 - while doing
> {code:}
> autoreconf -if
> {code}
> I received the error {{configure.ac:52: warning: macro
> `AM_EXTRA_RECURSIVE_TARGETS' not found in library}}
> The AM_EXTRA_RECURSIVE_TARGETS macro was introduced into automake 1.13.
> CentOS only has version 1.11 through normal channels. There is not a newer
> version available in either devtoolset-3 or devtoolset-4. A newer version
> can be downloaded and compiled, but that is not a standard package.
> @jpeach suggested:
> {code:}
> diff --git a/configure.ac b/configure.ac
> index 7e4adf6..5878756 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -49,7 +49,7 @@ AM_INIT_AUTOMAKE([-Wall -Werror -Wno-portability tar-ustar
> foreign no-installinf
> AM_MAINTAINER_MODE([enable])
>
> # Enable a recursive "tidy" rule for clang-tidy.
> -AM_EXTRA_RECURSIVE_TARGETS([tidy])
> +m4_ifdef([AM_EXTRA_RECURSIVE_TARGETS], [AM_EXTRA_RECURSIVE_TARGETS([tidy]])
>
> AC_CONFIG_HEADERS([lib/ink_autoconf.h])
>
> {code}
> as a temporary workaround. This change allowed autoreconf and configure to
> complete successfully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4773) AM_EXTRA_RECURSIVE_TARGETS not available in CentOS automake
[
https://issues.apache.org/jira/browse/TS-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Feltner updated TS-4773:
---
Affects Version/s: 7.0.0
Fix Version/s: 7.0.0
> AM_EXTRA_RECURSIVE_TARGETS not available in CentOS automake
> ---
>
> Key: TS-4773
> URL: https://issues.apache.org/jira/browse/TS-4773
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 7.0.0
>Reporter: Steven Feltner
> Fix For: 7.0.0
>
>
> Trying to build master branch on CentOS 6.7 - while doing
> {code:}
> autoreconf -if
> {code}
> I received the error {{configure.ac:52: warning: macro
> `AM_EXTRA_RECURSIVE_TARGETS' not found in library}}
> The AM_EXTRA_RECURSIVE_TARGETS macro was introduced into automake 1.13.
> CentOS only has version 1.11 through normal channels. There is not a newer
> version available in either devtoolset-3 or devtoolset-4. A newer version
> can be downloaded and compiled, but that is not a standard package.
> @jpeach suggested:
> {code:}
> diff --git a/configure.ac b/configure.ac
> index 7e4adf6..5878756 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -49,7 +49,7 @@ AM_INIT_AUTOMAKE([-Wall -Werror -Wno-portability tar-ustar
> foreign no-installinf
> AM_MAINTAINER_MODE([enable])
>
> # Enable a recursive "tidy" rule for clang-tidy.
> -AM_EXTRA_RECURSIVE_TARGETS([tidy])
> +m4_ifdef([AM_EXTRA_RECURSIVE_TARGETS], [AM_EXTRA_RECURSIVE_TARGETS([tidy]])
>
> AC_CONFIG_HEADERS([lib/ink_autoconf.h])
>
> {code}
> as a temporary workaround. This change allowed autoreconf and configure to
> complete successfully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4773) AM_EXTRA_RECURSIVE_TARGETS not available in CentOS automake
Steven Feltner created TS-4773:
--
Summary: AM_EXTRA_RECURSIVE_TARGETS not available in CentOS
automake
Key: TS-4773
URL: https://issues.apache.org/jira/browse/TS-4773
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Steven Feltner
Trying to build master branch on CentOS 6.7 - while doing
{code:}
autoreconf -if
{code}
I received the error {{configure.ac:52: warning: macro
`AM_EXTRA_RECURSIVE_TARGETS' not found in library}}
The AM_EXTRA_RECURSIVE_TARGETS macro was introduced into automake 1.13. CentOS
only has version 1.11 through normal channels. There is not a newer version
available in either devtoolset-3 or devtoolset-4. A newer version can be
downloaded and compiled, but that is not a standard package.
@jpeach suggested:
{code:}
diff --git a/configure.ac b/configure.ac
index 7e4adf6..5878756 100644
--- a/configure.ac
+++ b/configure.ac
@@ -49,7 +49,7 @@ AM_INIT_AUTOMAKE([-Wall -Werror -Wno-portability tar-ustar
foreign no-installinf
AM_MAINTAINER_MODE([enable])
# Enable a recursive "tidy" rule for clang-tidy.
-AM_EXTRA_RECURSIVE_TARGETS([tidy])
+m4_ifdef([AM_EXTRA_RECURSIVE_TARGETS], [AM_EXTRA_RECURSIVE_TARGETS([tidy]])
AC_CONFIG_HEADERS([lib/ink_autoconf.h])
{code}
as a temporary workaround. This change allowed autoreconf and configure to
complete successfully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4546) Build errors for H2 tests on OmniOS
[
https://issues.apache.org/jira/browse/TS-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431943#comment-15431943
]
Masakazu Kitajo edited comment on TS-4546 at 8/23/16 1:29 AM:
--
I comitted a fix for this.
[~zwoop] Could you check that the issue is really resolved on OmniOS?
was (Author: maskit):
[~zwoop] Could you check that the issue is really resolved on OmniOS?
> Build errors for H2 tests on OmniOS
> ---
>
> Key: TS-4546
> URL: https://issues.apache.org/jira/browse/TS-4546
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Tests
>Reporter: Leif Hedstrom
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {code}
> CXX test_HPACK.o
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc: In function
> ‘int prepare()’:
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:12: error:
> ‘struct dirent’ has no member named ‘d_type’
> if (d->d_type == DT_REG) {
> ^
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:22: error:
> ‘DT_REG’ was not declared in this scope
> if (d->d_type == DT_REG) {
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4546) Build errors for H2 tests on OmniOS
[
https://issues.apache.org/jira/browse/TS-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431943#comment-15431943
]
Masakazu Kitajo commented on TS-4546:
-
[~zwoop] Could you check that the issue is really resolved on OmniOS?
> Build errors for H2 tests on OmniOS
> ---
>
> Key: TS-4546
> URL: https://issues.apache.org/jira/browse/TS-4546
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Tests
>Reporter: Leif Hedstrom
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {code}
> CXX test_HPACK.o
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc: In function
> ‘int prepare()’:
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:12: error:
> ‘struct dirent’ has no member named ‘d_type’
> if (d->d_type == DT_REG) {
> ^
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:22: error:
> ‘DT_REG’ was not declared in this scope
> if (d->d_type == DT_REG) {
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4546) Build errors for H2 tests on OmniOS
[
https://issues.apache.org/jira/browse/TS-4546?focusedWorklogId=26859&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26859
]
ASF GitHub Bot logged work on TS-4546:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 01:24
Start Date: 23/Aug/16 01:24
Worklog Time Spent: 10m
Work Description: Github user maskit closed the pull request at:
https://github.com/apache/trafficserver/pull/885
Issue Time Tracking
---
Worklog Id: (was: 26859)
Time Spent: 1h 40m (was: 1.5h)
> Build errors for H2 tests on OmniOS
> ---
>
> Key: TS-4546
> URL: https://issues.apache.org/jira/browse/TS-4546
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Tests
>Reporter: Leif Hedstrom
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {code}
> CXX test_HPACK.o
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc: In function
> ‘int prepare()’:
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:12: error:
> ‘struct dirent’ has no member named ‘d_type’
> if (d->d_type == DT_REG) {
> ^
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:22: error:
> ‘DT_REG’ was not declared in this scope
> if (d->d_type == DT_REG) {
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #885: TS-4546: Fix a build error on OmniOS
Github user maskit closed the pull request at: https://github.com/apache/trafficserver/pull/885 --- 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-2237) URL encoding wrong in squid.blog
[ https://issues.apache.org/jira/browse/TS-2237?focusedWorklogId=26858&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26858 ] ASF GitHub Bot logged work on TS-2237: -- Author: ASF GitHub Bot Created on: 23/Aug/16 01:23 Start Date: 23/Aug/16 01:23 Worklog Time Spent: 10m Work Description: Github user maskit commented on the issue: https://github.com/apache/trafficserver/pull/866 👍 Issue Time Tracking --- Worklog Id: (was: 26858) Time Spent: 3h 50m (was: 3h 40m) > URL encoding wrong in squid.blog > > > Key: TS-2237 > URL: https://issues.apache.org/jira/browse/TS-2237 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: David Carlin >Assignee: Sudheer Vinukonda >Priority: Minor > Labels: yahoo > Fix For: 7.0.0 > > Attachments: TS-2237.diff > > Time Spent: 3h 50m > Remaining Estimate: 0h > > I was replaying URLs captured from squid.blog and I noticed I was getting > 404's for some of them when squid.blog showed a 200 for that request. Turns > out there is an issue with URL encoding. For example: > Requesting file 'duck%20sports%20authority.gif' via curl will put this in the > logs: > duck%2520sports%2520authority.gif > The % from %20 (space) in the request is being converted to %25 resulting in > %2520 > I tested both the % and % log fields - same thing happens. I > tested on ATS 3.2.0 and 3.3.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #866: TS-2237: Fix double encoding of URLs in squid logs...
Github user maskit commented on the issue: https://github.com/apache/trafficserver/pull/866 ð --- 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-4747) if the connection of parent is not alive, not make the parent host down,which will select the the unavailable host again
[
https://issues.apache.org/jira/browse/TS-4747?focusedWorklogId=26857&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26857
]
ASF GitHub Bot logged work on TS-4747:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 01:22
Start Date: 23/Aug/16 01:22
Worklog Time Spent: 10m
Work Description: GitHub user keith2008 opened a pull request:
https://github.com/apache/trafficserver/pull/903
TS-4747: if the connection of parent is notalive, not make the parent host
down,which will select the the unavailablehost again
if the connection of parent is notalive, not make the parent host
down,which will select the the unavailablehost again
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/keith2008/trafficserver TS-4747
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/903.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 #903
commit 8a76d21f5194cb31e514860319b8fcae2d2648be
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:42:30Z
TS-4743: parent use consistent_hash Strategy may cause crash while first
parent is not set
commit 3deb52397b047455ba8aba3e5132e3daafa980ad
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:51:44Z
TS-4744: ParentConsistentHash::selectParent may select the unavailable
parent
commit 49beaa5b5fd712c1d8383b081fc8479ec680ae0a
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:58:54Z
TS-4745: pRecord.failCount not init in ParentRecord::ProcessParents
commit 1159f47044e7add14ccaa84bf110895e244599b0
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T01:12:22Z
TS-4746: ParentRecord *secondary_parents malloc, but no place free,which
will cause memery leak
commit 46671f91f337cd28dbc084dedde903382e3b3c38
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T01:17:40Z
TS-4747: if the connection of parent is notalive, not make the parent host
down,which will select the the unavailablehost again
Issue Time Tracking
---
Worklog Id: (was: 26857)
Time Spent: 10m
Remaining Estimate: 0h
> if the connection of parent is not alive, not make the parent host down,which
> will select the the unavailable host again
>
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
> Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains
> multi ip. if one ip is down,but we not make the host down ,if the next
> request is comming, it will choice this ip again. we should make the host
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s)
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make
> the host down,line:3606
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #903: TS-4747: if the connection of parent is not...
GitHub user keith2008 opened a pull request: https://github.com/apache/trafficserver/pull/903 TS-4747: if the connection of parent is notalive, not make the parent host down,which will select the the unavailablehost again if the connection of parent is notalive, not make the parent host down,which will select the the unavailablehost again You can merge this pull request into a Git repository by running: $ git pull https://github.com/keith2008/trafficserver TS-4747 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/903.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 #903 commit 8a76d21f5194cb31e514860319b8fcae2d2648be Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:42:30Z TS-4743: parent use consistent_hash Strategy may cause crash while first parent is not set commit 3deb52397b047455ba8aba3e5132e3daafa980ad Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:51:44Z TS-4744: ParentConsistentHash::selectParent may select the unavailable parent commit 49beaa5b5fd712c1d8383b081fc8479ec680ae0a Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:58:54Z TS-4745: pRecord.failCount not init in ParentRecord::ProcessParents commit 1159f47044e7add14ccaa84bf110895e244599b0 Author: keith2008 <56985...@qq.com> Date: 2016-08-23T01:12:22Z TS-4746: ParentRecord *secondary_parents malloc, but no place free,which will cause memery leak commit 46671f91f337cd28dbc084dedde903382e3b3c38 Author: keith2008 <56985...@qq.com> Date: 2016-08-23T01:17:40Z TS-4747: if the connection of parent is notalive, not make the parent host down,which will select the the unavailablehost again --- 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-4746) ParentRecord *secondary_parents malloc,but no place free,which will cause memery leak
[
https://issues.apache.org/jira/browse/TS-4746?focusedWorklogId=26856&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26856
]
ASF GitHub Bot logged work on TS-4746:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 01:13
Start Date: 23/Aug/16 01:13
Worklog Time Spent: 10m
Work Description: GitHub user keith2008 opened a pull request:
https://github.com/apache/trafficserver/pull/902
TS-4746: ParentRecord *secondary_parents malloc, but no place free,which
will cause memery leak
ParentRecord *secondary_parents malloc, but no place free,which will cause
memery leak
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/keith2008/trafficserver TS-4746
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/902.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 #902
commit 8a76d21f5194cb31e514860319b8fcae2d2648be
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:42:30Z
TS-4743: parent use consistent_hash Strategy may cause crash while first
parent is not set
commit 3deb52397b047455ba8aba3e5132e3daafa980ad
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:51:44Z
TS-4744: ParentConsistentHash::selectParent may select the unavailable
parent
commit 49beaa5b5fd712c1d8383b081fc8479ec680ae0a
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:58:54Z
TS-4745: pRecord.failCount not init in ParentRecord::ProcessParents
commit 1159f47044e7add14ccaa84bf110895e244599b0
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T01:12:22Z
TS-4746: ParentRecord *secondary_parents malloc, but no place free,which
will cause memery leak
Issue Time Tracking
---
Worklog Id: (was: 26856)
Time Spent: 20m (was: 10m)
> ParentRecord *secondary_parents malloc,but no place free,which will cause
> memery leak
> -
>
> Key: TS-4746
> URL: https://issues.apache.org/jira/browse/TS-4746
> Project: Traffic Server
> Issue Type: Bug
> Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> secondary_parents is malloc in
> ParentRecord::ProcessParents(char *val, bool isPrimary)
> this->secondary_parents = (pRecord *)ats_malloc(sizeof(pRecord) * numTok);
> //line:372
> but no place to free it,which will cause memery leak.
> fix in
> ParentRecord::~ParentRecord()
> {
> if(parents != NULL) {
> ats_free(parents);
> }
> if(primary_parents != NULL){
> ats_free(primary_parents);
> }
> if(second_parents != NULL){
> ats_free(second_parents);
> }
> ..
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #902: TS-4746: ParentRecord *secondary_parents ma...
GitHub user keith2008 opened a pull request: https://github.com/apache/trafficserver/pull/902 TS-4746: ParentRecord *secondary_parents malloc, but no place free,which will cause memery leak ParentRecord *secondary_parents malloc, but no place free,which will cause memery leak You can merge this pull request into a Git repository by running: $ git pull https://github.com/keith2008/trafficserver TS-4746 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/902.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 #902 commit 8a76d21f5194cb31e514860319b8fcae2d2648be Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:42:30Z TS-4743: parent use consistent_hash Strategy may cause crash while first parent is not set commit 3deb52397b047455ba8aba3e5132e3daafa980ad Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:51:44Z TS-4744: ParentConsistentHash::selectParent may select the unavailable parent commit 49beaa5b5fd712c1d8383b081fc8479ec680ae0a Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:58:54Z TS-4745: pRecord.failCount not init in ParentRecord::ProcessParents commit 1159f47044e7add14ccaa84bf110895e244599b0 Author: keith2008 <56985...@qq.com> Date: 2016-08-23T01:12:22Z TS-4746: ParentRecord *secondary_parents malloc, but no place free,which will cause memery leak --- 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-4745) pRecord.failCount not init in ParentRecord::ProcessParents
[ https://issues.apache.org/jira/browse/TS-4745?focusedWorklogId=26855&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26855 ] ASF GitHub Bot logged work on TS-4745: -- Author: ASF GitHub Bot Created on: 23/Aug/16 01:09 Start Date: 23/Aug/16 01:09 Worklog Time Spent: 10m Work Description: GitHub user keith2008 opened a pull request: https://github.com/apache/trafficserver/pull/901 TS-4745: pRecord.failCount not init inParentRecord::ProcessParents pRecord.failCount not init inParentRecord::ProcessParents You can merge this pull request into a Git repository by running: $ git pull https://github.com/keith2008/trafficserver TS-4745 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/901.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 #901 commit 8a76d21f5194cb31e514860319b8fcae2d2648be Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:42:30Z TS-4743: parent use consistent_hash Strategy may cause crash while first parent is not set commit 3deb52397b047455ba8aba3e5132e3daafa980ad Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:51:44Z TS-4744: ParentConsistentHash::selectParent may select the unavailable parent commit 49beaa5b5fd712c1d8383b081fc8479ec680ae0a Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:58:54Z TS-4745: pRecord.failCount not init in ParentRecord::ProcessParents Issue Time Tracking --- Worklog Id: (was: 26855) Time Spent: 10m Remaining Estimate: 0h > pRecord.failCount not init in ParentRecord::ProcessParents > -- > > Key: TS-4745 > URL: https://issues.apache.org/jira/browse/TS-4745 > Project: Traffic Server > Issue Type: Bug > Components: Parent Proxy >Reporter: xiangdong chen >Assignee: John Rushford > Fix For: 7.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > the failCount is not init,is may be an big number ( it already happend in my > sisution),after the ats is startup. > it will cause the parent immediately marked down,once connect the parent > failed. > fix the code: > this->parents[i].failCount = 0;//added by xdchen,line:447 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #901: TS-4745: pRecord.failCount not init inParen...
GitHub user keith2008 opened a pull request: https://github.com/apache/trafficserver/pull/901 TS-4745: pRecord.failCount not init inParentRecord::ProcessParents pRecord.failCount not init inParentRecord::ProcessParents You can merge this pull request into a Git repository by running: $ git pull https://github.com/keith2008/trafficserver TS-4745 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/901.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 #901 commit 8a76d21f5194cb31e514860319b8fcae2d2648be Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:42:30Z TS-4743: parent use consistent_hash Strategy may cause crash while first parent is not set commit 3deb52397b047455ba8aba3e5132e3daafa980ad Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:51:44Z TS-4744: ParentConsistentHash::selectParent may select the unavailable parent commit 49beaa5b5fd712c1d8383b081fc8479ec680ae0a Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:58:54Z TS-4745: pRecord.failCount not init in ParentRecord::ProcessParents --- 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-4362) Remove cacheurl plugin
[ https://issues.apache.org/jira/browse/TS-4362?focusedWorklogId=26854&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26854 ] ASF GitHub Bot logged work on TS-4362: -- Author: ASF GitHub Bot Created on: 23/Aug/16 00:58 Start Date: 23/Aug/16 00:58 Worklog Time Spent: 10m Work Description: Github user PSUdaemon commented on the issue: https://github.com/apache/trafficserver/pull/882 Was this deprecated, or are we just removing and replacing with the cache_key plugin? Issue Time Tracking --- Worklog Id: (was: 26854) Time Spent: 1h 10m (was: 1h) > Remove cacheurl plugin > -- > > Key: TS-4362 > URL: https://issues.apache.org/jira/browse/TS-4362 > Project: Traffic Server > Issue Type: Task > Components: Plugins >Reporter: Gancho Tenev >Assignee: Gancho Tenev > Fix For: 7.0.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Deprecate cacheurl plugin in favor of cachekey plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #882: TS-4362 Removed cacheurl plugin
Github user PSUdaemon commented on the issue: https://github.com/apache/trafficserver/pull/882 Was this deprecated, or are we just removing and replacing with the cache_key plugin? --- 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-4744) ParentConsistentHash::selectParent may select the unavailable parent
[
https://issues.apache.org/jira/browse/TS-4744?focusedWorklogId=26853&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26853
]
ASF GitHub Bot logged work on TS-4744:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 00:53
Start Date: 23/Aug/16 00:53
Worklog Time Spent: 10m
Work Description: GitHub user keith2008 opened a pull request:
https://github.com/apache/trafficserver/pull/900
TS-4744: ParentConsistentHash::selectParent may select the unavailable
parent
ParentConsistentHash::selectParent may select the unavailable parent
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/keith2008/trafficserver TS-4744
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/900.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 #900
commit 8a76d21f5194cb31e514860319b8fcae2d2648be
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:42:30Z
TS-4743: parent use consistent_hash Strategy may cause crash while first
parent is not set
commit 3deb52397b047455ba8aba3e5132e3daafa980ad
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:51:44Z
TS-4744: ParentConsistentHash::selectParent may select the unavailable
parent
Issue Time Tracking
---
Worklog Id: (was: 26853)
Time Spent: 10m
Remaining Estimate: 0h
> ParentConsistentHash::selectParent may select the unavailable parent
>
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
> Issue Type: Bug
> Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL,
> &result->chashIter[last_lookup], &wrap_around[last_lookup], &hash);
> if (prtmp) {
> pRec = (parents[last_lookup] + prtmp->idx);
> }
> } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
> pRec = (parents[last_lookup] + prtmp->idx);
> else //begin of added xdchen, line:143
> pRec = NULL; //endof of added by xdchen
> if (prtmp) {
> pRec = (parents[last_lookup] + prtmp->idx);
> Debug("parent_select", "Selected a new parent: %s.",
> pRec->hostname);
> }
> else //begin of added xdchen, line:188
> pRec = NULL; end of added xdchen
>
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #900: TS-4744: ParentConsistentHash::selectParent...
GitHub user keith2008 opened a pull request: https://github.com/apache/trafficserver/pull/900 TS-4744: ParentConsistentHash::selectParent may select the unavailable parent ParentConsistentHash::selectParent may select the unavailable parent You can merge this pull request into a Git repository by running: $ git pull https://github.com/keith2008/trafficserver TS-4744 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/900.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 #900 commit 8a76d21f5194cb31e514860319b8fcae2d2648be Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:42:30Z TS-4743: parent use consistent_hash Strategy may cause crash while first parent is not set commit 3deb52397b047455ba8aba3e5132e3daafa980ad Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:51:44Z TS-4744: ParentConsistentHash::selectParent may select the unavailable parent --- 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-4743) parent use consistent_hash Strategy may cause crash while first parent is not set
[
https://issues.apache.org/jira/browse/TS-4743?focusedWorklogId=26852&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26852
]
ASF GitHub Bot logged work on TS-4743:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 00:47
Start Date: 23/Aug/16 00:47
Worklog Time Spent: 10m
Work Description: GitHub user keith2008 opened a pull request:
https://github.com/apache/trafficserver/pull/899
TS-4743: parent use consistent_hash Strategy may cause crash while first
parent is not set
parent use consistent_hash Strategy may cause crash while first parent is
not set, due to the pRec is null.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/keith2008/trafficserver TS-4743
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/899.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 #899
commit 8a76d21f5194cb31e514860319b8fcae2d2648be
Author: keith2008 <56985...@qq.com>
Date: 2016-08-23T00:42:30Z
TS-4743: parent use consistent_hash Strategy may cause crash while first
parent is not set
Issue Time Tracking
---
Worklog Id: (was: 26852)
Time Spent: 0.5h (was: 20m)
> parent use consistent_hash Strategy may cause crash while first parent is not
> set
> --
>
> Key: TS-4743
> URL: https://issues.apache.org/jira/browse/TS-4743
> Project: Traffic Server
> Issue Type: Bug
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> my parent.config
> eg :
> dest_domain=. secondary_parent="192.168.104.229:80|1.0;
> 192.168.104.182:80|1.0" round_robin=consistent_hash
> the crash place is :
> DEBUG: (parent_select)
> wrap_around[PRIMARY]: 1, wrap_around[SECONDARY]: 0
> traffic_server: Segmentation fault (Address not mapped to object [0x10])
> ParentConsistentHash.cc:167 code:
> Debug("parent_select", "Selected parent %s is not available, looking up
> another parent.", pRec->hostname);
> Fix the code like
> Debug("parent_select", "Selected parent %s is not available, looking up
> another parent.", pRec ? pRec->hostname:"[NULL]");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #899: TS-4743: parent use consistent_hash Strateg...
GitHub user keith2008 opened a pull request: https://github.com/apache/trafficserver/pull/899 TS-4743: parent use consistent_hash Strategy may cause crash while first parent is not set parent use consistent_hash Strategy may cause crash while first parent is not set, due to the pRec is null. You can merge this pull request into a Git repository by running: $ git pull https://github.com/keith2008/trafficserver TS-4743 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/899.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 #899 commit 8a76d21f5194cb31e514860319b8fcae2d2648be Author: keith2008 <56985...@qq.com> Date: 2016-08-23T00:42:30Z TS-4743: parent use consistent_hash Strategy may cause crash while first parent is not set --- 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] [Commented] (TS-4643) Different SSL Options for Origin and Client
[ https://issues.apache.org/jira/browse/TS-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431876#comment-15431876 ] Adi commented on TS-4643: - Is there any plan to review this ticket? > Different SSL Options for Origin and Client > --- > > Key: TS-4643 > URL: https://issues.apache.org/jira/browse/TS-4643 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: Adi > Fix For: sometime > > > Currently the setting > CONFIG proxy.config.ssl.TLSv1 affects connections from browser to server and > server to origin. > This has to be split to two configuration parameters ideally to differentiate > Browser to Server and Server to Origin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4195) out of traffic_manager causes a double free in traffic_server
[
https://issues.apache.org/jira/browse/TS-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431872#comment-15431872
]
Bryan Call commented on TS-4195:
I also see this one:
{noformat}
==23255==ERROR: AddressSanitizer: attempting double-free on 0x61900f80 in
thread T0 ([ET_NET 0]):
#0 0x2b24e55bbac0 in free (/lib64/libasan.so.3+0xc6ac0)
#1 0x2b24e9155214 in __run_exit_handlers (/lib64/libc.so.6+0x39214)
#2 0x2b24e9155234 in __GI_exit (/lib64/libc.so.6+0x39234)
#3 0x587239 in proxy_signal_handler
/home/bcall/dev/apache/trafficserver/proxy/Main.cc:409
#4 0x2b24e80fac2f (/lib64/libpthread.so.0+0x10c2f)
#5 0x2b24e921f4b2 in __GI_epoll_wait (/lib64/libc.so.6+0x1034b2)
#6 0xc31421 in NetHandler::mainNetEvent(int, Event*)
/home/bcall/dev/apache/trafficserver/iocore/net/UnixNet.cc:423
#7 0xd13ce0 in Continuation::handleEvent(int, void*)
/home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:153
#8 0xd13ce0 in EThread::process_event(Event*, int)
/home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:148
#9 0xd16bc6 in EThread::execute()
/home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:275
#10 0x49ac50 in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1956
#11 0x2b24e913c730 in __libc_start_main (/lib64/libc.so.6+0x20730)
#12 0x4aa598 in _start (/usr/local/bin/traffic_server+0x4aa598)
0x61900f80 is located 0 bytes inside of 1040-byte region
[0x61900f80,0x61901390)
freed by thread T1 here:
=
#0 0x2b24e55bbac0 in free (/lib64/libasan.so.3+0xc6ac0)
#1 0x2b24e9155214 in __run_exit_handlers (/lib64/libc.so.6+0x39214)
==23255==ERROR: LeakSanitizer: detected memory leaks
previously allocated by thread T0 ([ET_NET 0]) here:
Direct leak of 257 byte(s) in 1 object(s) allocated from:
#0 0x2b24e55bbfe0 in calloc (/lib64/libasan.so.3+0xc6fe0)
#1 0x2b24e91553e8 in __new_exitfn (/lib64/libc.so.6+0x393e8)
#0 0x2b24e55bbe20 in malloc (/lib64/libasan.so.3+0xc6e20)
Thread T1 created by T0 ([ET_NET 0]) here:
#1 0x2b24e64f30d5 in ats_malloc
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
#2 0x4988d5 in ats_scoped_str::ats_scoped_str(unsigned long)
../lib/ts/ink_memory.h:442
#3 0x4988d5 in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1608
#0 0x2b24e5526458 in pthread_create (/lib64/libasan.so.3+0x31458)
#4 0x2b24e913c730 in __libc_start_main (/lib64/libc.so.6+0x20730)
#1 0x49833c in ink_thread_create ../lib/ts/ink_thread.h:147
#2 0x49833c in ProcessManager::start() ../mgmt/ProcessManager.h:65
#3 0x49833c in initialize_process_manager
/home/bcall/dev/apache/trafficserver/proxy/Main.cc:503
#4 0x49833c in main /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1567
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#5 0x2b24e913c730 in __libc_start_main (/lib64/libc.so.6+0x20730)
#0 0x2b24e55bbe20 in malloc (/lib64/libasan.so.3+0xc6e20)
SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.3+0xc6ac0) in free
#1 0x2b24e64f30d5 in ats_malloc
/home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
==23255==ABORTING
#2 0xd13640 in Thread::start(char const*, unsigned long, void* (*)(void*),
void*) /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:92
[TrafficManager] ==> signal #2
{noformat}
> out of traffic_manager causes a double free in traffic_server
> -
>
> Key: TS-4195
> URL: https://issues.apache.org/jira/browse/TS-4195
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 7.0.0
>
>
> While testing stuff, I was running traffic_manager from command line, and
> then I get a crash from traffic_server:
> {code}
> root@loki 407/0 # ./bin/traffic_manager
> [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats'
> traffic_server: using root directory '/opt/ats'
> ^C[TrafficManager] ==> Cleaning up and reissuing signal #2
> traffic_server: Interrupt (Signal sent by the kernel 0 0)
> 9083 sent by kill()*** Error in `/opt/ats/bin/traffic_server': corrupted
> double-linked list: 0x028f8940 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x77da5)[0x2ad58f3fcda5]
> /lib64/libc.so.6(+0x80c06)[0x2ad58f405c06]
> /lib64/libc.so.6(cfree+0x4c)[0x2ad58f408cac]
> /lib64/libc.so.6(+0x39685)[0x2ad58f3be685]
> /lib64/libc.so.6(+0x396a5)[0x2ad58f3be6a5]
> /opt/ats/bin/traffic_server[0x4e300atraffic_server: Segmentation fault
> (Address not mapped to object [0x55b02140])
> traffic_server - STACK TRACE:
> /lib64/libc.so.6(nanosleep+0x2d)[0x2ad58f44d7ad]
>
[jira] [Work logged] (TS-4345) Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs
[ https://issues.apache.org/jira/browse/TS-4345?focusedWorklogId=26850&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26850 ] ASF GitHub Bot logged work on TS-4345: -- Author: ASF GitHub Bot Created on: 23/Aug/16 00:18 Start Date: 23/Aug/16 00:18 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/898 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/482/ for details. Issue Time Tracking --- Worklog Id: (was: 26850) Time Spent: 0.5h (was: 20m) > Change defaults for ERROR to not log to syslogs since it can potentially > flood syslogs > -- > > Key: TS-4345 > URL: https://issues.apache.org/jira/browse/TS-4345 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Follow up of TS-3857. > Should we change error defaults to "L" to ensure syslogs are not flooded with > the fix from TS-2940? The current defaults of "SL" did not work correctly > before TS-2940 and after the fix to TS-2940, any repeatedly occurring error > log can flood syslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #898: TS-4345: Change defaults for ERROR to not log to s...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/898 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/482/ 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-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?focusedWorklogId=26849&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26849
]
ASF GitHub Bot logged work on TS-4513:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 00:18
Start Date: 23/Aug/16 00:18
Worklog Time Spent: 10m
Work Description: Github user PSUdaemon commented on the issue:
https://github.com/apache/trafficserver/pull/894
How does this affect us since this code is in a `subtree`?
Issue Time Tracking
---
Worklog Id: (was: 26849)
Time Spent: 50m (was: 40m)
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #894: TS-4513: Error when building with gcc 6.1.1 with l...
Github user PSUdaemon commented on the issue: https://github.com/apache/trafficserver/pull/894 How does this affect us since this code is in a `subtree`? --- 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] [Commented] (TS-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431850#comment-15431850
]
Phil Sorber commented on TS-4513:
-
I see this too, but [~zwoop] doesn't see it, nor do the build hosts.
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4345) Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs
[ https://issues.apache.org/jira/browse/TS-4345?focusedWorklogId=26847&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26847 ] ASF GitHub Bot logged work on TS-4345: -- Author: ASF GitHub Bot Created on: 23/Aug/16 00:13 Start Date: 23/Aug/16 00:13 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/898 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/585/ for details. Issue Time Tracking --- Worklog Id: (was: 26847) Time Spent: 20m (was: 10m) > Change defaults for ERROR to not log to syslogs since it can potentially > flood syslogs > -- > > Key: TS-4345 > URL: https://issues.apache.org/jira/browse/TS-4345 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Follow up of TS-3857. > Should we change error defaults to "L" to ensure syslogs are not flooded with > the fix from TS-2940? The current defaults of "SL" did not work correctly > before TS-2940 and after the fix to TS-2940, any repeatedly occurring error > log can flood syslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4772) Add delay and max-age control to the generator plugin.
[
https://issues.apache.org/jira/browse/TS-4772?focusedWorklogId=26848&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26848
]
ASF GitHub Bot logged work on TS-4772:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 00:13
Start Date: 23/Aug/16 00:13
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/897
Linux build *successful*! See
https://ci.trafficserver.apache.org/job/Github-Linux/481/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26848)
Time Spent: 50m (was: 40m)
> Add delay and max-age control to the generator plugin.
> --
>
> Key: TS-4772
> URL: https://issues.apache.org/jira/browse/TS-4772
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Add configurable control over the response delay and the {{max-age}} in the
> cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4772) Add delay and max-age control to the generator plugin.
[
https://issues.apache.org/jira/browse/TS-4772?focusedWorklogId=26846&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26846
]
ASF GitHub Bot logged work on TS-4772:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 00:13
Start Date: 23/Aug/16 00:13
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/897
FreeBSD build *successful*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/586/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26846)
Time Spent: 40m (was: 0.5h)
> Add delay and max-age control to the generator plugin.
> --
>
> Key: TS-4772
> URL: https://issues.apache.org/jira/browse/TS-4772
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add configurable control over the response delay and the {{max-age}} in the
> cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #897: TS-4772: Add delay and max-age control to the gene...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/897 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/481/ 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. ---
[GitHub] trafficserver issue #898: TS-4345: Change defaults for ERROR to not log to s...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/898 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/585/ 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. ---
[GitHub] trafficserver issue #897: TS-4772: Add delay and max-age control to the gene...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/897 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/586/ 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] [Resolved] (TS-4374) Remove lighthttpd_mod_generator
[ https://issues.apache.org/jira/browse/TS-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-4374. Resolution: Fixed > Remove lighthttpd_mod_generator > --- > > Key: TS-4374 > URL: https://issues.apache.org/jira/browse/TS-4374 > Project: Traffic Server > Issue Type: Task > Components: Cleanup >Reporter: James Peach >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > We have the generator plugin now, so we don't need this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4374) Remove lighthttpd_mod_generator
[ https://issues.apache.org/jira/browse/TS-4374?focusedWorklogId=26845&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26845 ] ASF GitHub Bot logged work on TS-4374: -- Author: ASF GitHub Bot Created on: 23/Aug/16 00:09 Start Date: 23/Aug/16 00:09 Worklog Time Spent: 10m Work Description: Github user bryancall closed the pull request at: https://github.com/apache/trafficserver/pull/896 Issue Time Tracking --- Worklog Id: (was: 26845) Time Spent: 50m (was: 40m) > Remove lighthttpd_mod_generator > --- > > Key: TS-4374 > URL: https://issues.apache.org/jira/browse/TS-4374 > Project: Traffic Server > Issue Type: Task > Components: Cleanup >Reporter: James Peach >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > We have the generator plugin now, so we don't need this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #896: TS-4374: Remove lighthttpd_mod_generator
Github user bryancall closed the pull request at: https://github.com/apache/trafficserver/pull/896 --- 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-4772) Add delay and max-age control to the generator plugin.
[
https://issues.apache.org/jira/browse/TS-4772?focusedWorklogId=26844&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26844
]
ASF GitHub Bot logged work on TS-4772:
--
Author: ASF GitHub Bot
Created on: 23/Aug/16 00:03
Start Date: 23/Aug/16 00:03
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/897
Linux build *successful*! See
https://ci.trafficserver.apache.org/job/Github-Linux/480/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26844)
Time Spent: 0.5h (was: 20m)
> Add delay and max-age control to the generator plugin.
> --
>
> Key: TS-4772
> URL: https://issues.apache.org/jira/browse/TS-4772
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add configurable control over the response delay and the {{max-age}} in the
> cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #897: TS-4772: Add delay and max-age control to the gene...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/897 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/480/ 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-4345) Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs
[ https://issues.apache.org/jira/browse/TS-4345?focusedWorklogId=26843&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26843 ] ASF GitHub Bot logged work on TS-4345: -- Author: ASF GitHub Bot Created on: 23/Aug/16 00:02 Start Date: 23/Aug/16 00:02 Worklog Time Spent: 10m Work Description: GitHub user bryancall opened a pull request: https://github.com/apache/trafficserver/pull/898 TS-4345: Change defaults for ERROR to not log to syslogs since it can… … potentially flood syslogs You can merge this pull request into a Git repository by running: $ git pull https://github.com/bryancall/trafficserver TS-4345 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/898.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 #898 commit a84d11185a140163f55f715ebcd0be3fb8459ca7 Author: Bryan Call Date: 2016-08-23T00:02:28Z TS-4345: Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs Issue Time Tracking --- Worklog Id: (was: 26843) Time Spent: 10m Remaining Estimate: 0h > Change defaults for ERROR to not log to syslogs since it can potentially > flood syslogs > -- > > Key: TS-4345 > URL: https://issues.apache.org/jira/browse/TS-4345 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Follow up of TS-3857. > Should we change error defaults to "L" to ensure syslogs are not flooded with > the fix from TS-2940? The current defaults of "SL" did not work correctly > before TS-2940 and after the fix to TS-2940, any repeatedly occurring error > log can flood syslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #898: TS-4345: Change defaults for ERROR to not l...
GitHub user bryancall opened a pull request: https://github.com/apache/trafficserver/pull/898 TS-4345: Change defaults for ERROR to not log to syslogs since it can⦠⦠potentially flood syslogs You can merge this pull request into a Git repository by running: $ git pull https://github.com/bryancall/trafficserver TS-4345 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/898.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 #898 commit a84d11185a140163f55f715ebcd0be3fb8459ca7 Author: Bryan Call Date: 2016-08-23T00:02:28Z TS-4345: Change defaults for ERROR to not log to syslogs since it can potentially flood syslogs --- 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 #896: TS-4374: Remove lighthttpd_mod_generator
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/896 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/479/ 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-4374) Remove lighthttpd_mod_generator
[ https://issues.apache.org/jira/browse/TS-4374?focusedWorklogId=26842&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26842 ] ASF GitHub Bot logged work on TS-4374: -- Author: ASF GitHub Bot Created on: 22/Aug/16 23:58 Start Date: 22/Aug/16 23:58 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/896 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/479/ for details. Issue Time Tracking --- Worklog Id: (was: 26842) Time Spent: 40m (was: 0.5h) > Remove lighthttpd_mod_generator > --- > > Key: TS-4374 > URL: https://issues.apache.org/jira/browse/TS-4374 > Project: Traffic Server > Issue Type: Task > Components: Cleanup >Reporter: James Peach >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 40m > Remaining Estimate: 0h > > We have the generator plugin now, so we don't need this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #887: TS-2258: Mark whether configs are reloadabl...
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/887#discussion_r75781340
--- Diff: mgmt/RecordsConfig.cc ---
@@ -103,10 +103,10 @@ static const RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.output.logfile.rolling_size_mb", RECD_INT,
"100", RECU_DYNAMIC, RR_NULL, RECC_STR, "^0*[1-9][0-9]*$", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_RESTART_TS, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
--- End diff --
This looks dynamic to me.
---
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-4772) Add delay and max-age control to the generator plugin.
[
https://issues.apache.org/jira/browse/TS-4772?focusedWorklogId=26840&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26840
]
ASF GitHub Bot logged work on TS-4772:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:55
Start Date: 22/Aug/16 23:55
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/897
FreeBSD build *failed*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/584/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26840)
Time Spent: 20m (was: 10m)
> Add delay and max-age control to the generator plugin.
> --
>
> Key: TS-4772
> URL: https://issues.apache.org/jira/browse/TS-4772
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add configurable control over the response delay and the {{max-age}} in the
> cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-2258) Verify that all fields are correct in RecordsConfig.cc
[
https://issues.apache.org/jira/browse/TS-2258?focusedWorklogId=26841&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26841
]
ASF GitHub Bot logged work on TS-2258:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:56
Start Date: 22/Aug/16 23:56
Worklog Time Spent: 10m
Work Description: Github user jpeach commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/887#discussion_r75781340
--- Diff: mgmt/RecordsConfig.cc ---
@@ -103,10 +103,10 @@ static const RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.output.logfile.rolling_size_mb", RECD_INT,
"100", RECU_DYNAMIC, RR_NULL, RECC_STR, "^0*[1-9][0-9]*$", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_RESTART_TS, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
--- End diff --
This looks dynamic to me.
Issue Time Tracking
---
Worklog Id: (was: 26841)
Time Spent: 50m (was: 40m)
> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
> Labels: newbie
> Fix For: 7.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that
> fields such as if it's dynamically reloadable or not, validation regexes etc.
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for
> everything "configuration"; it can be used for command line help (e.g.
> traffic_line can say if a config is reloadable), and we can even use it as a
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new
> type of tools to help managing configurations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #897: TS-4772: Add delay and max-age control to the gene...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/897 FreeBSD build *failed*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/584/ 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-2258) Verify that all fields are correct in RecordsConfig.cc
[
https://issues.apache.org/jira/browse/TS-2258?focusedWorklogId=26839&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26839
]
ASF GitHub Bot logged work on TS-2258:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:54
Start Date: 22/Aug/16 23:54
Worklog Time Spent: 10m
Work Description: Github user jpeach commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/887#discussion_r75781258
--- Diff: mgmt/RecordsConfig.cc ---
@@ -67,29 +67,29 @@ static const RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.alarm_email", RECD_STRING, TS_PKGSYSUSER,
RECU_DYNAMIC, RR_NULL, RECC_STR, ".*", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.syslog_facility", RECD_STRING, "LOG_DAEMON",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.syslog_facility", RECD_STRING, "LOG_DAEMON",
RECU_RESTART_TS, RR_NULL, RECC_STR, ".*", RECA_NULL}
,
//# Negative core limit means max out limit
- {RECT_CONFIG, "proxy.config.core_limit", RECD_INT, "-1", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.core_limit", RECD_INT, "-1",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
{RECT_CONFIG, "proxy.config.crash_log_helper", RECD_STRING,
MGMT_CRASHLOG_HELPER, RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
// 0 - Disabled, 1 - enabled for important pages (e.g. cache directory),
2 - enabled for all pages
- {RECT_CONFIG, "proxy.config.mlock_enabled", RECD_INT, "0", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.mlock_enabled", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-2]", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.cop.core_signal", RECD_INT, "0", RECU_NULL,
RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.core_signal", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.linux_min_swapfree_kb", RECD_INT, "0",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.linux_min_swapfree_kb", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.linux_min_memfree_kb", RECD_INT, "0",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.linux_min_memfree_kb", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.init_sleep_time", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, "[0-900]", RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.init_sleep_time", RECD_INT, "0",
RECU_RESTART_TC, RR_NULL, RECC_INT, "[0-900]", RECA_NULL}
,
//# 0 = disable (seconds)
- {RECT_CONFIG, "proxy.config.dump_mem_info_frequency", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.dump_mem_info_frequency", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
//# 0 = disable
- {RECT_CONFIG, "proxy.config.http_ui_enabled", RECD_INT, "0", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.http_ui_enabled", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
--- End diff --
This one looks dynamic to me.
Issue Time Tracking
---
Worklog Id: (was: 26839)
Time Spent: 40m (was: 0.5h)
> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
> Labels: newbie
> Fix For: 7.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that
> fields such as if it's dynamically reloadable or not, validation regexes etc.
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for
> everything "configuration"; it can be used for command line help (e.g.
> traffic_line can say if a config is reloadable), and we can even use it as a
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new
> type of tools to help managing co
[GitHub] trafficserver pull request #887: TS-2258: Mark whether configs are reloadabl...
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/887#discussion_r75781258
--- Diff: mgmt/RecordsConfig.cc ---
@@ -67,29 +67,29 @@ static const RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.alarm_email", RECD_STRING, TS_PKGSYSUSER,
RECU_DYNAMIC, RR_NULL, RECC_STR, ".*", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.syslog_facility", RECD_STRING, "LOG_DAEMON",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.syslog_facility", RECD_STRING, "LOG_DAEMON",
RECU_RESTART_TS, RR_NULL, RECC_STR, ".*", RECA_NULL}
,
//# Negative core limit means max out limit
- {RECT_CONFIG, "proxy.config.core_limit", RECD_INT, "-1", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.core_limit", RECD_INT, "-1",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
{RECT_CONFIG, "proxy.config.crash_log_helper", RECD_STRING,
MGMT_CRASHLOG_HELPER, RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
// 0 - Disabled, 1 - enabled for important pages (e.g. cache directory),
2 - enabled for all pages
- {RECT_CONFIG, "proxy.config.mlock_enabled", RECD_INT, "0", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.mlock_enabled", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-2]", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.cop.core_signal", RECD_INT, "0", RECU_NULL,
RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.core_signal", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.linux_min_swapfree_kb", RECD_INT, "0",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.linux_min_swapfree_kb", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.linux_min_memfree_kb", RECD_INT, "0",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.linux_min_memfree_kb", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.init_sleep_time", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, "[0-900]", RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.init_sleep_time", RECD_INT, "0",
RECU_RESTART_TC, RR_NULL, RECC_INT, "[0-900]", RECA_NULL}
,
//# 0 = disable (seconds)
- {RECT_CONFIG, "proxy.config.dump_mem_info_frequency", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.dump_mem_info_frequency", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
//# 0 = disable
- {RECT_CONFIG, "proxy.config.http_ui_enabled", RECD_INT, "0", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.http_ui_enabled", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
--- End diff --
This one looks dynamic to me.
---
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-4374) Remove lighthttpd_mod_generator
[ https://issues.apache.org/jira/browse/TS-4374?focusedWorklogId=26838&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26838 ] ASF GitHub Bot logged work on TS-4374: -- Author: ASF GitHub Bot Created on: 22/Aug/16 23:53 Start Date: 22/Aug/16 23:53 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/896 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/583/ for details. Issue Time Tracking --- Worklog Id: (was: 26838) Time Spent: 0.5h (was: 20m) > Remove lighthttpd_mod_generator > --- > > Key: TS-4374 > URL: https://issues.apache.org/jira/browse/TS-4374 > Project: Traffic Server > Issue Type: Task > Components: Cleanup >Reporter: James Peach >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We have the generator plugin now, so we don't need this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #896: TS-4374: Remove lighthttpd_mod_generator
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/896 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/583/ 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-4374) Remove lighthttpd_mod_generator
[ https://issues.apache.org/jira/browse/TS-4374?focusedWorklogId=26837&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26837 ] ASF GitHub Bot logged work on TS-4374: -- Author: ASF GitHub Bot Created on: 22/Aug/16 23:50 Start Date: 22/Aug/16 23:50 Worklog Time Spent: 10m Work Description: Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/896 👍 Issue Time Tracking --- Worklog Id: (was: 26837) Time Spent: 20m (was: 10m) > Remove lighthttpd_mod_generator > --- > > Key: TS-4374 > URL: https://issues.apache.org/jira/browse/TS-4374 > Project: Traffic Server > Issue Type: Task > Components: Cleanup >Reporter: James Peach >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We have the generator plugin now, so we don't need this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #896: TS-4374: Remove lighthttpd_mod_generator
Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/896 ð --- 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-4772) Add delay and max-age control to the generator plugin.
[
https://issues.apache.org/jira/browse/TS-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-4772:
Fix Version/s: 7.0.0
> Add delay and max-age control to the generator plugin.
> --
>
> Key: TS-4772
> URL: https://issues.apache.org/jira/browse/TS-4772
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
> Fix For: 7.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add configurable control over the response delay and the {{max-age}} in the
> cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4772) Add delay and max-age control to the generator plugin.
[
https://issues.apache.org/jira/browse/TS-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-4772:
---
Assignee: James Peach
> Add delay and max-age control to the generator plugin.
> --
>
> Key: TS-4772
> URL: https://issues.apache.org/jira/browse/TS-4772
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add configurable control over the response delay and the {{max-age}} in the
> cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4772) Add delay and max-age control to the generator plugin.
[
https://issues.apache.org/jira/browse/TS-4772?focusedWorklogId=26836&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26836
]
ASF GitHub Bot logged work on TS-4772:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:47
Start Date: 22/Aug/16 23:47
Worklog Time Spent: 10m
Work Description: GitHub user jpeach opened a pull request:
https://github.com/apache/trafficserver/pull/897
TS-4772: Add delay and max-age control to the generator plugin.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jpeach/trafficserver fix/4772
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/897.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 #897
commit 733fc38d7cadde67c05770647b5bde66252fb0ca
Author: James Peach
Date: 2016-08-22T20:06:51Z
TS-4772: Add delay and max-age control to the generator plugin.
Issue Time Tracking
---
Worklog Id: (was: 26836)
Time Spent: 10m
Remaining Estimate: 0h
> Add delay and max-age control to the generator plugin.
> --
>
> Key: TS-4772
> URL: https://issues.apache.org/jira/browse/TS-4772
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add configurable control over the response delay and the {{max-age}} in the
> cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #897: TS-4772: Add delay and max-age control to t...
GitHub user jpeach opened a pull request: https://github.com/apache/trafficserver/pull/897 TS-4772: Add delay and max-age control to the generator plugin. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jpeach/trafficserver fix/4772 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/897.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 #897 commit 733fc38d7cadde67c05770647b5bde66252fb0ca Author: James Peach Date: 2016-08-22T20:06:51Z TS-4772: Add delay and max-age control to the generator plugin. --- 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-4374) Remove lighthttpd_mod_generator
[ https://issues.apache.org/jira/browse/TS-4374?focusedWorklogId=26835&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26835 ] ASF GitHub Bot logged work on TS-4374: -- Author: ASF GitHub Bot Created on: 22/Aug/16 23:45 Start Date: 22/Aug/16 23:45 Worklog Time Spent: 10m Work Description: GitHub user bryancall opened a pull request: https://github.com/apache/trafficserver/pull/896 TS-4374: Remove lighthttpd_mod_generator You can merge this pull request into a Git repository by running: $ git pull https://github.com/bryancall/trafficserver TS-4374 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/896.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 #896 commit 0e20bce6dbeaada1f968922d47dc237b467d8a4d Author: Bryan Call Date: 2016-08-22T23:44:54Z TS-4374: Remove lighthttpd_mod_generator Issue Time Tracking --- Worklog Id: (was: 26835) Time Spent: 10m Remaining Estimate: 0h > Remove lighthttpd_mod_generator > --- > > Key: TS-4374 > URL: https://issues.apache.org/jira/browse/TS-4374 > Project: Traffic Server > Issue Type: Task > Components: Cleanup >Reporter: James Peach >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We have the generator plugin now, so we don't need this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #896: TS-4374: Remove lighthttpd_mod_generator
GitHub user bryancall opened a pull request: https://github.com/apache/trafficserver/pull/896 TS-4374: Remove lighthttpd_mod_generator You can merge this pull request into a Git repository by running: $ git pull https://github.com/bryancall/trafficserver TS-4374 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/896.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 #896 commit 0e20bce6dbeaada1f968922d47dc237b467d8a4d Author: Bryan Call Date: 2016-08-22T23:44:54Z TS-4374: Remove lighthttpd_mod_generator --- 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-4700) Change the default timeout for HTTP/2
[ https://issues.apache.org/jira/browse/TS-4700?focusedWorklogId=26834&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26834 ] ASF GitHub Bot logged work on TS-4700: -- Author: ASF GitHub Bot Created on: 22/Aug/16 23:38 Start Date: 22/Aug/16 23:38 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/895 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/478/ for details. Issue Time Tracking --- Worklog Id: (was: 26834) Time Spent: 0.5h (was: 20m) > Change the default timeout for HTTP/2 > -- > > Key: TS-4700 > URL: https://issues.apache.org/jira/browse/TS-4700 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP/2 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > At the HTTP Workshop Patrick McManus stated that Firefox using a timeout of > 115 seconds for HTTP/2 and likes to close the connection before they normally > see a 120 second timeout on server. They don't want to have a race condition > with the server. > It would be better that was set the default timeout to 120, so we don't have > issues with race connections and Firefox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #895: TS-4700: Change the default timeout for HTTP/2
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/895 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/478/ 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-4700) Change the default timeout for HTTP/2
[ https://issues.apache.org/jira/browse/TS-4700?focusedWorklogId=26833&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26833 ] ASF GitHub Bot logged work on TS-4700: -- Author: ASF GitHub Bot Created on: 22/Aug/16 23:34 Start Date: 22/Aug/16 23:34 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/895 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/582/ for details. Issue Time Tracking --- Worklog Id: (was: 26833) Time Spent: 20m (was: 10m) > Change the default timeout for HTTP/2 > -- > > Key: TS-4700 > URL: https://issues.apache.org/jira/browse/TS-4700 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP/2 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > At the HTTP Workshop Patrick McManus stated that Firefox using a timeout of > 115 seconds for HTTP/2 and likes to close the connection before they normally > see a 120 second timeout on server. They don't want to have a race condition > with the server. > It would be better that was set the default timeout to 120, so we don't have > issues with race connections and Firefox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #895: TS-4700: Change the default timeout for HTTP/2
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/895 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/582/ 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] [Updated] (TS-4618) Still in priority queue after closing the stream
[
https://issues.apache.org/jira/browse/TS-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4618:
---
Fix Version/s: (was: 7.0.0)
> Still in priority queue after closing the stream
>
>
> Key: TS-4618
> URL: https://issues.apache.org/jira/browse/TS-4618
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> After the stream is closed it is still in the priority queue
> {code}
> (gdb) bt
> #0 Mutex_lock (this=0x2b6c005a5858, stream=0x2b6c0cd773c0,
> payload_length=@0x2b6b873cdd38) at
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 MutexLock (this=0x2b6c005a5858, stream=0x2b6c0cd773c0,
> payload_length=@0x2b6b873cdd38) at
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 Http2ConnectionState::send_a_data_frame (this=0x2b6c005a5858,
> stream=0x2b6c0cd773c0, payload_length=@0x2b6b873cdd38)
> at ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1037
> #3 0x005f69b9 in
> Http2ConnectionState::send_data_frames_depends_on_priority
> (this=0x2b6c005a5858) at
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x005f6f1c in Http2ConnectionState::main_event_handler
> (this=0x2b6c005a5858, event=, edata= out>)
> at ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0x0075408d in handleEvent (this=0x2b6b85bb7010, e=0x2b6bc41cf360,
> calling_code=2254) at
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 EThread::process_event (this=0x2b6b85bb7010, e=0x2b6bc41cf360,
> calling_code=2254) at
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0x00754b6b in EThread::execute (this=0x2b6b85bb7010) at
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0x007534ca in spawn_thread_internal (a=0x21f3280) at
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b6b83dccaa1 in start_thread () from /lib64/libpthread.so.0
> #10 0x0038180e893d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-4618) Still in priority queue after closing the stream
[
https://issues.apache.org/jira/browse/TS-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-4618.
--
Resolution: Duplicate
> Still in priority queue after closing the stream
>
>
> Key: TS-4618
> URL: https://issues.apache.org/jira/browse/TS-4618
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> After the stream is closed it is still in the priority queue
> {code}
> (gdb) bt
> #0 Mutex_lock (this=0x2b6c005a5858, stream=0x2b6c0cd773c0,
> payload_length=@0x2b6b873cdd38) at
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 MutexLock (this=0x2b6c005a5858, stream=0x2b6c0cd773c0,
> payload_length=@0x2b6b873cdd38) at
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 Http2ConnectionState::send_a_data_frame (this=0x2b6c005a5858,
> stream=0x2b6c0cd773c0, payload_length=@0x2b6b873cdd38)
> at ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1037
> #3 0x005f69b9 in
> Http2ConnectionState::send_data_frames_depends_on_priority
> (this=0x2b6c005a5858) at
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x005f6f1c in Http2ConnectionState::main_event_handler
> (this=0x2b6c005a5858, event=, edata= out>)
> at ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0x0075408d in handleEvent (this=0x2b6b85bb7010, e=0x2b6bc41cf360,
> calling_code=2254) at
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 EThread::process_event (this=0x2b6b85bb7010, e=0x2b6bc41cf360,
> calling_code=2254) at
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0x00754b6b in EThread::execute (this=0x2b6b85bb7010) at
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0x007534ca in spawn_thread_internal (a=0x21f3280) at
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b6b83dccaa1 in start_thread () from /lib64/libpthread.so.0
> #10 0x0038180e893d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4772) Add delay and max-age control to the generator plugin.
James Peach created TS-4772:
---
Summary: Add delay and max-age control to the generator plugin.
Key: TS-4772
URL: https://issues.apache.org/jira/browse/TS-4772
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: James Peach
Add configurable control over the response delay and the {{max-age}} in the
cached response. This makes it easier to test cache revalidation scenarios.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4618) Still in priority queue after closing the stream
[
https://issues.apache.org/jira/browse/TS-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-4618:
--
Assignee: Bryan Call
> Still in priority queue after closing the stream
>
>
> Key: TS-4618
> URL: https://issues.apache.org/jira/browse/TS-4618
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> After the stream is closed it is still in the priority queue
> {code}
> (gdb) bt
> #0 Mutex_lock (this=0x2b6c005a5858, stream=0x2b6c0cd773c0,
> payload_length=@0x2b6b873cdd38) at
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 MutexLock (this=0x2b6c005a5858, stream=0x2b6c0cd773c0,
> payload_length=@0x2b6b873cdd38) at
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 Http2ConnectionState::send_a_data_frame (this=0x2b6c005a5858,
> stream=0x2b6c0cd773c0, payload_length=@0x2b6b873cdd38)
> at ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1037
> #3 0x005f69b9 in
> Http2ConnectionState::send_data_frames_depends_on_priority
> (this=0x2b6c005a5858) at
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x005f6f1c in Http2ConnectionState::main_event_handler
> (this=0x2b6c005a5858, event=, edata= out>)
> at ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0x0075408d in handleEvent (this=0x2b6b85bb7010, e=0x2b6bc41cf360,
> calling_code=2254) at
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 EThread::process_event (this=0x2b6b85bb7010, e=0x2b6bc41cf360,
> calling_code=2254) at
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0x00754b6b in EThread::execute (this=0x2b6b85bb7010) at
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0x007534ca in spawn_thread_internal (a=0x21f3280) at
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b6b83dccaa1 in start_thread () from /lib64/libpthread.so.0
> #10 0x0038180e893d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-4513.
Resolution: Fixed
Applied the patch from 7b26e9c998095ef9fbc4540908df6c30a693baa0 and fixed 1
other formatting error gcc 6.1.1 doesn't like.
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?focusedWorklogId=26831&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26831
]
ASF GitHub Bot logged work on TS-4513:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:28
Start Date: 22/Aug/16 23:28
Worklog Time Spent: 10m
Work Description: Github user bryancall closed the pull request at:
https://github.com/apache/trafficserver/pull/894
Issue Time Tracking
---
Worklog Id: (was: 26831)
Time Spent: 0.5h (was: 20m)
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?focusedWorklogId=26830&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26830
]
ASF GitHub Bot logged work on TS-4513:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:28
Start Date: 22/Aug/16 23:28
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/894
FreeBSD build *successful*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/581/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26830)
Time Spent: 0.5h (was: 20m)
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?focusedWorklogId=26832&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26832
]
ASF GitHub Bot logged work on TS-4513:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:28
Start Date: 22/Aug/16 23:28
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/894
Linux build *successful*! See
https://ci.trafficserver.apache.org/job/Github-Linux/477/ for details.
Issue Time Tracking
---
Worklog Id: (was: 26832)
Time Spent: 40m (was: 0.5h)
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #894: TS-4513: Error when building with gcc 6.1.1 with l...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/894 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/477/ 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. ---
[GitHub] trafficserver issue #894: TS-4513: Error when building with gcc 6.1.1 with l...
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/894 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/581/ 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. ---
[GitHub] trafficserver pull request #894: TS-4513: Error when building with gcc 6.1.1...
Github user bryancall closed the pull request at: https://github.com/apache/trafficserver/pull/894 --- 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-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?focusedWorklogId=26829&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26829
]
ASF GitHub Bot logged work on TS-4513:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:26
Start Date: 22/Aug/16 23:26
Worklog Time Spent: 10m
Work Description: Github user jpeach commented on the issue:
https://github.com/apache/trafficserver/pull/894
👍
Issue Time Tracking
---
Worklog Id: (was: 26829)
Time Spent: 20m (was: 10m)
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #894: TS-4513: Error when building with gcc 6.1.1 with l...
Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/894 ð --- 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-4700) Change the default timeout for HTTP/2
[ https://issues.apache.org/jira/browse/TS-4700?focusedWorklogId=26828&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26828 ] ASF GitHub Bot logged work on TS-4700: -- Author: ASF GitHub Bot Created on: 22/Aug/16 23:22 Start Date: 22/Aug/16 23:22 Worklog Time Spent: 10m Work Description: GitHub user bryancall opened a pull request: https://github.com/apache/trafficserver/pull/895 TS-4700: Change the default timeout for HTTP/2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bryancall/trafficserver TS-4700 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/895.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 #895 commit 3db54378720e6f4c66e265c28b7c0d445afe5849 Author: Bryan Call Date: 2016-08-22T23:21:25Z TS-4700: Change the default timeout for HTTP/2 Issue Time Tracking --- Worklog Id: (was: 26828) Time Spent: 10m Remaining Estimate: 0h > Change the default timeout for HTTP/2 > -- > > Key: TS-4700 > URL: https://issues.apache.org/jira/browse/TS-4700 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, HTTP/2 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 7.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > At the HTTP Workshop Patrick McManus stated that Firefox using a timeout of > 115 seconds for HTTP/2 and likes to close the connection before they normally > see a 120 second timeout on server. They don't want to have a race condition > with the server. > It would be better that was set the default timeout to 120, so we don't have > issues with race connections and Firefox. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #895: TS-4700: Change the default timeout for HTT...
GitHub user bryancall opened a pull request: https://github.com/apache/trafficserver/pull/895 TS-4700: Change the default timeout for HTTP/2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bryancall/trafficserver TS-4700 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/895.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 #895 commit 3db54378720e6f4c66e265c28b7c0d445afe5849 Author: Bryan Call Date: 2016-08-22T23:21:25Z TS-4700: Change the default timeout for HTTP/2 --- 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-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?focusedWorklogId=26827&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26827
]
ASF GitHub Bot logged work on TS-4513:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 23:16
Start Date: 22/Aug/16 23:16
Worklog Time Spent: 10m
Work Description: GitHub user bryancall opened a pull request:
https://github.com/apache/trafficserver/pull/894
TS-4513: Error when building with gcc 6.1.1 with luajit
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bryancall/trafficserver TS-4513
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/894.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 #894
commit 5f91438df0b89865386374ec1363ad8edb2b11cb
Author: Bryan Call
Date: 2016-08-22T23:11:14Z
TS-4513: Error when building with gcc 6.1.1 with luajit
Issue Time Tracking
---
Worklog Id: (was: 26827)
Time Spent: 10m
Remaining Estimate: 0h
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4513) Error when building with gcc 6.1.1 with luajit
[
https://issues.apache.org/jira/browse/TS-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-4513:
--
Assignee: Bryan Call
> Error when building with gcc 6.1.1 with luajit
> --
>
> Key: TS-4513
> URL: https://issues.apache.org/jira/browse/TS-4513
> Project: Traffic Server
> Issue Type: Improvement
> Components: Lua
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> Errors that I am seeing:
> {code}
> lj_cparse.c: In function 'cp_next_':
> lj_cparse.c:313:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
>^~
> lj_cparse.c:313:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '|') return '|'; cp_get(cp); return CTOK_OROR;
> ^~
> lj_cparse.c:315:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
>^~
> lj_cparse.c:315:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '&') return '&'; cp_get(cp); return CTOK_ANDAND;
> ^~
> lj_cparse.c:317:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
>^~
> lj_cparse.c:317:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '='; cp_get(cp); return CTOK_EQ;
> ^~
> lj_cparse.c:319:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
>^~
> lj_cparse.c:319:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '=') return '!'; cp_get(cp); return CTOK_NE;
> ^~
> lj_cparse.c:329:7: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
>^~
> lj_cparse.c:329:42: note: ...this statement, but the latter is misleadingly
> indented as if it is guarded by the 'if'
>if (cp_get(cp) != '>') return '-'; cp_get(cp); return CTOK_DEREF;
> ^~
> HOSTCChost/buildvm.o
> In file included from host/buildvm.c:59:0:
> ./../dynasm/dasm_x86.h: In function 'dasm_put':
> ./../dynasm/dasm_x86.h:207:2: error: this 'if' clause does not guard...
> [-Werror=misleading-indentation]
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~
> ./../dynasm/dasm_x86.h:207:45: note: ...this statement, but the latter is
> misleadingly indented as if it is guarded by the 'if'
> if (*p++ == 1 && *p == DASM_DISP) mrm = n; continue;
> ^~~~
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #894: TS-4513: Error when building with gcc 6.1.1...
GitHub user bryancall opened a pull request: https://github.com/apache/trafficserver/pull/894 TS-4513: Error when building with gcc 6.1.1 with luajit You can merge this pull request into a Git repository by running: $ git pull https://github.com/bryancall/trafficserver TS-4513 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/894.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 #894 commit 5f91438df0b89865386374ec1363ad8edb2b11cb Author: Bryan Call Date: 2016-08-22T23:11:14Z TS-4513: Error when building with gcc 6.1.1 with luajit --- 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 pull request #893: TS-4581 CID 1356973 dead code in proxy/hdrs...
GitHub user ngara opened a pull request: https://github.com/apache/trafficserver/pull/893 TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.cc You can merge this pull request into a Git repository by running: $ git pull https://github.com/ngara/trafficserver TS-4581 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/893.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 #893 commit 6cc8fbd1b267324d86db17e1ff8e6a3ece7b2772 Author: Nathan Garabedian Date: 2016-06-24T22:13:46Z TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.cc --- 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-4581) CID 1356973 dead code in proxy/hdrs/HTTP.cc
[ https://issues.apache.org/jira/browse/TS-4581?focusedWorklogId=26825&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26825 ] ASF GitHub Bot logged work on TS-4581: -- Author: ASF GitHub Bot Created on: 22/Aug/16 22:51 Start Date: 22/Aug/16 22:51 Worklog Time Spent: 10m Work Description: GitHub user ngara opened a pull request: https://github.com/apache/trafficserver/pull/893 TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.cc You can merge this pull request into a Git repository by running: $ git pull https://github.com/ngara/trafficserver TS-4581 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/893.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 #893 commit 6cc8fbd1b267324d86db17e1ff8e6a3ece7b2772 Author: Nathan Garabedian Date: 2016-06-24T22:13:46Z TS-4581 CID 1356973 dead code in proxy/hdrs/HTTP.cc Issue Time Tracking --- Worklog Id: (was: 26825) Time Spent: 10m Remaining Estimate: 0h > CID 1356973 dead code in proxy/hdrs/HTTP.cc > --- > > Key: TS-4581 > URL: https://issues.apache.org/jira/browse/TS-4581 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Nathan Garabedian >Assignee: Nathan Garabedian > Fix For: 7.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > 1069 > notnull: At condition url_start, the value of url_start cannot be NULL. > dead_error_condition: The condition !url_start cannot be true. > notnull: At condition url_end, the value of url_end cannot be NULL. > dead_error_condition: The condition !url_end cannot be true. > 1070if (!url_start || !url_end) > > CID 1356973 (#1 of 1): Logically dead code (DEADCODE) > dead_error_line: Execution cannot reach this statement: return PARSE_ERROR;. > 1071 return PARSE_ERROR; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4475) Crash in Log-Collation client after using inactivity-cop.
[
https://issues.apache.org/jira/browse/TS-4475?focusedWorklogId=26824&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26824
]
ASF GitHub Bot logged work on TS-4475:
--
Author: ASF GitHub Bot
Created on: 22/Aug/16 22:47
Start Date: 22/Aug/16 22:47
Worklog Time Spent: 10m
Work Description: Github user pbchou commented on the issue:
https://github.com/apache/trafficserver/pull/831
@shinrich @oknet -- Please see the updated PR. I added the same event
handling to the host side. I also added two records.config options to make the
time-out configurable on the host and client sides respectively. The default
time-out of 86400s just corresponds to the default
proxy.config.net.default_inactivity_timeout with a default configuration file.
Issue Time Tracking
---
Worklog Id: (was: 26824)
Time Spent: 1h 40m (was: 1.5h)
> Crash in Log-Collation client after using inactivity-cop.
> -
>
> Key: TS-4475
> URL: https://issues.apache.org/jira/browse/TS-4475
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 6.1.1
>Reporter: Peter Chou
> Fix For: sometime
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Background: We recently tried making use of inactivity-cop by setting it to
> 300s instead of the default one-day setting. This was to address an issue
> where, under heavy load, ATS would become un-responsive to client requests,
> and the condition would persist after traffic was stopped with the active
> queue saying 0 connections but 'netstat -na' showing a bunch of established
> connections (up to the throttle limit approximately).
> Inactivity cop seemed to help ATS handle this situation, but we have since
> experienced a couple of core dumps over the last four day period. It seems
> occasionally the Log Collation Client State Machine will have event value 105
> or VC_EVENT_INACTIVITY_TIMEOUT, but when it reaches read_signal_and_update()
> it tries to call the continuation handler which down the line does not know
> about this event thus causing core dump !"unexpcted state" [sic].
> Here is the back-trace --
> (gdb) bt
> #0 0x2b67cd5405f7 in raise () from /lib64/libc.so.6
> #1 0x2b67cd541e28 in abort () from /lib64/libc.so.6
> #2 0x2b67cb032921 in ink_die_die_die () at ink_error.cc:43
> #3 0x2b67cb0329da in ink_fatal_va (fmt=0x2b67cb0442dc "%s:%d: failed
> assert `%s`", ap=0x7ffc690e7ba8) at ink_error.cc:65
> #4 0x2b67cb032a79 in ink_fatal (message_format=0x2b67cb0442dc "%s:%d:
> failed assert `%s`") at ink_error.cc:73
> #5 0x2b67cb0305a6 in _ink_assert (expression=0x7fb422 "!\"unexpcted
> state\"", file=0x7fb35b "LogCollationClientSM.cc",
> line=445) at ink_assert.cc:37
> #6 0x0069c86b in LogCollationClientSM::client_idle
> (this=0x2b681400bb00, event=105) at LogCollationClientSM.cc:445
> #7 0x0069b427 in LogCollationClientSM::client_handler
> (this=0x2b681400bb00, event=105, data=0x2b680c017020)
> at LogCollationClientSM.cc:119
> #8 0x00502cc6 in Continuation::handleEvent (this=0x2b681400bb00,
> event=105, data=0x2b680c017020)
> at ../iocore/eventsystem/I_Continuation.h:153
> #9 0x00783d40 in read_signal_and_update (event=105,
> vc=0x2b680c016f00) at UnixNetVConnection.cc:150
> #10 0x00787a22 in UnixNetVConnection::mainEvent (this=0x2b680c016f00,
> event=1, e=0x127ad60) at UnixNetVConnection.cc:1188
> #11 0x00502cc6 in Continuation::handleEvent (this=0x2b680c016f00,
> event=1, data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x0077d943 in InactivityCop::check_inactivity (this=0x1209a00,
> event=2, e=0x127ad60) at UnixNet.cc:102
> #13 0x00502cc6 in Continuation::handleEvent (this=0x1209a00, event=2,
> data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #14 0x007a5df6 in EThread::process_event (this=0x2b67cf7bb010,
> e=0x127ad60, calling_code=2) at UnixEThread.cc:128
> #15 0x007a61f5 in EThread::execute (this=0x2b67cf7bb010) at
> UnixEThread.cc:207
> #16 0x00534430 in main (argv=0x7ffc690e82e8) at Main.cc:1918
> I believe it takes a wrong turn here --
> #9 0x00783d40 in read_signal_and_update (event=105,
> vc=0x2b680c016f00) at UnixNetVConnection.cc:150
> 150 vc->read.vio._cont->handleEvent(event, &vc->read.vio);
> (gdb) list
> 145 static inline int
> 146 read_signal_and_update(int event, UnixNetVConnection *vc)
> 147 {
> 148 vc->recursion++;
> 149 if (vc->read.vio._cont) {
> 150 vc->read.vio._cont->handleEvent(event, &vc->read.vio);
> 151 } else {
> 152 switch (event) {
> 153 case VC_EVENT_EOS
[GitHub] trafficserver issue #831: TS-4475: Log Collation Client SM, added VC_EVENT_I...
Github user pbchou commented on the issue: https://github.com/apache/trafficserver/pull/831 @shinrich @oknet -- Please see the updated PR. I added the same event handling to the host side. I also added two records.config options to make the time-out configurable on the host and client sides respectively. The default time-out of 86400s just corresponds to the default proxy.config.net.default_inactivity_timeout with a default configuration file. --- 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-4724) Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" to remove host name from the GET request send to next tier
[ https://issues.apache.org/jira/browse/TS-4724?focusedWorklogId=26819&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26819 ] ASF GitHub Bot logged work on TS-4724: -- Author: ASF GitHub Bot Created on: 22/Aug/16 21:42 Start Date: 22/Aug/16 21:42 Worklog Time Spent: 10m Work Description: Github user shukitchan commented on the issue: https://github.com/apache/trafficserver/pull/859 I think it makes sense. Just make it look similar to "client_request". I think we can close this one. And please change the title on the jira and open a new pull request with the changes on just ts_lua plugin's "server_request" APIs. Thanks a lot. Issue Time Tracking --- Worklog Id: (was: 26819) Time Spent: 2h 50m (was: 2h 40m) > Adding/creating new lua API "ts.server_request.remove_host_name_from_url()" > to remove host name from the GET request send to next tier > -- > > Key: TS-4724 > URL: https://issues.apache.org/jira/browse/TS-4724 > Project: Traffic Server > Issue Type: Improvement > Components: Lua >Reporter: Rajendra Kishore Bonumahanti > Fix For: 7.0.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Create a new lua API "ts.server_request.remove_host_name_from_url()" to > remove host name from the GET request to next tier. This helps to have a > parent remap.config entry similar to child cache. This makes provisioning > more meaningful and easy at both parent and child. > With this fix, the GET request to parent will change.. > from: > + Proxy's Request + > -- State Machine Id: 5593 > GET http://origin.com/dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > To: > + Proxy's Request + > -- State Machine Id: 5593 > GET /dir1/a.txt HTTP/1.1^M > User-Agent: curl/7.29.0^M > Host: abc.com^M > Accept: */*^M > Client-ip: 135.xx.xx.xx^M > X-Forwarded-For: 135.xx.xx.xx^M > This will enable to have parent and child's remap.config entries as below: > map http://abc.com http://origin.com @plugin=tslua.so > @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #859: TS-4724: Modified ts_lua plugin to provide ts.serv...
Github user shukitchan commented on the issue: https://github.com/apache/trafficserver/pull/859 I think it makes sense. Just make it look similar to "client_request". I think we can close this one. And please change the title on the jira and open a new pull request with the changes on just ts_lua plugin's "server_request" APIs. Thanks a lot. --- 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. ---
