[jira] [Updated] (TS-2753) Add more SPDY and HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2753: Attachment: TS-2802_2.diff Move ssl handshake calculation after ssl_read, please feel free to change the naming if necessary. > Add more SPDY and HTTPS statistics > --- > > Key: TS-2753 > URL: https://issues.apache.org/jira/browse/TS-2753 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Wei Sun >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: TS-2753_1.diff, TS-2802_2.diff > > > Adding stats to spdy helps monitoring and troubleshooting, it would be good > to define and add spdy specific stats. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2859) fix DBG macros to not generate warnings from GCC 4.9
[
https://issues.apache.org/jira/browse/TS-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Juszkiewicz updated TS-2859:
---
Attachment: trafficserver-fix-dbg.patch
> fix DBG macros to not generate warnings from GCC 4.9
>
>
> Key: TS-2859
> URL: https://issues.apache.org/jira/browse/TS-2859
> Project: Traffic Server
> Issue Type: Improvement
> Components: Build
>Reporter: Marcin Juszkiewicz
> Attachments: trafficserver-fix-dbg.patch
>
>
> Fedora 'rawhide' is using gcc 4.9 as default compiler. During build of
> trafficserver 4.2.1 I had lot of extra output from gcc due to DBG macros:
> ---
> In file included from ../../lib/ts/ink_time.h:38:0,
> from ../../lib/ts/ink_align.h:28,
> from ../../lib/ts/libts.h:46,
> from P_EventSystem.h:34,
> from IOBuffer.cc:28:
> ../../lib/ts/ink_defs.h:147:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define FDBGif (debug_level==1) printf("debug "__FILE__":%d
> %s : entered\n" ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:148:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG(s) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:149:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG1(s,a) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a)
> ^
> ../../lib/ts/ink_defs.h:150:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG2(s,a1,a2) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2)
> ^
> ../../lib/ts/ink_defs.h:151:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG3(s,a1,a2,a3)if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3)
> ^
> ../../lib/ts/ink_defs.h:152:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG4(s,a1,a2,a3,a4) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3,a4)
> ---
> I have a fix for that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2859) fix DBG macros to not generate warnings from GCC 4.9
Marcin Juszkiewicz created TS-2859:
--
Summary: fix DBG macros to not generate warnings from GCC 4.9
Key: TS-2859
URL: https://issues.apache.org/jira/browse/TS-2859
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: Marcin Juszkiewicz
Attachments: trafficserver-fix-dbg.patch
Fedora 'rawhide' is using gcc 4.9 as default compiler. During build of
trafficserver 4.2.1 I had lot of extra output from gcc due to DBG macros:
---
In file included from ../../lib/ts/ink_time.h:38:0,
from ../../lib/ts/ink_align.h:28,
from ../../lib/ts/libts.h:46,
from P_EventSystem.h:34,
from IOBuffer.cc:28:
../../lib/ts/ink_defs.h:147:56: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
#define FDBGif (debug_level==1) printf("debug "__FILE__":%d %s
: entered\n" ,__LINE__,__FUNCTION__)
^
../../lib/ts/ink_defs.h:148:56: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
#define DBG(s) if (debug_level==1) printf("debug "__FILE__":%d %s
:" s ,__LINE__,__FUNCTION__)
^
../../lib/ts/ink_defs.h:149:56: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
#define DBG1(s,a) if (debug_level==1) printf("debug "__FILE__":%d %s
:" s ,__LINE__,__FUNCTION__, a)
^
../../lib/ts/ink_defs.h:150:56: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
#define DBG2(s,a1,a2) if (debug_level==1) printf("debug "__FILE__":%d %s
:" s ,__LINE__,__FUNCTION__, a1,a2)
^
../../lib/ts/ink_defs.h:151:56: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
#define DBG3(s,a1,a2,a3)if (debug_level==1) printf("debug "__FILE__":%d %s
:" s ,__LINE__,__FUNCTION__, a1,a2,a3)
^
../../lib/ts/ink_defs.h:152:56: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
#define DBG4(s,a1,a2,a3,a4) if (debug_level==1) printf("debug "__FILE__":%d %s
:" s ,__LINE__,__FUNCTION__, a1,a2,a3,a4)
---
I have a fix for that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2860) AArch64 support
Marcin Juszkiewicz created TS-2860: -- Summary: AArch64 support Key: TS-2860 URL: https://issues.apache.org/jira/browse/TS-2860 Project: Traffic Server Issue Type: New Feature Components: Build, Portability Reporter: Marcin Juszkiewicz Attachments: trafficserver-aarch64.patch Out of the box traffic server does not build on AArch64 (64-bit ARM) architecture. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2860) AArch64 support
[ https://issues.apache.org/jira/browse/TS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcin Juszkiewicz updated TS-2860: --- Attachment: trafficserver-aarch64.patch This patch adds all required definitions to get traffic server 4.2.1 built on AArch64 system. All tests passed. > AArch64 support > --- > > Key: TS-2860 > URL: https://issues.apache.org/jira/browse/TS-2860 > Project: Traffic Server > Issue Type: New Feature > Components: Build, Portability >Reporter: Marcin Juszkiewicz > Attachments: trafficserver-aarch64.patch > > > Out of the box traffic server does not build on AArch64 (64-bit ARM) > architecture. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2859) fix DBG macros to not generate warnings from GCC 4.9
[
https://issues.apache.org/jira/browse/TS-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012435#comment-14012435
]
James Peach commented on TS-2859:
-
Thanks for the patch Marcin. These macros look obsolete and unused. Could you
submit a path that simply removes them?
> fix DBG macros to not generate warnings from GCC 4.9
>
>
> Key: TS-2859
> URL: https://issues.apache.org/jira/browse/TS-2859
> Project: Traffic Server
> Issue Type: Improvement
> Components: Build
>Reporter: Marcin Juszkiewicz
> Attachments: trafficserver-fix-dbg.patch
>
>
> Fedora 'rawhide' is using gcc 4.9 as default compiler. During build of
> trafficserver 4.2.1 I had lot of extra output from gcc due to DBG macros:
> ---
> In file included from ../../lib/ts/ink_time.h:38:0,
> from ../../lib/ts/ink_align.h:28,
> from ../../lib/ts/libts.h:46,
> from P_EventSystem.h:34,
> from IOBuffer.cc:28:
> ../../lib/ts/ink_defs.h:147:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define FDBGif (debug_level==1) printf("debug "__FILE__":%d
> %s : entered\n" ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:148:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG(s) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:149:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG1(s,a) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a)
> ^
> ../../lib/ts/ink_defs.h:150:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG2(s,a1,a2) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2)
> ^
> ../../lib/ts/ink_defs.h:151:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG3(s,a1,a2,a3)if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3)
> ^
> ../../lib/ts/ink_defs.h:152:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG4(s,a1,a2,a3,a4) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3,a4)
> ---
> I have a fix for that.
--
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-tabpanel&focusedCommentId=14012443#comment-14012443
]
Masakazu Kitajo commented on TS-2839:
-
I confirmed that the last change works for me. Thanks.
> 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-2753) Add more SPDY and HTTPS statistics
[
https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012458#comment-14012458
]
James Peach commented on TS-2753:
-
The naming convention for macros that increment stats by an amount seems to be
{{FOO_SUM_DYN_STAT}}. For example, {{NET_SUM_DYN_STAT}},
{{HOSTDB_SUM_DYN_STAT}}, {{DNS_SUM_DYN_STAT}}. So
{{SSL_INCREMENT_MULTI_DYN_STAT}} should be {{SSL_SUM_DYN_STAT}} to be
consistent.
> Add more SPDY and HTTPS statistics
> ---
>
> Key: TS-2753
> URL: https://issues.apache.org/jira/browse/TS-2753
> Project: Traffic Server
> Issue Type: Improvement
> Components: SPDY
>Reporter: Wei Sun
>Assignee: Bryan Call
> Labels: spdy, yahoo
> Fix For: 5.0.0
>
> Attachments: TS-2753_1.diff, TS-2802_2.diff
>
>
> Adding stats to spdy helps monitoring and troubleshooting, it would be good
> to define and add spdy specific stats.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2861) traffic_line option to find differences from defaults
Miles Libbey created TS-2861: Summary: traffic_line option to find differences from defaults Key: TS-2861 URL: https://issues.apache.org/jira/browse/TS-2861 Project: Traffic Server Issue Type: Bug Reporter: Miles Libbey Whenever someone has an issue with ATS getting to run as expected, the first troubleshooting question is, 'what are your configs?' which frequently relies on the user remembering what has been changed. It would be nice to have an easy way to print out the configs that are different than the defaults to begin troubleshooting. Yesterday, someone came with a performance issue -- turned out that the user had forgotten that he had turned on diagnostic logging, slowing the performance. Took a while to figure out that it was turned on -- which could have been avoided if it were easy to figure out the non-default configurations being used. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012542#comment-14012542
]
Bryan Call edited comment on TS-2095 at 5/29/14 5:04 PM:
-
>From config.log:
When testing the preprocessor it doesn't use c++11:
{code}
configure:7971: checking unordered_map presence
configure:7971: c++ -E conftest.cpp
In file included from /usr/include/c++/4.8.2/unordered_map:35:0,
from conftest.cpp:22:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file
requires compiler and library support for the ISO C++ 2011 standard. This
support is currently experimental, and must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
...
configure:7971: result: no
{code}
But does for the compiler:
{code}
configure:7971: checking unordered_set usability
configure:7971: c++ -c -std=c++11 conftest.cpp >&5
configure:7971: $? = 0
configure:7971: result: yes
{code}
was (Author: bcall):
>From config.log:
When testing the preprocessor it doesn't use c++11:
{code}
configure:7971: checking unordered_map presence
configure:7971: c++ -E conftest.cpp
In file included from /usr/include/c++/4.8.2/unordered_map:35:0,
from conftest.cpp:22:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file
requires compiler and library support for the ISO C++ 2011 standard. This
support is currently experimental, and must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
{code}
But does for the compiler:
{code}
configure:7971: checking unordered_set usability
configure:7971: c++ -c -std=c++11 conftest.cpp >&5
configure:7971: $? = 0
configure:7971: result: yes
{code}
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012542#comment-14012542
]
Bryan Call commented on TS-2095:
>From config.log:
When testing the preprocessor it doesn't use c++11:
{code}
configure:7971: checking unordered_map presence
configure:7971: c++ -E conftest.cpp
In file included from /usr/include/c++/4.8.2/unordered_map:35:0,
from conftest.cpp:22:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file
requires compiler and library support for the ISO C++ 2011 standard. This
support is currently experimental, and must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
{code}
But does for the compiler:
{code}
configure:7971: checking unordered_set usability
configure:7971: c++ -c -std=c++11 conftest.cpp >&5
configure:7971: $? = 0
configure:7971: result: yes
{code}
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012542#comment-14012542
]
Bryan Call edited comment on TS-2095 at 5/29/14 5:05 PM:
-
>From config.log (running Fedora 20):
When testing the preprocessor it doesn't use c++11:
{code}
configure:7971: checking unordered_map presence
configure:7971: c++ -E conftest.cpp
In file included from /usr/include/c++/4.8.2/unordered_map:35:0,
from conftest.cpp:22:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file
requires compiler and library support for the ISO C++ 2011 standard. This
support is currently experimental, and must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
...
configure:7971: result: no
{code}
But does for the compiler:
{code}
configure:7971: checking unordered_set usability
configure:7971: c++ -c -std=c++11 conftest.cpp >&5
configure:7971: $? = 0
configure:7971: result: yes
{code}
was (Author: bcall):
>From config.log:
When testing the preprocessor it doesn't use c++11:
{code}
configure:7971: checking unordered_map presence
configure:7971: c++ -E conftest.cpp
In file included from /usr/include/c++/4.8.2/unordered_map:35:0,
from conftest.cpp:22:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file
requires compiler and library support for the ISO C++ 2011 standard. This
support is currently experimental, and must be enabled with the -std=c++11 or
-std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
...
configure:7971: result: no
{code}
But does for the compiler:
{code}
configure:7971: checking unordered_set usability
configure:7971: c++ -c -std=c++11 conftest.cpp >&5
configure:7971: $? = 0
configure:7971: result: yes
{code}
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012545#comment-14012545
]
Bryan Call commented on TS-2095:
>From config.log (running OSX) works for both:
Preprocessor:
{code}
configure:7946: checking unordered_map presence
configure:7946: clang++ -E conftest.cpp
configure:7946: $? = 0
configure:7946: result: yes
{code}
Compiler:
{code}
configure:7946: checking unordered_map usability
configure:7946: clang++ -c -std=c++11 conftest.cpp >&5
configure:7946: $? = 0
configure:7946: result: yes
{code}
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2858) Current master fails to build on OmniOS
[
https://issues.apache.org/jira/browse/TS-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2858:
--
Fix Version/s: 5.0.0
> 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
> Fix For: 5.0.0
>
>
> 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] [Assigned] (TS-2858) Current master fails to build on OmniOS
[
https://issues.apache.org/jira/browse/TS-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2858:
-
Assignee: Leif Hedstrom
> 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
>Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
>
> 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-2858) Current master fails to build on OmniOS
[
https://issues.apache.org/jira/browse/TS-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012644#comment-14012644
]
ASF subversion and git services commented on TS-2858:
-
Commit 1cb12a93a0df96e5c38e77076bcc1337e4caaa31 in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1cb12a9 ]
TS-2858 Build failures on OmniOS
> 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
> Fix For: 5.0.0
>
>
> 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] [Resolved] (TS-2858) Current master fails to build on OmniOS
[
https://issues.apache.org/jira/browse/TS-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2858.
---
Resolution: Fixed
> 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
> Fix For: 5.0.0
>
>
> 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] [Updated] (TS-2859) fix DBG macros to not generate warnings from GCC 4.9
[
https://issues.apache.org/jira/browse/TS-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Juszkiewicz updated TS-2859:
---
Attachment: trafficserver-remove-dbg-macros.patch
This patch removes DBG macros as they are not used.
> fix DBG macros to not generate warnings from GCC 4.9
>
>
> Key: TS-2859
> URL: https://issues.apache.org/jira/browse/TS-2859
> Project: Traffic Server
> Issue Type: Improvement
> Components: Build
>Reporter: Marcin Juszkiewicz
> Attachments: trafficserver-fix-dbg.patch,
> trafficserver-remove-dbg-macros.patch
>
>
> Fedora 'rawhide' is using gcc 4.9 as default compiler. During build of
> trafficserver 4.2.1 I had lot of extra output from gcc due to DBG macros:
> ---
> In file included from ../../lib/ts/ink_time.h:38:0,
> from ../../lib/ts/ink_align.h:28,
> from ../../lib/ts/libts.h:46,
> from P_EventSystem.h:34,
> from IOBuffer.cc:28:
> ../../lib/ts/ink_defs.h:147:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define FDBGif (debug_level==1) printf("debug "__FILE__":%d
> %s : entered\n" ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:148:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG(s) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:149:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG1(s,a) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a)
> ^
> ../../lib/ts/ink_defs.h:150:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG2(s,a1,a2) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2)
> ^
> ../../lib/ts/ink_defs.h:151:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG3(s,a1,a2,a3)if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3)
> ^
> ../../lib/ts/ink_defs.h:152:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG4(s,a1,a2,a3,a4) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3,a4)
> ---
> I have a fix for that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012715#comment-14012715 ] Leif Hedstrom commented on TS-2834: --- This seems fine, but I think I'd like to call it INTERNAL-REQUEST, because that's what the underlying API is called. This becomes more obvious after we also add the "InternalSession" API. > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012720#comment-14012720 ] Leif Hedstrom commented on TS-2834: --- Actually, maybe we should (later) rename the API to be TSHttpIsInternalTransaction(), I'll file a different Jira on that. > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012739#comment-14012739 ] Leif Hedstrom edited comment on TS-2834 at 5/29/14 7:11 PM: One thing: I don't like the % stuff in the conditions. We need to resolve this in some better way, generalizing the stuff that was done for the "expander". Edit: Argh, yeah I really don't like this, major code duplication here between this new stuff and the "expander" code... :/ was (Author: zwoop): One thing: I don't like the % stuff in the conditions. We need to resolve this in some better way, generalizing the stuff that was done for the "expander". I'll commit this as it is, but we really need to rope this in at some point such that all log tags are supported "equally". > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
[ https://issues.apache.org/jira/browse/TS-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2862: -- Fix Version/s: sometime > Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction() > --- > > Key: TS-2862 > URL: https://issues.apache.org/jira/browse/TS-2862 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Labels: api-change > Fix For: sometime > > > Or possible TSHttpIsInternalTxn(), depending on what we name the new > Session() API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
[ https://issues.apache.org/jira/browse/TS-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2862: -- Labels: api-change (was: ) > Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction() > --- > > Key: TS-2862 > URL: https://issues.apache.org/jira/browse/TS-2862 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Labels: api-change > Fix For: sometime > > > Or possible TSHttpIsInternalTxn(), depending on what we name the new > Session() API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
Leif Hedstrom created TS-2862: - Summary: Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction() Key: TS-2862 URL: https://issues.apache.org/jira/browse/TS-2862 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Or possible TSHttpIsInternalTxn(), depending on what we name the new Session() API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012739#comment-14012739 ] Leif Hedstrom commented on TS-2834: --- One thing: I don't like the % stuff in the conditions. We need to resolve this in some better way, generalizing the stuff that was done for the "expander". I'll commit this as it is, but we really need to rope this in at some point such that all log tags are supported "equally". > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2859) fix DBG macros to not generate warnings from GCC 4.9
[
https://issues.apache.org/jira/browse/TS-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012757#comment-14012757
]
ASF subversion and git services commented on TS-2859:
-
Commit e7586dfee7a04b44e3c378a484cc1e776e847b27 in trafficserver's branch
refs/heads/master from [~hrw-redhat]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e7586df ]
TS-2859: remove DBG macros to not generate warnings from GCC 4.9
> fix DBG macros to not generate warnings from GCC 4.9
>
>
> Key: TS-2859
> URL: https://issues.apache.org/jira/browse/TS-2859
> Project: Traffic Server
> Issue Type: Improvement
> Components: Build
>Reporter: Marcin Juszkiewicz
> Attachments: trafficserver-fix-dbg.patch,
> trafficserver-remove-dbg-macros.patch
>
>
> Fedora 'rawhide' is using gcc 4.9 as default compiler. During build of
> trafficserver 4.2.1 I had lot of extra output from gcc due to DBG macros:
> ---
> In file included from ../../lib/ts/ink_time.h:38:0,
> from ../../lib/ts/ink_align.h:28,
> from ../../lib/ts/libts.h:46,
> from P_EventSystem.h:34,
> from IOBuffer.cc:28:
> ../../lib/ts/ink_defs.h:147:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define FDBGif (debug_level==1) printf("debug "__FILE__":%d
> %s : entered\n" ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:148:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG(s) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:149:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG1(s,a) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a)
> ^
> ../../lib/ts/ink_defs.h:150:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG2(s,a1,a2) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2)
> ^
> ../../lib/ts/ink_defs.h:151:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG3(s,a1,a2,a3)if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3)
> ^
> ../../lib/ts/ink_defs.h:152:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG4(s,a1,a2,a3,a4) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3,a4)
> ---
> I have a fix for that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2855) add TSHttpIsInternalSession API
[
https://issues.apache.org/jira/browse/TS-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012777#comment-14012777
]
ASF subversion and git services commented on TS-2855:
-
Commit 52682da919945fce6097d5fa50e024a6f7fb5da6 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=52682da ]
TS-2855: add TSHttpIsInternalSession API
Add TSHttpIsInternalSession API to be symmetric with
TSHttpIsInternalRequest.
> 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] [Resolved] (TS-2855) add TSHttpIsInternalSession API
[
https://issues.apache.org/jira/browse/TS-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2855.
-
Resolution: Fixed
> 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-2863) FQDN session pools work poorly
Alan M. Carroll created TS-2863: --- Summary: FQDN session pools work poorly Key: TS-2863 URL: https://issues.apache.org/jira/browse/TS-2863 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Alan M. Carroll Because the server session pool hashes by IP address, most of the time a server session is not found (even if present) when selecting by FQDN only. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
[
https://issues.apache.org/jira/browse/TS-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012767#comment-14012767
]
James Peach commented on TS-2862:
-
The right convention would be {{TSHttpTxnIsInternal}}
> Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
> ---
>
> Key: TS-2862
> URL: https://issues.apache.org/jira/browse/TS-2862
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: Leif Hedstrom
> Labels: api-change
> Fix For: sometime
>
>
> Or possible TSHttpIsInternalTxn(), depending on what we name the new
> Session() API.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2859) fix DBG macros to not generate warnings from GCC 4.9
[
https://issues.apache.org/jira/browse/TS-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2859:
Fix Version/s: 5.0.0
Assignee: James Peach
> fix DBG macros to not generate warnings from GCC 4.9
>
>
> Key: TS-2859
> URL: https://issues.apache.org/jira/browse/TS-2859
> Project: Traffic Server
> Issue Type: Improvement
> Components: Build
>Reporter: Marcin Juszkiewicz
>Assignee: James Peach
> Fix For: 5.0.0
>
> Attachments: trafficserver-fix-dbg.patch,
> trafficserver-remove-dbg-macros.patch
>
>
> Fedora 'rawhide' is using gcc 4.9 as default compiler. During build of
> trafficserver 4.2.1 I had lot of extra output from gcc due to DBG macros:
> ---
> In file included from ../../lib/ts/ink_time.h:38:0,
> from ../../lib/ts/ink_align.h:28,
> from ../../lib/ts/libts.h:46,
> from P_EventSystem.h:34,
> from IOBuffer.cc:28:
> ../../lib/ts/ink_defs.h:147:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define FDBGif (debug_level==1) printf("debug "__FILE__":%d
> %s : entered\n" ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:148:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG(s) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__)
> ^
> ../../lib/ts/ink_defs.h:149:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG1(s,a) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a)
> ^
> ../../lib/ts/ink_defs.h:150:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG2(s,a1,a2) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2)
> ^
> ../../lib/ts/ink_defs.h:151:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG3(s,a1,a2,a3)if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3)
> ^
> ../../lib/ts/ink_defs.h:152:56: warning: invalid suffix on literal; C++11
> requires a space between literal and string macro [-Wliteral-suffix]
> #define DBG4(s,a1,a2,a3,a4) if (debug_level==1) printf("debug "__FILE__":%d
> %s :" s ,__LINE__,__FUNCTION__, a1,a2,a3,a4)
> ---
> I have a fix for that.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2862) Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction()
[ https://issues.apache.org/jira/browse/TS-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012789#comment-14012789 ] Leif Hedstrom commented on TS-2862: --- Sounds good. Should we do that? > Rename TSHttpIsInternalRequest to TSHttpIsInternalTransaction() > --- > > Key: TS-2862 > URL: https://issues.apache.org/jira/browse/TS-2862 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom > Labels: api-change > Fix For: sometime > > > Or possible TSHttpIsInternalTxn(), depending on what we name the new > Session() API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012844#comment-14012844 ] ASF subversion and git services commented on TS-2834: - Commit 05f64b6ebcf35b1916ff6663fac57e4d5b3049fa in trafficserver's branch refs/heads/master from [~manjesh] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=05f64b6 ] TS-2834 header_rewrite: internal transaction and client IP conditions > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012845#comment-14012845 ] ASF subversion and git services commented on TS-2834: - Commit 896ce4d33468a1e2094b103a720eee38fafa26df in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=896ce4d ] TS-2834 Refactor the getIP() code, and rename the condition to CLIENT-IP. Also added a little bit of docs. Long term, we should figure out how to unify conditions and the expander in a way that it integrates with the internal log token expansions. This closes #91 > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2834: -- Issue Type: New Feature (was: Improvement) > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2834) header_rewrite: internal transaction and client IP conditions
[ https://issues.apache.org/jira/browse/TS-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012846#comment-14012846 ] ASF GitHub Bot commented on TS-2834: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/91 > header_rewrite: internal transaction and client IP conditions > - > > Key: TS-2834 > URL: https://issues.apache.org/jira/browse/TS-2834 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > It would be nice to use the above two conditions in the rules. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2231) header_rewrite uses boost regexes, we should switch to PCRE
[ https://issues.apache.org/jira/browse/TS-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2231: -- Fix Version/s: (was: 5.0.0) 5.1.0 > header_rewrite uses boost regexes, we should switch to PCRE > --- > > Key: TS-2231 > URL: https://issues.apache.org/jira/browse/TS-2231 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.1.0 > > > It makes no sense to have another regex format, lets unify everything on > PCRE. Also, while we're at it, lets get rid of BOOST entirely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012858#comment-14012858
]
ASF subversion and git services commented on TS-2095:
-
Commit 89f19acec7ecaeebe13bc0229f463efaf1543047 in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=89f19ac ]
TS-2095: autoconf warnings related to unordered_map
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-2095.
Resolution: Fixed
Had to add -std=c++11 to CPPFLAGS when c++11 support is detected.
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reopened TS-2095:
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012886#comment-14012886
]
ASF subversion and git services commented on TS-2095:
-
Commit 11c329f2a2bc25c13a6c1f943f88a124ac1421bf in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=11c329f ]
Revert "TS-2095: autoconf warnings related to unordered_map"
This reverts commit 89f19acec7ecaeebe13bc0229f463efaf1543047.
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 5.0.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2804) Add revalidation plugin
[ https://issues.apache.org/jira/browse/TS-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012910#comment-14012910 ] ASF subversion and git services commented on TS-2804: - Commit 515f312b69398762a4b4eb935d3276ffd404fce6 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=515f312 ] TS-2804 Fix build on platforms where alloca.h is in a different spot > Add revalidation plugin > --- > > Key: TS-2804 > URL: https://issues.apache.org/jira/browse/TS-2804 > Project: Traffic Server > Issue Type: New Feature >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 5.0.0 > > > We have developed a plugin that allows you to use regular expressions to > force a revalidation of content. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Deleted] (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 deleted TS-2853: > 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 >Reporter: Brian Geffon >Assignee: Phil Sorber > > 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] [Deleted] (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 deleted TS-2852: > BACKPORT - Crash in LogBufferIterator::next > --- > > Key: TS-2852 > URL: https://issues.apache.org/jira/browse/TS-2852 > Project: Traffic Server > Issue Type: Bug >Reporter: Brian Geffon >Assignee: Phil Sorber > > 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] [Deleted] (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 deleted TS-2854: > 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 >Reporter: Brian Geffon >Assignee: Phil Sorber > > 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-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012969#comment-14012969
]
ASF subversion and git services commented on TS-2564:
-
Commit 45fb60efebeff4fc3b2ddba6da74595bc11e2d0f in trafficserver's branch
refs/heads/4.2.x from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=45fb60e ]
TS-2564: Fix race condition when object is in the ram_cache and presence bits
are already recalculated
> Segmentation fault in 4.2.0-rc0
> ---
>
> Key: TS-2564
> URL: https://issues.apache.org/jira/browse/TS-2564
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Phil Sorber
>Priority: Blocker
> Labels: crash
> Fix For: 4.2.1, 5.0.0
>
> Attachments: ts-2564-B.diff, ts-2564.diff
>
>
> Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
> 4.2.0-rc0:
> {code}
> (gdb) bt
> #0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
> field=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= out>) at MIME.cc:1586
> #3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
> #4 field_delete (cached_header=0x2acde002fa40,
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
> #5 HttpTransact::merge_response_header_with_cached_header
> (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
> HttpTransact.cc:4914
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14012971#comment-14012971 ] Phil Sorber commented on TS-2778: - This has been backported. > 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: 4.2.2, 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] [Updated] (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 updated TS-2778: Fix Version/s: 4.2.2 > 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: 4.2.2, 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-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:comment-tabpanel&focusedCommentId=14012970#comment-14012970 ] ASF subversion and git services commented on TS-2778: - Commit 79220c16fe57b03ee4b6a391e8ba65a5200ed3f0 in trafficserver's branch refs/heads/4.2.x from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=79220c1 ] TS-2778: Websockets remap doesn't properly handle the implicit port for wss. (cherry picked from commit 6396c485bab8dbc4255f6790a5711de298b22787) > 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: 4.2.2, 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] [Updated] (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 updated TS-2778: Backport to Version: (was: 4.2.2) > 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: 4.2.2, 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] [Updated] (TS-2784) header_rewrite fails to build on FreeBSD(10)
[
https://issues.apache.org/jira/browse/TS-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2784:
--
Backport to Version: 4.2.2
> header_rewrite fails to build on FreeBSD(10)
>
>
> Key: TS-2784
> URL: https://issues.apache.org/jira/browse/TS-2784
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 5.0.0
>
>
> {code}
> CXX expander.lo
> expander.cc:41:28: error: member access into incomplete type 'const struct
> sockaddr_in'
> inet_ntop(s_sockaddr_in->sin_family, &s_sockaddr_in->sin_addr, res,
> INET_ADDRSTRLEN);
>^
> expander.cc:30:16: note: forward declaration of 'sockaddr_in'
> const struct sockaddr_in *s_sockaddr_in;
>^
> expander.cc:45:29: error: member access into incomplete type 'const struct
> sockaddr_in6'
> inet_ntop(s_sockaddr_in6->sin6_family, &s_sockaddr_in6->sin6_addr, res,
> INET6_ADDRSTRLEN);
> ^
> expander.cc:31:16: note: forward declaration of 'sockaddr_in6'
> const struct sockaddr_in6 *s_sockaddr_in6;
>^
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (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 updated TS-2822: Backport to Version: (was: 4.2.2) > 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: 4.2.2, 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-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2822: Fix Version/s: 4.2.2 > 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: 4.2.2, 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] [Assigned] (TS-2784) header_rewrite fails to build on FreeBSD(10)
[
https://issues.apache.org/jira/browse/TS-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber reassigned TS-2784:
---
Assignee: Phil Sorber (was: Leif Hedstrom)
> header_rewrite fails to build on FreeBSD(10)
>
>
> Key: TS-2784
> URL: https://issues.apache.org/jira/browse/TS-2784
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 5.0.0
>
>
> {code}
> CXX expander.lo
> expander.cc:41:28: error: member access into incomplete type 'const struct
> sockaddr_in'
> inet_ntop(s_sockaddr_in->sin_family, &s_sockaddr_in->sin_addr, res,
> INET_ADDRSTRLEN);
>^
> expander.cc:30:16: note: forward declaration of 'sockaddr_in'
> const struct sockaddr_in *s_sockaddr_in;
>^
> expander.cc:45:29: error: member access into incomplete type 'const struct
> sockaddr_in6'
> inet_ntop(s_sockaddr_in6->sin6_family, &s_sockaddr_in6->sin6_addr, res,
> INET6_ADDRSTRLEN);
> ^
> expander.cc:31:16: note: forward declaration of 'sockaddr_in6'
> const struct sockaddr_in6 *s_sockaddr_in6;
>^
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1486: -- Issue Type: Task (was: Improvement) > drop solaris studio support > --- > > Key: TS-1486 > URL: https://issues.apache.org/jira/browse/TS-1486 > Project: Traffic Server > Issue Type: Task > Components: Core, Portability >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > We should drop Solaris Studio support for the 3.4 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1062) Introduce extended FetchSM API
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1062: -- Issue Type: Improvement (was: Bug) > Introduce extended FetchSM API > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: James Peach >Assignee: Yunkai Zhang > Fix For: 5.0.0 > > Attachments: 0001-TS-1062-Extends-and-optimizes-FetchSM.patch, > 0002-TS-1062-Implement-dechunk-supporting-for-extended-Fe.patch, > 0003-TS-1062-Make-TSFetchUrl-handle-chunked-encoding-auto.patch > > > 1) Introduce extended FetchSM APIs, which will be used by SPDY. > 2) Make TSFetchUrl() dechunk encoding automatically: > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1486: -- Issue Type: Improvement (was: Bug) > drop solaris studio support > --- > > Key: TS-1486 > URL: https://issues.apache.org/jira/browse/TS-1486 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Portability >Reporter: James Peach >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > We should drop Solaris Studio support for the 3.4 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2784) header_rewrite fails to build on FreeBSD(10)
[
https://issues.apache.org/jira/browse/TS-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013254#comment-14013254
]
ASF subversion and git services commented on TS-2784:
-
Commit 0c8d513018a6857f3ea67e3db56d239c9d8f8ccc in trafficserver's branch
refs/heads/4.2.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0c8d513 ]
TS-2784 Fix build for FreeBSD10
(cherry picked from commit 3b6748ed2117cd824049498508fa3b1609f5638a)
> header_rewrite fails to build on FreeBSD(10)
>
>
> Key: TS-2784
> URL: https://issues.apache.org/jira/browse/TS-2784
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 4.2.2, 5.0.0
>
>
> {code}
> CXX expander.lo
> expander.cc:41:28: error: member access into incomplete type 'const struct
> sockaddr_in'
> inet_ntop(s_sockaddr_in->sin_family, &s_sockaddr_in->sin_addr, res,
> INET_ADDRSTRLEN);
>^
> expander.cc:30:16: note: forward declaration of 'sockaddr_in'
> const struct sockaddr_in *s_sockaddr_in;
>^
> expander.cc:45:29: error: member access into incomplete type 'const struct
> sockaddr_in6'
> inet_ntop(s_sockaddr_in6->sin6_family, &s_sockaddr_in6->sin6_addr, res,
> INET6_ADDRSTRLEN);
> ^
> expander.cc:31:16: note: forward declaration of 'sockaddr_in6'
> const struct sockaddr_in6 *s_sockaddr_in6;
>^
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2822) Crash in LogBufferIterator::next
[ https://issues.apache.org/jira/browse/TS-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013255#comment-14013255 ] ASF subversion and git services commented on TS-2822: - Commit a0f821eb6aa3a4f04edbbe623ed4d85f4054c381 in trafficserver's branch refs/heads/4.2.x from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a0f821e ] [TS-2822] Crash in LogBufferIterator::next (cherry picked from commit 13453d9ab8c975fd12da632a49868eeaf2eb1fd3) > 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: 4.2.2, 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-2784) header_rewrite fails to build on FreeBSD(10)
[
https://issues.apache.org/jira/browse/TS-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2784:
Fix Version/s: 4.2.2
> header_rewrite fails to build on FreeBSD(10)
>
>
> Key: TS-2784
> URL: https://issues.apache.org/jira/browse/TS-2784
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 4.2.2, 5.0.0
>
>
> {code}
> CXX expander.lo
> expander.cc:41:28: error: member access into incomplete type 'const struct
> sockaddr_in'
> inet_ntop(s_sockaddr_in->sin_family, &s_sockaddr_in->sin_addr, res,
> INET_ADDRSTRLEN);
>^
> expander.cc:30:16: note: forward declaration of 'sockaddr_in'
> const struct sockaddr_in *s_sockaddr_in;
>^
> expander.cc:45:29: error: member access into incomplete type 'const struct
> sockaddr_in6'
> inet_ntop(s_sockaddr_in6->sin6_family, &s_sockaddr_in6->sin6_addr, res,
> INET6_ADDRSTRLEN);
> ^
> expander.cc:31:16: note: forward declaration of 'sockaddr_in6'
> const struct sockaddr_in6 *s_sockaddr_in6;
>^
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2784) header_rewrite fails to build on FreeBSD(10)
[
https://issues.apache.org/jira/browse/TS-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2784:
Backport to Version: (was: 4.2.2)
> header_rewrite fails to build on FreeBSD(10)
>
>
> Key: TS-2784
> URL: https://issues.apache.org/jira/browse/TS-2784
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 4.2.2, 5.0.0
>
>
> {code}
> CXX expander.lo
> expander.cc:41:28: error: member access into incomplete type 'const struct
> sockaddr_in'
> inet_ntop(s_sockaddr_in->sin_family, &s_sockaddr_in->sin_addr, res,
> INET_ADDRSTRLEN);
>^
> expander.cc:30:16: note: forward declaration of 'sockaddr_in'
> const struct sockaddr_in *s_sockaddr_in;
>^
> expander.cc:45:29: error: member access into incomplete type 'const struct
> sockaddr_in6'
> inet_ntop(s_sockaddr_in6->sin6_family, &s_sockaddr_in6->sin6_addr, res,
> INET6_ADDRSTRLEN);
> ^
> expander.cc:31:16: note: forward declaration of 'sockaddr_in6'
> const struct sockaddr_in6 *s_sockaddr_in6;
>^
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2274: -- Issue Type: Improvement (was: Bug) > Better initial default configs > -- > > Key: TS-2274 > URL: https://issues.apache.org/jira/browse/TS-2274 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Miles Libbey >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > Seems like there are several config values that are not very smart for the > newbie user: > - cache size: storage.config: var/trafficserver 256M > - max object size (though, perhaps this is now unlimited) > - read-while-write settings? > - 4-5 volumes for the volume config? > - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? > Adam Dace in > https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested > several others, but, it looks to me like the settings are very machine > specific (eg, specific IP addresses) > Others? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2542) Turn on caching zero length responses by default
[ https://issues.apache.org/jira/browse/TS-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2542: -- Issue Type: Improvement (was: Bug) > Turn on caching zero length responses by default > > > Key: TS-2542 > URL: https://issues.apache.org/jira/browse/TS-2542 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Bryan Call >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > > 301 response is not being cached in forward proxy mode if content length is > zero bytes. > Test with a zero byte content length - doing multiple requests: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:44:03 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 0 > Content-Type: text/html; charset=UTF-8 > Age: 0 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t > cCMi p sS]) > Is cached if the content length is non-zero: > [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s > http://homer.bryancall.com/301.php > HTTP/1.1 301 Moved Permanently > Date: Wed, 29 Jan 2014 23:48:11 GMT > Server: ATS > X-Powered-By: PHP/5.5.7 > Location: http://www.yahoo.com/ > Content-Length: 4 > Content-Type: text/html; charset=UTF-8 > Age: 7 > Proxy-Connection: keep-alive > Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t > cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2349) move command-line tools to obvious places
[ https://issues.apache.org/jira/browse/TS-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2349: -- Issue Type: Improvement (was: Bug) > move command-line tools to obvious places > - > > Key: TS-2349 > URL: https://issues.apache.org/jira/browse/TS-2349 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup, Core, Quality >Reporter: James Peach >Assignee: James Peach > Fix For: 5.0.0 > > > It's often difficult to figure out where the source for a given command-line > tools lives. This makes it hard to navigate the source tree, but also hard to > decouple the build dependencies. > Moving these tools to an obvious source tree location is a small change that > can help this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2723: -- Issue Type: New Feature (was: Bug) > Add new features for ts_lua. > > > Key: TS-2723 > URL: https://issues.apache.org/jira/browse/TS-2723 > Project: Traffic Server > Issue Type: New Feature > Components: Lua, Plugins >Reporter: portl4t >Assignee: Kit Chan > Fix For: 5.0.0 > > Attachments: 0001-TS-2723-add-new-features-for-ts_lua.patch, > 0001-TS-2723-refine-doc-for-ts_lua.patch, > 0002-TS-2723-add-new-features-for-ts_lua.patch > > > After TS-2555, Kit Chan and me will integrate new features from > https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2632: -- Issue Type: Improvement (was: Bug) > Range request will always lock object in cache, even thought it's rarely > cacheable > -- > > Key: TS-2632 > URL: https://issues.apache.org/jira/browse/TS-2632 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.0.0 > > Attachments: range.diff > > > Right now, if a client sends a Range: request, we still lock the URL in the > cache, under the assumption that it will be written to. Since we don't > support partial objects, in almost all cases, we'll not write the object and > therefore release the object. > I suggest we change this such that we never try to write lock a URL in the > presence of a Range: header in the client request. This will allow other > requests to go to origin faster, and better yet, it allows a request without > a Range: header to properly lock the URL for writing. This turns out to be > important for implementing e.g. "background filling" as a plugin. > There is one use case where this might be useful; If the origin does not > respond with a 206 (partial object), we can now cache the full object. > However, this is a pretty rare case, and for someone to support this, all you > have to do is to remove the Range: header on the request. > I'm opening up this bug right now for discussion, if anyone have any concerns > about this change, please let me know. It is an "incompatible" change, > without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2753) Add more SPDY and HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2753: Attachment: (was: TS-2802_2.diff) > Add more SPDY and HTTPS statistics > --- > > Key: TS-2753 > URL: https://issues.apache.org/jira/browse/TS-2753 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Wei Sun >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: TS-2753_1.diff, TS-2802_2.diff > > > Adding stats to spdy helps monitoring and troubleshooting, it would be good > to define and add spdy specific stats. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2753) Add more SPDY and HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2753: Attachment: TS-2802_2.diff Convert the naming in terms of James's comment, thanks. > Add more SPDY and HTTPS statistics > --- > > Key: TS-2753 > URL: https://issues.apache.org/jira/browse/TS-2753 > Project: Traffic Server > Issue Type: Improvement > Components: SPDY >Reporter: Wei Sun >Assignee: Bryan Call > Labels: spdy, yahoo > Fix For: 5.0.0 > > Attachments: TS-2753_1.diff, TS-2802_2.diff > > > Adding stats to spdy helps monitoring and troubleshooting, it would be good > to define and add spdy specific stats. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2737) rfc5861 (stale-while-revalidate) is not an intuitive name
[ https://issues.apache.org/jira/browse/TS-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2737: -- Issue Type: Improvement (was: Bug) > rfc5861 (stale-while-revalidate) is not an intuitive name > - > > Key: TS-2737 > URL: https://issues.apache.org/jira/browse/TS-2737 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Igor Galić >Assignee: Phil Sorber > Fix For: 5.0.0 > > > Can we please rename this plugin to make it a little clearer to users what it > does? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2755) API is missing TSTextLogObjectRollingEnabledSet argument values
[
https://issues.apache.org/jira/browse/TS-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2755:
--
Issue Type: Improvement (was: Bug)
> API is missing TSTextLogObjectRollingEnabledSet argument values
> ---
>
> Key: TS-2755
> URL: https://issues.apache.org/jira/browse/TS-2755
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> The argument to {{TSTextLogObjectRollingEnabledSet}} is a value of type
> {{LogConfig::RollingEnabledValues}}, however these values are not exposed by
> the API.
> I'm going to fix this by using the {{enabled}} argument to
> {{TSTextLogObjectRollingEnabledSet}} as a boolean, since that is consistent
> with similar APIs. If rolling is enabled, then you will always get
> {{ROLL_ON_TIME_OR_SIZE}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2480: -- Issue Type: Improvement (was: Wish) > Choose the address related SSL_CTX for session ticket callback > -- > > Key: TS-2480 > URL: https://issues.apache.org/jira/browse/TS-2480 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Wei Sun >Assignee: James Peach > Labels: review > Fix For: 5.0.0 > > Attachments: TS-2480.diff > > > When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX > retrieved from the request when presenting session ticket or session id is > not associated with any app data (certs, settings, etc), ats delays the > association in SNI handling. So in the callback of > SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the > expected SSL_CTX, and session ticket handling will be degraded to the default > behavior. > I have a requirement of retrieving SSL_CTX during these two callback > functions, probably I could workaround it by > SSLCertificateConfig::acquire()->findInfoInHash(ip) in every callback and get > the expected SSL_CTX. I'm wondering is it feasible to do it once in > make_ssl_connection()? Is there any design consideration for being this > (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it > is needed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2652) atscppapi: Allow developers to cancel AsyncHttpFetch in specific and AsyncProviders in general
[ https://issues.apache.org/jira/browse/TS-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2652: -- Issue Type: Improvement (was: Wish) > atscppapi: Allow developers to cancel AsyncHttpFetch in specific and > AsyncProviders in general > -- > > Key: TS-2652 > URL: https://issues.apache.org/jira/browse/TS-2652 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Manjesh Nilange >Assignee: Brian Geffon > Fix For: 5.0.0 > > > Use case - if a plugin starts an async http fetch but wants to cancel it > before completion (timeout or something), the options available today are > 1) setting some state in the plugin and using this to ignore the callback. > 2) delete receiver (most cases a transaction plugin). > #1 is ugly and #2 is not possible always (there may be other things the > plugin wants to do). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2019) find out what is the problem of reporting OpenReadHead failed on vector inconsistency
[
https://issues.apache.org/jira/browse/TS-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2019:
--
Issue Type: Bug (was: Task)
> find out what is the problem of reporting OpenReadHead failed on vector
> inconsistency
> -
>
> Key: TS-2019
> URL: https://issues.apache.org/jira/browse/TS-2019
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Zhao Yongming
>Assignee: Alan M. Carroll
>Priority: Critical
> Fix For: 4.2.0, 5.0.0
>
>
> {code}
> [Jul 10 19:40:33.170] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey 44B5C68B : vector inconsistency with 4624
> [Jul 10 19:40:33.293] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey 2ABA746F : vector inconsistency with 4632
> [Jul 10 19:40:33.368] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey 389594A0 : vector inconsistency with 4632
> [Jul 10 19:40:33.399] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey FBC601A3 : vector inconsistency with 4632
> [Jul 10 19:40:33.506] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey 1F39AD5F : vector inconsistency with 4632
> [Jul 10 19:40:33.602] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey ABFC6D97 : vector inconsistency with 4632
> [Jul 10 19:40:33.687] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey 2420ABBF : vector inconsistency with 4632
> [Jul 10 19:40:33.753] Server {0x2aaf1680} NOTE: OpenReadHead failed for
> cachekey 5DD061C8 : vector inconsistency with 4632
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2580) SSL Connection reset by peer errors in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013364#comment-14013364
]
kang li commented on TS-2580:
-
This log imported in the patch of
[TS-2096|https://issues.apache.org/jira/browse/TS-2096]. As before this patch,
{quote}
We were passing a format string to SSLDiagnostic(), but never
actually using it when we logged the error.
{quote}
> SSL Connection reset by peer errors in 4.2.0-rc0
>
>
> Key: TS-2580
> URL: https://issues.apache.org/jira/browse/TS-2580
> Project: Traffic Server
> Issue Type: Bug
> Components: Network, SSL
>Affects Versions: 4.2.0
>Reporter: David Carlin
>Assignee: Bryan Call
>Priority: Blocker
> Fix For: 5.0.0
>
>
> This error is filling /var/log/messages when using 4.2.0-rc0:
> {noformat}Feb 20 04:44:33 l1 traffic_server[28428]: {0x2adcd9029700} ERROR:
> [SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
> error: Connection reset by peer{noformat}
> Did something change in the logging level and the connection resets are
> normal?
> Whats interesting is that this problem comes and goes as I progress through
> the git bisect for TS-2564, so I may need to do another git bisect for this
> issue.
> TS-2548 would help me troubleshoot this via tcpdump.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
