[jira] [Commented] (TS-2783) Automated verification of defaults (config vs. code)
[ https://issues.apache.org/jira/browse/TS-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010847#comment-14010847 ] Piotr Buliński commented on TS-2783: I've fixed an issue in the verifier, so now it shows proper result. Additionally now, by default, only-missing reports are hidden and can be enabled with -m or --report-missing flag. Please find diff-only report against latest master here: https://gist.github.com/piotrbulinski/9396189#file-ats_report-2014-05-28-txt (47 entries with defaults differences). Should we include the tool in ATS source and maintain it there? Automated verification of defaults (config vs. code) Key: TS-2783 URL: https://issues.apache.org/jira/browse/TS-2783 Project: Traffic Server Issue Type: Improvement Components: Configuration, Documentation Reporter: Piotr Buliński Assignee: Bryan Call Fix For: 5.0.0 There are cases where documentation states different defaults than they are actually used in code. I will work on some automated mechanism verifying that, so we can keep easily code and docs in sync with each release. Additionally it should show: - missing configuration parameters in docs, - unused configuration parameters in code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2839) tsxs doesn't work on OSX
[
https://issues.apache.org/jira/browse/TS-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011159#comment-14011159
]
Masakazu Kitajo commented on TS-2839:
-
Hi James,
Which ld are you using? At least, my TWO environment, my personal environment
and a n environment for work, need my patch.
tsxs doesn't work on OSX
Key: TS-2839
URL: https://issues.apache.org/jira/browse/TS-2839
Project: Traffic Server
Issue Type: Improvement
Components: Tools
Reporter: Masakazu Kitajo
Assignee: Leif Hedstrom
Fix For: 5.0.0
When I specify -L option to tsxs on OS X, I get these error messages below.
{noformat}
$ tsxs -L/somewhere/lib -o test.so test.cc
compiling test.cc - test.lo
linking - test.so
ld: warning: directory not found for option '-L/somewhere/lib'
ld: unknown option: --rpath=/somewhere/lib
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
tsxs: link failed: cc -bundle -flat_namespace -undefined suppress
-L/somewhere/lib -Wl,--rpath=/somewhere/lib -o test.so test.lo
{noformat}
It seems that two dashes and a equal sign for rpath are not supported on OS
X's ld.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2783) Automated verification of defaults (config vs. code)
[ https://issues.apache.org/jira/browse/TS-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011167#comment-14011167 ] James Peach commented on TS-2783: - How is your tool different from the tools we already have that I mentioned above? Automated verification of defaults (config vs. code) Key: TS-2783 URL: https://issues.apache.org/jira/browse/TS-2783 Project: Traffic Server Issue Type: Improvement Components: Configuration, Documentation Reporter: Piotr Buliński Assignee: Bryan Call Fix For: 5.0.0 There are cases where documentation states different defaults than they are actually used in code. I will work on some automated mechanism verifying that, so we can keep easily code and docs in sync with each release. Additionally it should show: - missing configuration parameters in docs, - unused configuration parameters in code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2839) tsxs doesn't work on OSX
[
https://issues.apache.org/jira/browse/TS-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011166#comment-14011166
]
James Peach commented on TS-2839:
-
I'm using the Darwin ld from Xcode 5.0.1
tsxs doesn't work on OSX
Key: TS-2839
URL: https://issues.apache.org/jira/browse/TS-2839
Project: Traffic Server
Issue Type: Improvement
Components: Tools
Reporter: Masakazu Kitajo
Assignee: Leif Hedstrom
Fix For: 5.0.0
When I specify -L option to tsxs on OS X, I get these error messages below.
{noformat}
$ tsxs -L/somewhere/lib -o test.so test.cc
compiling test.cc - test.lo
linking - test.so
ld: warning: directory not found for option '-L/somewhere/lib'
ld: unknown option: --rpath=/somewhere/lib
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
tsxs: link failed: cc -bundle -flat_namespace -undefined suppress
-L/somewhere/lib -Wl,--rpath=/somewhere/lib -o test.so test.lo
{noformat}
It seems that two dashes and a equal sign for rpath are not supported on OS
X's ld.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2839) tsxs doesn't work on OSX
[
https://issues.apache.org/jira/browse/TS-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2839.
---
Resolution: Fixed
tsxs doesn't work on OSX
Key: TS-2839
URL: https://issues.apache.org/jira/browse/TS-2839
Project: Traffic Server
Issue Type: Improvement
Components: Tools
Reporter: Masakazu Kitajo
Assignee: Leif Hedstrom
Fix For: 5.0.0
When I specify -L option to tsxs on OS X, I get these error messages below.
{noformat}
$ tsxs -L/somewhere/lib -o test.so test.cc
compiling test.cc - test.lo
linking - test.so
ld: warning: directory not found for option '-L/somewhere/lib'
ld: unknown option: --rpath=/somewhere/lib
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
tsxs: link failed: cc -bundle -flat_namespace -undefined suppress
-L/somewhere/lib -Wl,--rpath=/somewhere/lib -o test.so test.lo
{noformat}
It seems that two dashes and a equal sign for rpath are not supported on OS
X's ld.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2839) tsxs doesn't work on OSX
[
https://issues.apache.org/jira/browse/TS-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011171#comment-14011171
]
Leif Hedstrom commented on TS-2839:
---
The issue is only if you do tsxs -L ... . Ive fixed it (again) as per
Masakazu's suggestions.
tsxs doesn't work on OSX
Key: TS-2839
URL: https://issues.apache.org/jira/browse/TS-2839
Project: Traffic Server
Issue Type: Improvement
Components: Tools
Reporter: Masakazu Kitajo
Assignee: Leif Hedstrom
Fix For: 5.0.0
When I specify -L option to tsxs on OS X, I get these error messages below.
{noformat}
$ tsxs -L/somewhere/lib -o test.so test.cc
compiling test.cc - test.lo
linking - test.so
ld: warning: directory not found for option '-L/somewhere/lib'
ld: unknown option: --rpath=/somewhere/lib
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
tsxs: link failed: cc -bundle -flat_namespace -undefined suppress
-L/somewhere/lib -Wl,--rpath=/somewhere/lib -o test.so test.lo
{noformat}
It seems that two dashes and a equal sign for rpath are not supported on OS
X's ld.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2618) IOBufferBlock::realloc()'s bounds check is wrong
[
https://issues.apache.org/jira/browse/TS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2618:
--
Fix Version/s: (was: 5.1.0)
5.0.0
IOBufferBlock::realloc()'s bounds check is wrong
Key: TS-2618
URL: https://issues.apache.org/jira/browse/TS-2618
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Assignee: William Bardwell
Fix For: 5.0.0
Presumably this never fires, but:
{code}
if (i = (int64_t) sizeof(ioBufAllocator))
return;
{code}
looks wrong, it looks like i is an index into that array, so it should be
{code}
i = SIZE(ioBufAllocator))
{code}
(SIZE() from ink_defs.h)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2618) IOBufferBlock::realloc()'s bounds check is wrong
[
https://issues.apache.org/jira/browse/TS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011212#comment-14011212
]
ASF subversion and git services commented on TS-2618:
-
Commit 3e35848dc793aec663d03faa56080c7d03d6fd9b in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3e35848 ]
TS-2618] IOBufferBlock::realloc()'s bounds check is wrong.
Original suggestions from William Bardwell.
IOBufferBlock::realloc()'s bounds check is wrong
Key: TS-2618
URL: https://issues.apache.org/jira/browse/TS-2618
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Assignee: William Bardwell
Fix For: 5.0.0
Presumably this never fires, but:
{code}
if (i = (int64_t) sizeof(ioBufAllocator))
return;
{code}
looks wrong, it looks like i is an index into that array, so it should be
{code}
i = SIZE(ioBufAllocator))
{code}
(SIZE() from ink_defs.h)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2618) IOBufferBlock::realloc()'s bounds check is wrong
[
https://issues.apache.org/jira/browse/TS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2618:
-
Assignee: Leif Hedstrom (was: William Bardwell)
IOBufferBlock::realloc()'s bounds check is wrong
Key: TS-2618
URL: https://issues.apache.org/jira/browse/TS-2618
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Assignee: Leif Hedstrom
Fix For: 5.0.0
Presumably this never fires, but:
{code}
if (i = (int64_t) sizeof(ioBufAllocator))
return;
{code}
looks wrong, it looks like i is an index into that array, so it should be
{code}
i = SIZE(ioBufAllocator))
{code}
(SIZE() from ink_defs.h)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2618) IOBufferBlock::realloc()'s bounds check is wrong
[
https://issues.apache.org/jira/browse/TS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2618.
---
Resolution: Fixed
IOBufferBlock::realloc()'s bounds check is wrong
Key: TS-2618
URL: https://issues.apache.org/jira/browse/TS-2618
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Assignee: William Bardwell
Fix For: 5.0.0
Presumably this never fires, but:
{code}
if (i = (int64_t) sizeof(ioBufAllocator))
return;
{code}
looks wrong, it looks like i is an index into that array, so it should be
{code}
i = SIZE(ioBufAllocator))
{code}
(SIZE() from ink_defs.h)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2839) tsxs doesn't work on OSX
[
https://issues.apache.org/jira/browse/TS-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011215#comment-14011215
]
James Peach commented on TS-2839:
-
It still looks wrong. The correct arguments to {{cc}} would be {{-Wl,-rpath
-Wl,/lib/path}}.
tsxs doesn't work on OSX
Key: TS-2839
URL: https://issues.apache.org/jira/browse/TS-2839
Project: Traffic Server
Issue Type: Improvement
Components: Tools
Reporter: Masakazu Kitajo
Assignee: Leif Hedstrom
Fix For: 5.0.0
When I specify -L option to tsxs on OS X, I get these error messages below.
{noformat}
$ tsxs -L/somewhere/lib -o test.so test.cc
compiling test.cc - test.lo
linking - test.so
ld: warning: directory not found for option '-L/somewhere/lib'
ld: unknown option: --rpath=/somewhere/lib
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
tsxs: link failed: cc -bundle -flat_namespace -undefined suppress
-L/somewhere/lib -Wl,--rpath=/somewhere/lib -o test.so test.lo
{noformat}
It seems that two dashes and a equal sign for rpath are not supported on OS
X's ld.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2839) tsxs doesn't work on OSX
[
https://issues.apache.org/jira/browse/TS-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011237#comment-14011237
]
Leif Hedstrom commented on TS-2839:
---
it works with Masakazu's patch ...
tsxs doesn't work on OSX
Key: TS-2839
URL: https://issues.apache.org/jira/browse/TS-2839
Project: Traffic Server
Issue Type: Improvement
Components: Tools
Reporter: Masakazu Kitajo
Assignee: Leif Hedstrom
Fix For: 5.0.0
When I specify -L option to tsxs on OS X, I get these error messages below.
{noformat}
$ tsxs -L/somewhere/lib -o test.so test.cc
compiling test.cc - test.lo
linking - test.so
ld: warning: directory not found for option '-L/somewhere/lib'
ld: unknown option: --rpath=/somewhere/lib
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
tsxs: link failed: cc -bundle -flat_namespace -undefined suppress
-L/somewhere/lib -Wl,--rpath=/somewhere/lib -o test.so test.lo
{noformat}
It seems that two dashes and a equal sign for rpath are not supported on OS
X's ld.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2839) tsxs doesn't work on OSX
[
https://issues.apache.org/jira/browse/TS-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011252#comment-14011252
]
ASF subversion and git services commented on TS-2839:
-
Commit 8a2166ab71d0178f43baa6b63daaa3f83344c08f in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8a2166a ]
TS-2839 Additional fix for tsxs. I'm not sure if this
will break on gnu ld, but it works with XCode ld.
Suggestions from James Peach.
tsxs doesn't work on OSX
Key: TS-2839
URL: https://issues.apache.org/jira/browse/TS-2839
Project: Traffic Server
Issue Type: Improvement
Components: Tools
Reporter: Masakazu Kitajo
Assignee: Leif Hedstrom
Fix For: 5.0.0
When I specify -L option to tsxs on OS X, I get these error messages below.
{noformat}
$ tsxs -L/somewhere/lib -o test.so test.cc
compiling test.cc - test.lo
linking - test.so
ld: warning: directory not found for option '-L/somewhere/lib'
ld: unknown option: --rpath=/somewhere/lib
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
tsxs: link failed: cc -bundle -flat_namespace -undefined suppress
-L/somewhere/lib -Wl,--rpath=/somewhere/lib -o test.so test.lo
{noformat}
It seems that two dashes and a equal sign for rpath are not supported on OS
X's ld.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011447#comment-14011447
]
Sudheer Vinukonda commented on TS-2842:
---
Note: I had to duplicate a structure between HttpConfig.h and SpdyCommon.h to
be able to get it to compile. Didn't want to make too many changes, since 5.0
is really close - If it is acceptable, will work on cleaning up the spdy config
once 5.0 is cut.
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011460#comment-14011460
]
James Peach commented on TS-2842:
-
Nack. These are not overridable parameters.
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011478#comment-14011478
]
Leif Hedstrom commented on TS-2842:
---
Agreed. I'd personally prefer not to introduce that new struct, particularly
not with that naming (they are not overridable). The normal way is to simply
add all those new configurations to the appropriate (existing) struct, and
register the update callback for all of them (individually).
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011478#comment-14011478
]
Leif Hedstrom edited comment on TS-2842 at 5/28/14 7:27 PM:
Agreed. I'd personally prefer not to introduce that new struct, particularly
not with that naming (they are not overridable). The normal way is to simply
add all those new configurations to the appropriate (existing) struct, and
register the update callback for all of them (individually).
Also, if the intent is to make these overridable, they should be members of the
existing overridable struct. And then also be added to InkAPI.cc, ts/ts.h as
well as InkAPITest.cc.
was (Author: zwoop):
Agreed. I'd personally prefer not to introduce that new struct, particularly
not with that naming (they are not overridable). The normal way is to simply
add all those new configurations to the appropriate (existing) struct, and
register the update callback for all of them (individually).
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011496#comment-14011496
]
James Peach commented on TS-2842:
-
These are all integral values, so you don't need a struct to hold them or
anything fancy; just use the records API to link them to the config update.
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2783) Automated verification of defaults (config vs. code)
[ https://issues.apache.org/jira/browse/TS-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011520#comment-14011520 ] Piotr Buliński commented on TS-2783: I think I missed something while looking at the output of the existing script in the first place. It actually shows the same information. No need to include my script then. Then there would be only a question: does it make sense to put all the descriptions into the C code/comments and generate RST doc out of it? Automated verification of defaults (config vs. code) Key: TS-2783 URL: https://issues.apache.org/jira/browse/TS-2783 Project: Traffic Server Issue Type: Improvement Components: Configuration, Documentation Reporter: Piotr Buliński Assignee: Bryan Call Fix For: 5.0.0 There are cases where documentation states different defaults than they are actually used in code. I will work on some automated mechanism verifying that, so we can keep easily code and docs in sync with each release. Additionally it should show: - missing configuration parameters in docs, - unused configuration parameters in code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2851) Cleanup iobuffer index types
Leif Hedstrom created TS-2851: - Summary: Cleanup iobuffer index types Key: TS-2851 URL: https://issues.apache.org/jira/browse/TS-2851 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Unfortunately (my bad...) we use int64_t's for various index types / parameters for iobuffers. This makes no sense, in some cases, it ought to just be unsigned, or size_t or some such. The wrinkle here is that (if I recall) that sometimes we overload parameters to mean both indexes (0, 1, 2 etc.) or sizes (if negative). In those cases, if we retain that overloading, we need them to be int64_t's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2851) Cleanup iobuffer index types
[ https://issues.apache.org/jira/browse/TS-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2851: -- Fix Version/s: sometime Cleanup iobuffer index types -- Key: TS-2851 URL: https://issues.apache.org/jira/browse/TS-2851 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Fix For: sometime Unfortunately (my bad...) we use int64_t's for various index types / parameters for iobuffers. This makes no sense, in some cases, it ought to just be unsigned, or size_t or some such. The wrinkle here is that (if I recall) that sometimes we overload parameters to mean both indexes (0, 1, 2 etc.) or sizes (if negative). In those cases, if we retain that overloading, we need them to be int64_t's. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011547#comment-14011547
]
Sudheer Vinukonda commented on TS-2842:
---
[~jpeach], [~zwoop] - thanks for the comments; the patch does fix the reloading
of the params, but, does a little bit more (since, I was playing with that, I
thought I might just do the additional changes, as a base for adding API hooks
for overriding in the future). Anyway, since, you all don't like the extra
changes, I am limiting the changes to a minimum (just support reloading of the
params)
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2842:
--
Attachment: ts2842.diff
Please take a look at the new patch and let me know if you still have concerns.
Appreciate the feedback!
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011570#comment-14011570
]
Bryan Call commented on TS-2842:
Patch looks good. There is a minor formatting issue I can fix up.
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011547#comment-14011547
]
Sudheer Vinukonda edited comment on TS-2842 at 5/28/14 9:38 PM:
[~jpe...@apache.org]], [~zwoop] - thanks for the comments; the patch does fix
the reloading of the params, but, does a little bit more (since, I was playing
with that, I thought I might just do the additional changes, as a base for
adding API hooks for overriding in the future). Anyway, since, you all don't
like the extra changes, I am limiting the changes to a minimum (just support
reloading of the params)
was (Author: sudheerv):
[~jpeach], [~zwoop] - thanks for the comments; the patch does fix the reloading
of the params, but, does a little bit more (since, I was playing with that, I
thought I might just do the additional changes, as a base for adding API hooks
for overriding in the future). Anyway, since, you all don't like the extra
changes, I am limiting the changes to a minimum (just support reloading of the
params)
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011547#comment-14011547
]
Sudheer Vinukonda edited comment on TS-2842 at 5/28/14 9:38 PM:
[~jpe...@apache.org], [~zwoop] - thanks for the comments; the patch does fix
the reloading of the params, but, does a little bit more (since, I was playing
with that, I thought I might just do the additional changes, as a base for
adding API hooks for overriding in the future). Anyway, since, you all don't
like the extra changes, I am limiting the changes to a minimum (just support
reloading of the params)
was (Author: sudheerv):
[~jpe...@apache.org]], [~zwoop] - thanks for the comments; the patch does fix
the reloading of the params, but, does a little bit more (since, I was playing
with that, I thought I might just do the additional changes, as a base for
adding API hooks for overriding in the future). Anyway, since, you all don't
like the extra changes, I am limiting the changes to a minimum (just support
reloading of the params)
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2766) HdrHeap::coalesce_str_heaps doesn't properly calculate new heap size
[ https://issues.apache.org/jira/browse/TS-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2766: --- Assignee: Phil Sorber (was: Brian Geffon) HdrHeap::coalesce_str_heaps doesn't properly calculate new heap size Key: TS-2766 URL: https://issues.apache.org/jira/browse/TS-2766 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 5.0.0 HdrHeap::coalesce_str_heaps doesn't properly calculate the new heap size for a few reasons: 1) It doesn't current walk the HdrHeap chain (m_next). 2) It doesn't account for HdrHeap objects that point to the same string in the HdrStrHeap. The easiest fix for this is to completely walk all of the HdrHeap objects in the chain and sum up the size of every string; obviously this approach means that strings that were previously aliased will now become independent copies on coalesce; however, the alternative solution that allows continued aliasing would be pretty messy. I'm proposing we just properly determine the size but allow the user to minimizing coalescing by making the read only heap sizes configurable and the StrHdrHeap and HdrHeap default sizes configurable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2822: --- Assignee: Phil Sorber (was: Brian Geffon) Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1833) Deprecate TSMimeHdrFieldValueStringInsert() (and family)
[ https://issues.apache.org/jira/browse/TS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1833: -- Fix Version/s: (was: 5.0.0) 6.0.0 Deprecate TSMimeHdrFieldValueStringInsert() (and family) Key: TS-1833 URL: https://issues.apache.org/jira/browse/TS-1833 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 6.0.0 It seems to be that TSMimeHdrFieldValueStringInsert() is really just a subset of TSMimeHdrFieldValueStringSet(). This just makes for confusing APIs, i.e. which one do I use when? The alternative would be to remove the idx argument to the TSMimeHdrFieldValueStringSet() method, but that would then break API and ABI compatibility. Also, as James found out, the docs are less than clear. Set() needs to be called with an idx of -1 for it to actually be a Set() operation. With idx =0, TSMimeHdrFieldValueStringSet() is actually identical to TSMimeHdrFieldValueStringInsert() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2852) BACKPORT - Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2852: Fix Version/s: (was: 5.0.0) 4.2.2 BACKPORT - Crash in LogBufferIterator::next --- Key: TS-2852 URL: https://issues.apache.org/jira/browse/TS-2852 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 4.2.2 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011672#comment-14011672
]
Bryan Call commented on TS-2842:
Tested patch:
{code}
[bcall@mac-bryan-wire trafficserver]$ sudo traffic_line -r
proxy.config.spdy.no_activity_timeout_in
30
[bcall@mac-bryan-wire trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
[bcall@mac-bryan-wire trafficserver]$ sudo traffic_line -r
proxy.config.spdy.no_activity_timeout_in
31
{code}
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-2822. - Resolution: Fixed Crash in LogBufferIterator::next Key: TS-2822 URL: https://issues.apache.org/jira/browse/TS-2822 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 5.0.0 It appears there is a crash in traffic_logstats that's consistently happening in LogBufferIterator::next, a sample stack trace is attached. I'll be looking into the issue. #0 0x00465c1d in LogBufferIterator::next (this=0x7fff435bd7b0) at LogBuffer.cc:813 #1 0x00448fd2 in parse_log_buff (buf_header=0x7fff435bd900, summary=false) at logstats.cc:1234 #2 0x00449660 in process_file (in_fd=8, offset=0, max_age=0) at logstats.cc:1757 #3 0x0044d031 in main (argv=0x7fff435ce1a8) at logstats.cc:2558 It appears the issue is related to logstats.cc::process_file(), the final read when it will read the contents of the log buffer can return a value less than buffer_bytes; and since header is an aliased pointer of buffer, the contents of header and the subsequent buffers can be invalid data, the solution in my opinion would be to loop until all required data has been read before calling parse_log_buff(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2853) BACKPORT - Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2853: Fix Version/s: (was: 5.0.0) 4.2.2 BACKPORT - Websockets remap doesn't properly handle the implicit port for wss. -- Key: TS-2853 URL: https://issues.apache.org/jira/browse/TS-2853 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 4.2.2 When doing remap rules such as: map wss://domain.com/ ..., remap isn't handling the implicit port 443 correctly, the issues is currently resolved by doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2853) BACKPORT - Websockets remap doesn't properly handle the implicit port for wss.
Phil Sorber created TS-2853: --- Summary: BACKPORT - Websockets remap doesn't properly handle the implicit port for wss. Key: TS-2853 URL: https://issues.apache.org/jira/browse/TS-2853 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 5.0.0 When doing remap rules such as: map wss://domain.com/ ..., remap isn't handling the implicit port 443 correctly, the issues is currently resolved by doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2842) Can't set SPDY inactivity timeout with traffic_line
[
https://issues.apache.org/jira/browse/TS-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011677#comment-14011677
]
ASF subversion and git services commented on TS-2842:
-
Commit c25f17c9bef3d5e2fabf6c2b71565966ded8dbb3 in trafficserver's branch
refs/heads/master from [~sudheerv]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c25f17c ]
TS-2842: Can't set SPDY inactivity timeout with traffic_line
Reviewed: Bryan Call
Can't set SPDY inactivity timeout with traffic_line
---
Key: TS-2842
URL: https://issues.apache.org/jira/browse/TS-2842
Project: Traffic Server
Issue Type: Bug
Components: SPDY, Tools
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
Attachments: ts2842.diff
Works for other configuration options:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.http.keep_alive_no_activity_timeout_in -v 61
[bcall@l10 trafficserver]$ sudo traffic_line -r
proxy.config.http.keep_alive_no_activity_timeout_in
61
{code}
Doesn't work for the SPDY inactivity:
{code}
[bcall@l10 trafficserver]$ sudo traffic_line -s
proxy.config.spdy.no_activity_timeout_in -v 31
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2766) HdrHeap::coalesce_str_heaps doesn't properly calculate new heap size
[ https://issues.apache.org/jira/browse/TS-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-2766. - Resolution: Fixed HdrHeap::coalesce_str_heaps doesn't properly calculate new heap size Key: TS-2766 URL: https://issues.apache.org/jira/browse/TS-2766 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 5.0.0 HdrHeap::coalesce_str_heaps doesn't properly calculate the new heap size for a few reasons: 1) It doesn't current walk the HdrHeap chain (m_next). 2) It doesn't account for HdrHeap objects that point to the same string in the HdrStrHeap. The easiest fix for this is to completely walk all of the HdrHeap objects in the chain and sum up the size of every string; obviously this approach means that strings that were previously aliased will now become independent copies on coalesce; however, the alternative solution that allows continued aliasing would be pretty messy. I'm proposing we just properly determine the size but allow the user to minimizing coalescing by making the read only heap sizes configurable and the StrHdrHeap and HdrHeap default sizes configurable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2854) BACKPORT - HdrHeap::coalesce_str_heaps doesn't properly calculate new heap size
[ https://issues.apache.org/jira/browse/TS-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2854: Fix Version/s: (was: 5.0.0) 4.2.2 BACKPORT - HdrHeap::coalesce_str_heaps doesn't properly calculate new heap size --- Key: TS-2854 URL: https://issues.apache.org/jira/browse/TS-2854 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 4.2.2 HdrHeap::coalesce_str_heaps doesn't properly calculate the new heap size for a few reasons: 1) It doesn't current walk the HdrHeap chain (m_next). 2) It doesn't account for HdrHeap objects that point to the same string in the HdrStrHeap. The easiest fix for this is to completely walk all of the HdrHeap objects in the chain and sum up the size of every string; obviously this approach means that strings that were previously aliased will now become independent copies on coalesce; however, the alternative solution that allows continued aliasing would be pretty messy. I'm proposing we just properly determine the size but allow the user to minimizing coalescing by making the read only heap sizes configurable and the StrHdrHeap and HdrHeap default sizes configurable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1833) Deprecate TSMimeHdrFieldValueStringInsert() (and family)
[ https://issues.apache.org/jira/browse/TS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011678#comment-14011678 ] Leif Hedstrom commented on TS-1833: --- I moved all this out to 6.0.0, but added a small comment to the include file. Deprecate TSMimeHdrFieldValueStringInsert() (and family) Key: TS-1833 URL: https://issues.apache.org/jira/browse/TS-1833 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 6.0.0 It seems to be that TSMimeHdrFieldValueStringInsert() is really just a subset of TSMimeHdrFieldValueStringSet(). This just makes for confusing APIs, i.e. which one do I use when? The alternative would be to remove the idx argument to the TSMimeHdrFieldValueStringSet() method, but that would then break API and ABI compatibility. Also, as James found out, the docs are less than clear. Set() needs to be called with an idx of -1 for it to actually be a Set() operation. With idx =0, TSMimeHdrFieldValueStringSet() is actually identical to TSMimeHdrFieldValueStringInsert() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2778) Websockets remap doesn't properly handle the implicit port for wss.
[ https://issues.apache.org/jira/browse/TS-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber resolved TS-2778. - Resolution: Fixed Websockets remap doesn't properly handle the implicit port for wss. --- Key: TS-2778 URL: https://issues.apache.org/jira/browse/TS-2778 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.2.1, 5.0.0 Reporter: Brian Geffon Assignee: Phil Sorber Fix For: 5.0.0 When doing remap rules such as: map wss://domain.com/ ..., remap isn't handling the implicit port 443 correctly, the issues is currently resolved by doing: map wss://domain.com:443/; however, this shouldn't be necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2837) Dangling pointer in URLImpl which may cause core dump
[
https://issues.apache.org/jira/browse/TS-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011690#comment-14011690
]
ASF subversion and git services commented on TS-2837:
-
Commit f4e9fd61953de3647351aa0ccb2775091cdbf701 in trafficserver's branch
refs/heads/master from [~Kang Li]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f4e9fd6 ]
TS-2837: Dangling pointer in URLImpl which may cause core dump
Reviewed: Bryan Call
Dangling pointer in URLImpl which may cause core dump
-
Key: TS-2837
URL: https://issues.apache.org/jira/browse/TS-2837
Project: Traffic Server
Issue Type: Bug
Components: HTTP, Logging
Affects Versions: 4.0.2
Reporter: kang li
Assignee: Bryan Call
Labels: crash, yahoo
Fix For: 5.0.0
Attachments: ts-2837.diff
There were core dump shows that URLImpl::m_ptr_printed_string was out of
bound.
{code}
#0 ink_strlcpy (dst=value optimized out, src=0x2b64901a79a4 Address
0x2b64901a79a4 out of bounds, siz=value optimized out)
at ink_string.cc:226
#1 0x0058d820 in LogAccessHttp::init (this=0x2b631752da20) at
LogAccessHttp.cc:96
#2 0x0058a96f in resolve_logfield_string (context=0x2b631752da20,
format_str=0x3468e10 !DOCTYPE html\nhtml lang=\en-us\head\nmeta
http-equiv=\content-type\ content=\text/html; charset=UTF-8\\nmeta
charset=\utf-8\\ntitleYahoo/title\nmeta name=\viewport\
content=\wid...) at LogAccess.cc:1396
#3 0x00508fed in HttpBodyTemplate::build_instantiated_buffer
(this=0x3468de0, context=value optimized out,
buflen_return=0x2b63e2c42068) at HttpBodyFactory.cc:1015
#4 0x00509ea4 in HttpBodyFactory::fabricate (this=value optimized
out, acpt_language_list=0x2b631752e130,
acpt_charset_list=0x2b631752dfd0, type=0x6d2c3d connect#failed_connect,
context=0x2b63e2c416d8, buffer_length_return=0x2b63e2c42068,
content_language_return=0x2b631752e2a8,
content_charset_return=0x2b631752e2a0, set_return=0x2b631752e298) at
HttpBodyFactory.cc:451
#5 0x0050b1b7 in HttpBodyFactory::fabricate_with_old_api(const char
*,
HttpTransact::State *, int64_t, int64_t *, char *, size_t, char *, size_t,
const char *, typedef __va_list_tag __va_list_tag *) (this=0x344e850,
type=0x6d2c3d connect#failed_connect,
context=0x2b63e2c416d8, max_buffer_length=8192,
resulting_buffer_length=0x2b63e2c42068,
content_language_out_buf=0x2b631752e460
en,
content_language_buf_size=256, content_type_out_buf=0x2b631752e360
text/html, content_type_buf_size=256,
format=0x6ce288 internal error - server connection terminated,
ap=0x2b631752e590) at HttpBodyFactory.cc:137
#6 0x0054cd74 in HttpTransact::build_error_response
(s=0x2b63e2c416d8,
status_code=HTTP_STATUS_BAD_GATEWAY,
reason_phrase_or_null=0x6ce288 internal error - server connection
terminated, error_body_type=value optimized out,
format=0x6ce288 internal error - server connection terminated) at
HttpTransact.cc:7998
#7 0x00551b42 in HttpTransact::handle_server_connection_not_open
(s=0x2b63e2c416d8) at HttpTransact.cc:3719
#8 0x00562f31 in HttpTransact::HandleResponse (s=0x2b63e2c416d8) at
HttpTransact.cc:3180
#9 0x0051c588 in HttpSM::call_transact_and_set_next_state
(this=0x2b63e2c41670, f=value optimized out) at HttpSM.cc:6817
#10 0x00531f89 in HttpSM::state_http_server_open (this=0x2b63e2c41670,
event=201, data=0xff9d) at HttpSM.cc:1712
#11 0x00530b38 in HttpSM::main_handler (this=0x2b63e2c41670,
event=201,
data=0xff9d) at HttpSM.cc:2548
#12 0x006878ec in handleEvent (this=0x2b64ac19f870, t=0x2b6315111010)
at ../../iocore/eventsystem/I_Continuation.h:146
#13 UnixNetVConnection::connectUp (this=0x2b64ac19f870, t=0x2b6315111010) at
UnixNetVConnection.cc:1104
#14 0x006849ca in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=value optimized out,
target=value optimized out, opt=0x2b631752f990) at
UnixNetProcessor.cc:250
#15 0x005314ae in connect_re (this=0x2b63e2c41670, raw=value
optimized
out) at ../../iocore/net/P_UnixNetProcessor.h:89
#16 HttpSM::do_http_server_open (this=0x2b63e2c41670, raw=value optimized
out) at HttpSM.cc:4676
#17 0x00536446 in HttpSM::set_next_state (this=0x2b63e2c41670) at
HttpSM.cc:7006
#18 0x005371ef in HttpSM::state_send_server_request_header
(this=0x2b63e2c41670, event=104, data=0x2b64144c7e28) at HttpSM.cc:2008
#19 0x00530b38 in HttpSM::main_handler (this=0x2b63e2c41670,
event=104,
data=0x2b64144c7e28) at HttpSM.cc:2548
#20 0x006872a1 in handleEvent (event=value optimized out,
nh=0x2b6315114e20, vc=0x2b64144c7d20)
[jira] [Commented] (TS-2783) Automated verification of defaults (config vs. code)
[ https://issues.apache.org/jira/browse/TS-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011722#comment-14011722 ] Bryan Call commented on TS-2783: From reading the bug and running contrib/python/compare_RecordsConfigcc.py it looks like only the documentation needs to be updated for the 5.0 release. There are a lot of configuration option defaults that are incorrect in the documentation. Automated verification of defaults (config vs. code) Key: TS-2783 URL: https://issues.apache.org/jira/browse/TS-2783 Project: Traffic Server Issue Type: Improvement Components: Configuration, Documentation Reporter: Piotr Buliński Assignee: Bryan Call Fix For: 5.0.0 There are cases where documentation states different defaults than they are actually used in code. I will work on some automated mechanism verifying that, so we can keep easily code and docs in sync with each release. Additionally it should show: - missing configuration parameters in docs, - unused configuration parameters in code. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2855) add TSHttpIsInternalSession API
[
https://issues.apache.org/jira/browse/TS-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2855:
Fix Version/s: 5.0.0
Assignee: James Peach
Labels: api-addition (was: )
add TSHttpIsInternalSession API
---
Key: TS-2855
URL: https://issues.apache.org/jira/browse/TS-2855
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: James Peach
Assignee: James Peach
Labels: api-addition
Fix For: 5.0.0
We need to have a {{TSHttpIsInternalSession}} counterpart to
{{TSHttpIsInternalRequest}}. The {{tcpinfo}} plugin will use this to ignore
internally generated requests.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2855) add TSHttpIsInternalSession API
James Peach created TS-2855:
---
Summary: add TSHttpIsInternalSession API
Key: TS-2855
URL: https://issues.apache.org/jira/browse/TS-2855
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: James Peach
We need to have a {{TSHttpIsInternalSession}} counterpart to
{{TSHttpIsInternalRequest}}. The {{tcpinfo}} plugin will use this to ignore
internally generated requests.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-2670) trafficserver process dies with SEGFAULT (failed assert `masksum == mh-m_presence_bits`)
[
https://issues.apache.org/jira/browse/TS-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call closed TS-2670.
--
Resolution: Duplicate
Fix Version/s: (was: 5.0.0)
[~amc] believes this is related to TS-2564.
Make sure you clear your cache with:
sudo /usr/local/bin/traffic_server -Cclear
trafficserver process dies with SEGFAULT (failed assert `masksum ==
mh-m_presence_bits`)
-
Key: TS-2670
URL: https://issues.apache.org/jira/browse/TS-2670
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Timur Irmatov
Assignee: Bryan Call
I have upgraded our installation of TrafficServer from 4.1.2 to 4.2.0. ATS is
running as a forward proxy (to save internet bandwidth). As soon as traffic
grows to our normal levels ATS crashes because of segmentation fault:
{noformat}
[ET_NET 0][11682]: segfault at 1c ip 005c2d50 sp 7fff35b5a168
error 4 in traffic_server[40+35f000]
{noformat}
I have recompiled ATS with --enable-debug. Then ATS dies with failed
assertion:
{noformat}
traffic_server[4003]: FATAL: MIME.cc:599: failed assert `masksum ==
mh-m_presence_bits`
{noformat}
Stack trace:
{noformat}
% sudo gdb /opt/ts/bin/traffic_server /opt/ts/core
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /opt/ts/bin/traffic_server...done.
warning: core file may not match specified executable file.
[New LWP 4003]
[New LWP 4004]
[New LWP 4021]
[New LWP 4022]
[New LWP 4023]
[New LWP 4024]
[New LWP 4025]
[New LWP 4026]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `/opt/ts/bin/traffic_server -M --httpport
3129:fd=7:tr-full'.
Program terminated with signal 6, Aborted.
#0 0x2b222a363f77 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x2b222a363f77 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x2b222a3675e8 in __GI_abort () at abort.c:90
#2 0x2b222830d25e in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x2b222830d349 in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1, message_format=0x2b222831b6c8
%s:%d: failed assert `%s`, ap=0x7fff793cc408)
at ink_error.cc:65
#4 0x2b222830d3f4 in ink_fatal (return_code=1,
message_format=0x2b222831b6c8 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x2b222830bf37 in _ink_assert (expression=0x7409e8 masksum ==
mh-m_presence_bits, file=0x74075f MIME.cc, line=599) at ink_assert.cc:37
#6 0x006127cd in mime_hdr_sanity_check (mh=0x2b2233aeb588) at
MIME.cc:599
#7 0x006140fa in mime_hdr_copy_onto (s_mh=0x2b2233aeb588,
s_heap=0x2b2233aeb4d0, d_mh=0x2b2233a138c8, d_heap=0x2b2233a13810,
inherit_strs=false) at MIME.cc:1102
#8 0x00606a0e in http_hdr_copy_onto (s_hh=0x2b2233aeb558,
s_heap=0x2b2233aeb4d0, d_hh=0x2b2233a13898, d_heap=0x2b2233a13810,
inherit_strs=true) at HTTP.cc:357
#9 0x00606a7f in http_hdr_clone (s_hh=0x2b2233aeb558,
s_heap=0x2b2233aeb4d0, d_heap=0x2b2233a13810) at HTTP.cc:375
#10 0x005086ce in HTTPHdr::copy (this=0x2765bb0, hdr=0x2b2233aeaea8)
at ./hdrs/HTTP.h:866
#11 0x00508dba in HTTPInfo::response_set (this=0x2b22339f3868,
resp=0x2b2233aeaea8) at ./hdrs/HTTP.h:1403
#12 0x0059ccf4 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b22339f3800) at
HttpTransact.cc:4657
#13 0x0059bde6 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b22339f3800) at HttpTransact.cc:4463
#14 0x00599cf6 in HttpTransact::handle_forward_server_connection_open
(s=0x2b22339f3800) at HttpTransact.cc:3966
#15 0x00598440 in HttpTransact::handle_response_from_server
(s=0x2b22339f3800) at HttpTransact.cc:3643
#16 0x00596e28 in HttpTransact::HandleResponse (s=0x2b22339f3800) at
HttpTransact.cc:3334
#17 0x0057d4f1 in HttpSM::call_transact_and_set_next_state
(this=0x2b22339f3790, f=0x0) at HttpSM.cc:6779
#18 0x0056a7f3 in HttpSM::handle_api_return (this=0x2b22339f3790) at
[jira] [Updated] (TS-2357) Add option to cache POST requests
[ https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2357: --- Attachment: ts-2357.diff Add option to cache POST requests - Key: TS-2357 URL: https://issues.apache.org/jira/browse/TS-2357 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.1.0 Attachments: ts-2357.diff This feature was added to YTS after it was open sourced. Yahoo bug number: 2831983 This is the configuration option and it might be nice to keep it the same name for those that are migrating from YTS to ATS: CONFIG proxy.config.http.cache.cache_method_post INT 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2357) Add option to cache POST requests
[ https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2357: --- Fix Version/s: (was: 5.0.0) 5.1.0 Add option to cache POST requests - Key: TS-2357 URL: https://issues.apache.org/jira/browse/TS-2357 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.1.0 Attachments: ts-2357.diff This feature was added to YTS after it was open sourced. Yahoo bug number: 2831983 This is the configuration option and it might be nice to keep it the same name for those that are migrating from YTS to ATS: CONFIG proxy.config.http.cache.cache_method_post INT 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2357) Add option to cache POST requests
[ https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011758#comment-14011758 ] Bryan Call commented on TS-2357: This will require more work then just applying a patch from the Yahoo version of the code. Add option to cache POST requests - Key: TS-2357 URL: https://issues.apache.org/jira/browse/TS-2357 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.1.0 Attachments: ts-2357.diff This feature was added to YTS after it was open sourced. Yahoo bug number: 2831983 This is the configuration option and it might be nice to keep it the same name for those that are migrating from YTS to ATS: CONFIG proxy.config.http.cache.cache_method_post INT 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2357) Add option to cache POST requests
[ https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011758#comment-14011758 ] Bryan Call edited comment on TS-2357 at 5/28/14 10:58 PM: -- This will require more work then just applying a patch from the Yahoo version of the code. Attaching the patch that I have right now... was (Author: bcall): This will require more work then just applying a patch from the Yahoo version of the code. Add option to cache POST requests - Key: TS-2357 URL: https://issues.apache.org/jira/browse/TS-2357 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.1.0 Attachments: ts-2357.diff This feature was added to YTS after it was open sourced. Yahoo bug number: 2831983 This is the configuration option and it might be nice to keep it the same name for those that are migrating from YTS to ATS: CONFIG proxy.config.http.cache.cache_method_post INT 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1
[
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011839#comment-14011839
]
ASF subversion and git services commented on TS-2391:
-
Commit d22f9891043bca75df2f44a36c7464d45f72936e in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d22f989 ]
TS-2391: Traffic Server tries to reverse resolve 127.0.0.1
Traffic Server tries to reverse resolve 127.0.0.1
-
Key: TS-2391
URL: https://issues.apache.org/jira/browse/TS-2391
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: David Carlin
Assignee: Bryan Call
Fix For: 5.0.0
We have a number of remaps using 127.0.0.1 for serving healthchecks. Bryan
Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every
one of the requests (there are a lot, sometimes hundreds per second).
Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see
the healthcheck log entries flowing and then all of a sudden it'll stop
anywhere from 15-80 seconds. Then the backlog of healthchecks is cleared out
at once. 5-20 minutes later this process will recur.
From traffic.out with debug dns.*|hostdb.* - this occurs continuously.
Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added
to HostDB.
Unsure if related, but TS-852 seemed similar.
{noformat}
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query
type = 12, timeout = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query
1.0.0.127.in-addr.arpa
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to
collapsing queue
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query
(qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname =
1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one:
failover_number for resolver 0 is 1
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet
size = 109
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS
response code = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for
[1.0.0.127.in-addr.arpa]
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query
(qtype=12) for to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id
= 4497, nameserver = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one:
failover_number for resolver 0 is 1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet
size = 92
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS
response code = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for =
not found retry 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back
continuation for
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 1]
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for
127.0.0.1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for:
: (md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1
9993e35a45b4be6a 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate
answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) delaying force
0 answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759c8953a0} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) DNS IP 127.0.0.1
{noformat}
YTS doesn't have this issue:
{noformat}
bash-3.2#
[jira] [Resolved] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1
[
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-2391.
Resolution: Fixed
I ended up removing the check for host_rule_in_CacheControlTable(). If you are
going to put an IP address in the map to field then you need to use an IP
address in the cache.config file. Tested this scenario and it works.
Traffic Server tries to reverse resolve 127.0.0.1
-
Key: TS-2391
URL: https://issues.apache.org/jira/browse/TS-2391
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: David Carlin
Assignee: Bryan Call
Fix For: 5.0.0
We have a number of remaps using 127.0.0.1 for serving healthchecks. Bryan
Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every
one of the requests (there are a lot, sometimes hundreds per second).
Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see
the healthcheck log entries flowing and then all of a sudden it'll stop
anywhere from 15-80 seconds. Then the backlog of healthchecks is cleared out
at once. 5-20 minutes later this process will recur.
From traffic.out with debug dns.*|hostdb.* - this occurs continuously.
Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added
to HostDB.
Unsure if related, but TS-852 seemed similar.
{noformat}
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query
type = 12, timeout = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query
1.0.0.127.in-addr.arpa
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to
collapsing queue
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query
(qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname =
1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one:
failover_number for resolver 0 is 1
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet
size = 109
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS
response code = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for
[1.0.0.127.in-addr.arpa]
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query
(qtype=12) for to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id
= 4497, nameserver = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one:
failover_number for resolver 0 is 1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet
size = 92
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS
response code = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for =
not found retry 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back
continuation for
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 1]
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for
127.0.0.1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for:
: (md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1
9993e35a45b4be6a 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate
answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) delaying force
0 answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759c8953a0} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) DNS IP 127.0.0.1
{noformat}
YTS doesn't have this issue:
{noformat}
bash-3.2# traffic_server -k
[Nov 24 20:18:11.941] {4146358528} STATUS: opened
[jira] [Updated] (TS-2856) Remove proxy.config.spdy.verbose_in and use diags instead
[ https://issues.apache.org/jira/browse/TS-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2856: --- Fix Version/s: 5.0.0 Remove proxy.config.spdy.verbose_in and use diags instead - Key: TS-2856 URL: https://issues.apache.org/jira/browse/TS-2856 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2856) Remove proxy.config.spdy.verbose_in and use diags instead
Bryan Call created TS-2856: -- Summary: Remove proxy.config.spdy.verbose_in and use diags instead Key: TS-2856 URL: https://issues.apache.org/jira/browse/TS-2856 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Bryan Call -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2856) Remove proxy.config.spdy.verbose_in and use diags instead
[ https://issues.apache.org/jira/browse/TS-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2856: -- Assignee: Bryan Call Remove proxy.config.spdy.verbose_in and use diags instead - Key: TS-2856 URL: https://issues.apache.org/jira/browse/TS-2856 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2856) Remove proxy.config.spdy.verbose_in and use diags instead
[ https://issues.apache.org/jira/browse/TS-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-2856. Resolution: Fixed Remove proxy.config.spdy.verbose_in and use diags instead - Key: TS-2856 URL: https://issues.apache.org/jira/browse/TS-2856 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2856) Remove proxy.config.spdy.verbose_in and use diags instead
[ https://issues.apache.org/jira/browse/TS-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011900#comment-14011900 ] ASF subversion and git services commented on TS-2856: - Commit d0f4d5c47272dd2ab87fc3db6271553864822887 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d0f4d5c ] TS-2856: Remove proxy.config.spdy.verbose_in and use diags instead Remove proxy.config.spdy.verbose_in and use diags instead - Key: TS-2856 URL: https://issues.apache.org/jira/browse/TS-2856 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2857) clean up SPDY and SSL stat names
Bryan Call created TS-2857: -- Summary: clean up SPDY and SSL stat names Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2857) clean up SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2857: -- Assignee: Bryan Call clean up SPDY and SSL stat names Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2857) clean up SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2857: --- Fix Version/s: 5.0.0 clean up SPDY and SSL stat names Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2857) clean up SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011920#comment-14011920 ] Bryan Call commented on TS-2857: Rename these stats: proxy.process.https.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.active_sessions -- proxy.spdy.current_client_connections proxy.process.spdy.active_streams -- proxy.spdy.current_client_streams clean up SPDY and SSL stat names Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2858) Current master fails to build on OmniOS
Leif Hedstrom created TS-2858:
-
Summary: Current master fails to build on OmniOS
Key: TS-2858
URL: https://issues.apache.org/jira/browse/TS-2858
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
On my OmniOS VM, I get this error when it tries to build the LuaJit imported
tree:
{code}
test -d ../lib/luajit/src || (cd .. git submodule update --init)
test -d ../lib/luajit/src || cp -rf ./luajit ../lib/
cd luajit gmake PREFIX=/usr/local CC=/opt/gcc-4.8.1/bin/gcc
CFLAGS=-m64 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols
-fno-strict-aliasing -mcx16
gmake[3]: Entering directory `/tmp/trafficserver/lib/luajit'
Building LuaJIT 2.0.3
gmake -C src
gmake[4]: Entering directory `/tmp/trafficserver/lib/luajit/src'
HOSTLINK host/minilua
ld: fatal: file host/minilua.o: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to host/minilua
{code}
A *wild* guess it that it's something with the CFLAGS, but was hoping some of
the OmniOS expertise could help? I did verify that compiling with the CFLAGS
works, but I worry we might break other platform if we don't pass along our
CFLAGS?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1866) Clean up some of the unsupported hardware architecture tests in configure.ac
[ https://issues.apache.org/jira/browse/TS-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011990#comment-14011990 ] ASF subversion and git services commented on TS-1866: - Commit d6cdbfd528920a3074760455cffe4b694bf6e19e in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d6cdbfd ] TS-1866 Remove some DEC specific compiler wonkiness Clean up some of the unsupported hardware architecture tests in configure.ac Key: TS-1866 URL: https://issues.apache.org/jira/browse/TS-1866 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2843:
--
Assignee: (was: Leif Hedstrom)
Buffer overflow in SSL error messages
-
Key: TS-2843
URL: https://issues.apache.org/jira/browse/TS-2843
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Fix For: sometime
With a bad TLS config, I was getting the following errors, which looks like
it's reading buffers beyond EOL.
{code}
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
decrypt:pem_lib.c:483���
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:140B0009:SSL
routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011996#comment-14011996
]
Leif Hedstrom commented on TS-2843:
---
I'm not sure where this is coming from, but I'm guessing from OpenSSL... Moving
out to sometime.
Buffer overflow in SSL error messages
-
Key: TS-2843
URL: https://issues.apache.org/jira/browse/TS-2843
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: sometime
With a bad TLS config, I was getting the following errors, which looks like
it's reading buffers beyond EOL.
{code}
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
decrypt:pem_lib.c:483���
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:140B0009:SSL
routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2843) Buffer overflow in SSL error messages
[
https://issues.apache.org/jira/browse/TS-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2843:
--
Fix Version/s: (was: 5.0.0)
sometime
Buffer overflow in SSL error messages
-
Key: TS-2843
URL: https://issues.apache.org/jira/browse/TS-2843
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Fix For: sometime
With a bad TLS config, I was getting the following errors, which looks like
it's reading buffers beyond EOL.
{code}
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:596���
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:0906A065:PEM routines:PEM_do_header:bad
decrypt:pem_lib.c:483���
May 24 22:31:55 ats-int traffic_server[12696]: {0x2b89afcc6900} ERROR:
SSLUtils.cc:971 (SSLInitServerContext)
SSL::47870359922944:error:140B0009:SSL
routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669���
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2857) clean up SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011920#comment-14011920 ] Bryan Call edited comment on TS-2857 at 5/29/14 2:54 AM: - Rename these stats: proxy.process.https.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.connection_count -- proxy.process.spdy.total_client_connections proxy.process.spdy.active_sessions -- proxy.spdy.current_client_connections proxy.process.spdy.active_streams -- proxy.spdy.current_client_streams proxy.process.spdy.total_streams -- proxy.process.spdy.total_client_streams was (Author: bcall): Rename these stats: proxy.process.https.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.connection_count -- proxy.process.spdy.total_client_connections proxy.process.spdy.active_sessions -- proxy.spdy.current_client_connections proxy.process.spdy.active_streams -- proxy.spdy.current_client_streams clean up SPDY and SSL stat names Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2857) clean up SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011920#comment-14011920 ] Bryan Call edited comment on TS-2857 at 5/29/14 2:54 AM: - Rename these stats: proxy.process.https.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.connection_count -- proxy.process.spdy.total_client_connections proxy.process.spdy.active_sessions -- proxy.spdy.current_client_connections proxy.process.spdy.active_streams -- proxy.spdy.current_client_streams was (Author: bcall): Rename these stats: proxy.process.https.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.active_sessions -- proxy.spdy.current_client_connections proxy.process.spdy.active_streams -- proxy.spdy.current_client_streams clean up SPDY and SSL stat names Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2857) Clean up SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2857: --- Summary: Clean up SPDY and SSL stat names (was: clean up SPDY and SSL stat names) Clean up SPDY and SSL stat names Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2857) Cleanup SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2857: --- Summary: Cleanup SPDY and SSL stat names (was: Clean up SPDY and SSL stat names) Cleanup SPDY and SSL stat names --- Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2857) Cleanup SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012005#comment-14012005 ] ASF subversion and git services commented on TS-2857: - Commit d65bc70a5de9f73b61357212e26f88d3d3fb2f25 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d65bc70 ] TS-2857: Cleanup SPDY and SSL stat names Cleanup SPDY and SSL stat names --- Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2857) Cleanup SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012006#comment-14012006 ] Bryan Call commented on TS-2857: Should we also change proxy.process.spdy.total_time ? Cleanup SPDY and SSL stat names --- Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2857) Cleanup SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012006#comment-14012006 ] Bryan Call edited comment on TS-2857 at 5/29/14 3:13 AM: - Should we also change proxy.process.spdy.total_time ? So there is already: proxy.process.http.total_transactions_time 2474718928309301 proxy.process.http.client_transaction_time 0 proxy.process.http.server_transaction_time 0 However, client and sever transaction times for http are not being updated. was (Author: bcall): Should we also change proxy.process.spdy.total_time ? Cleanup SPDY and SSL stat names --- Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2604) Collapsed connection plugin
[ https://issues.apache.org/jira/browse/TS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012023#comment-14012023 ] ASF subversion and git services commented on TS-2604: - Commit 2ddcc688403eabf71cde47855d9f1377196583be in trafficserver's branch refs/heads/master from [~yzlai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2ddcc68 ] TS-2604: collapsed connection plugin Collapsed connection plugin --- Key: TS-2604 URL: https://issues.apache.org/jira/browse/TS-2604 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Ethan Lai Assignee: Bryan Call Labels: review Fix For: 5.0.0 This plugin collapses connections with identical CacheUrl/EffectiveUrl. Please find more detail from README and state.png (State Diagram) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2857) Cleanup SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012054#comment-14012054 ] ASF subversion and git services commented on TS-2857: - Commit f6e9da4aa2ec5e2ad96b1ebc3f34ee20bb7afbef in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f6e9da4 ] TS-2857: Cleanup SPDY and SSL stat names Cleanup SPDY and SSL stat names --- Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2857) Cleanup SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011920#comment-14011920 ] Bryan Call edited comment on TS-2857 at 5/29/14 4:30 AM: - Rename these stats: proxy.process.https.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.connection_count -- proxy.process.spdy.total_client_connections proxy.process.spdy.active_sessions -- proxy.spdy.current_client_connections proxy.process.spdy.active_streams -- proxy.spdy.current_client_streams proxy.process.spdy.total_streams -- proxy.process.spdy.total_client_streams proxy.process.spdy.total_time -- proxy.process.spdy.total_transactions_time was (Author: bcall): Rename these stats: proxy.process.https.connection_count -- proxy.process.https.total_client_connections proxy.process.spdy.connection_count -- proxy.process.spdy.total_client_connections proxy.process.spdy.active_sessions -- proxy.spdy.current_client_connections proxy.process.spdy.active_streams -- proxy.spdy.current_client_streams proxy.process.spdy.total_streams -- proxy.process.spdy.total_client_streams Cleanup SPDY and SSL stat names --- Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2857) Cleanup SPDY and SSL stat names
[ https://issues.apache.org/jira/browse/TS-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-2857. Resolution: Fixed Cleanup SPDY and SSL stat names --- Key: TS-2857 URL: https://issues.apache.org/jira/browse/TS-2857 Project: Traffic Server Issue Type: Improvement Components: SPDY, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
