[jira] [Updated] (TS-4223) ERROR: [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)

[bettydramit (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

bettydramit updated TS-4223:

Description: 
update to 6.1.1

configure
./configure --enable-layout=Gentoo  --libdir=%{_libdir}/trafficserver   
--enable-hwloc


when exec traffic_ctl config reload

lot of  [Feb 23 14:20:13.554] Manager {0x7f4216adb840} ERROR: 
[LocalManager::pollMgmtProcessServer] select failed or was interrupted (4) at 
manager.log 

traffic.out
traffic_ctl: configuration reload request failed: [13] Operation not permitted.
traffic_ctl: configuration reload request failed: [13] Operation not permitted.
traffic_ctl: configuration reload request failed: [13] Operation not permitted.


new config will not reload success

  was:
update to 6.1.1


when exec traffic_ctl config reload

lot of  [Feb 23 14:20:13.554] Manager {0x7f4216adb840} ERROR: 
[LocalManager::pollMgmtProcessServer] select failed or was interrupted (4) at 
manager.log 

traffic.out
traffic_ctl: configuration reload request failed: [13] Operation not permitted.
traffic_ctl: configuration reload request failed: [13] Operation not permitted.
traffic_ctl: configuration reload request failed: [13] Operation not permitted.


new config will not reload success


> ERROR: [LocalManager::pollMgmtProcessServer] select failed or was interrupted 
> (4)
> -
>
> Key: TS-4223
> URL: https://issues.apache.org/jira/browse/TS-4223
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: bettydramit
>Priority: Critical
> Fix For: sometime
>
>
> update to 6.1.1
> configure
> ./configure --enable-layout=Gentoo  --libdir=%{_libdir}/trafficserver   
> --enable-hwloc
> when exec traffic_ctl config reload
> lot of  [Feb 23 14:20:13.554] Manager {0x7f4216adb840} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4) at 
> manager.log 
> traffic.out
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> new config will not reload success



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4223) new config will not reload success ERROR: [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)

[bettydramit (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15170321#comment-15170321
 ] 

bettydramit commented on TS-4223:
-

[~zwoop] Sorry, reload success.
but with a lot of "select failed or was interrupted (4) "

> new config will not reload success  ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)
> -
>
> Key: TS-4223
> URL: https://issues.apache.org/jira/browse/TS-4223
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: bettydramit
>Priority: Critical
> Fix For: sometime
>
>
> update to 6.1.1
> when exec traffic_ctl config reload
> lot of  [Feb 23 14:20:13.554] Manager {0x7f4216adb840} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4) at 
> manager.log 
> traffic.out
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> new config will not reload success



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4223) ERROR: [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)

[bettydramit (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

bettydramit updated TS-4223:

Summary: ERROR: [LocalManager::pollMgmtProcessServer] select failed or was 
interrupted (4)  (was: new config will not reload success  ERROR: 
[LocalManager::pollMgmtProcessServer] select failed or was interrupted (4))

> ERROR: [LocalManager::pollMgmtProcessServer] select failed or was interrupted 
> (4)
> -
>
> Key: TS-4223
> URL: https://issues.apache.org/jira/browse/TS-4223
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: bettydramit
>Priority: Critical
> Fix For: sometime
>
>
> update to 6.1.1
> when exec traffic_ctl config reload
> lot of  [Feb 23 14:20:13.554] Manager {0x7f4216adb840} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4) at 
> manager.log 
> traffic.out
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> new config will not reload success



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4233) ATS on AARCH64 with 64K page kernel crashes

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15170141#comment-15170141
 ] 

ASF GitHub Bot commented on TS-4233:


GitHub user shaygalon opened a pull request:

https://github.com/apache/trafficserver/pull/502

TS-4233 AARCH64 48b va freelist fix

Tested on linux aarch64 Cavium ThunderX platform, 4.2 kernel configured 
with 64K pages. 
Crashes during freelist operations when trying to access pointer after sign 
extension.

Freelist pointer versioning sign extends upper 16 bits. Does not work well 
for 48b va on aarch64.
Patch clears the upper 16 bits instead.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shaygalon/trafficserver master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/502.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #502


commit f304c50a2c00d7d711015c981b2007dacdf159b7
Author: Shay Gal-On 
Date:   2016-02-26T23:46:01Z

TS-4233 AARCH64 48b va freelist fix




> ATS on AARCH64 with 64K page kernel crashes
> ---
>
> Key: TS-4233
> URL: https://issues.apache.org/jira/browse/TS-4233
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Shay Gal-On
> Fix For: sometime
>
>
> Tested on linux aarch64 Cavium ThunderX platform, 4.2 kernel configured with 
> 64K pages. Crashes are caused by 2 issues:
> 1. Freelist pointer versioning sign extends upper 16 bits. Does not work well 
> for 48b va on aarch64.
> Patch:
> --- orig-trafficserver-5.3.2/lib/ts/ink_queue.h 2015-09-08 13:05:06.0 
> -0700
> +++ trafficserver-5.3.2/lib/ts/ink_queue.h  2016-02-18 09:02:36.899451000 
> -0800
> @@ -135,11 +135,16 @@
>  #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) \
>(_x).s.pointer = _p;   \
>(_x).s.version = _v
> -#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__) || 
> defined(__aarch64__)
> +#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__)
>  #define FREELIST_POINTER(_x) \
>((void *)(intptr_t)(_x).data) << 16) >> 16) | 
> (((~intptr_t)(_x).data) << 16 >> 63) - 1)) >> 48) << 48))) // sign extend
>  #define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
>  #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
> intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
> +#elif defined(__aarch64__)
> +#define FREELIST_POINTER(_x) \
> +  ((void *)(intptr_t)(_x).data) & 0xULL  // clear 
> the version
> +#define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
> +#define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
> intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
>  #else
>  #error "unsupported processor"
>  #endif
> 2. The iocore cache sets the STORE_BLOCK_SIZE to 8k. However, in order to 
> mmap files, the size has to be a multiple of kernel page size, so that with 
> 64K pages it is possible to get bad offsets when remapping the cache blocks. 
> Following patch wraps the block size, and adds configure check for 64K pages 
> to override it in that case.
> diff -Naur orig-trafficserver-5.3.2/iocore/cache/I_Store.h 
> trafficserver-5.3.2/iocore/cache/I_Store.h
> --- orig-trafficserver-5.3.2/iocore/cache/I_Store.h 2015-09-08 
> 13:05:06.0 -0700
> +++ trafficserver-5.3.2/iocore/cache/I_Store.h  2016-02-18 08:52:32.459451000 
> -0800
> @@ -33,7 +33,9 @@
>  #include "libts.h"
> +#ifndef STORE_BLOCK_SIZE
>  #define STORE_BLOCK_SIZE 8192
> +#endif
>  #define STORE_BLOCK_SHIFT 13
>  #define DEFAULT_HW_SECTOR_SIZE 512
> --- orig-trafficserver-5.3.2/configure.ac   2015-09-08 13:05:06.0 
> -0700
> +++ trafficserver-5.3.2/configure.ac2016-02-26 11:09:12.099451000 -0800
> @@ -1324,6 +1324,14 @@
>TS_ADDTO(CFLAGS, [-mcx16])
>TS_ADDTO(CXXFLAGS, [-mcx16])
>  ])
> +AC_MSG_CHECKING([TESTING KERNEL PAGE SIZE])
> +kernel_page_size=`getconf PAGE_SIZE`
> +AS_IF([test "x${kernel_page_size}" = "x65536"],
> +[
> +  TS_ADDTO(CXXFLAGS, [-DSTORE_BLOCK_SIZE=65536])
> +]
> +)
> +AC_MSG_RESULT([$kernel_page_size])
>  # Check for POSIX capabilities library.
>  # If we don't find it, disable checking for header.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: freebsd_10-master » clang,freebsd_10,debug #730

[jenkins]

See 


--
[...truncated 2936 lines...]
libtool: compile:  clang -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/regex_revalidate -I../../../lib 
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -DDEBUG -D_DEBUG -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6 
-std=gnu99 -ggdb3 -pipe -Wall -Wno-deprecated-declarations -Qunused-arguments 
-Werror -mcx16 -MT regex_revalidate.lo -MD -MP -MF .deps/regex_revalidate.Tpo 
-c ../../../../plugins/experimental/regex_revalidate/regex_revalidate.c  -fPIC 
-DPIC -o .libs/regex_revalidate.o
/bin/sh ../../../libtool  --tag=CC   --mode=link clang  -std=gnu99 -ggdb3 -pipe 
-Wall -Wno-deprecated-declarations -Qunused-arguments -Werror -mcx16 -module 
-shared -avoid-version -export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
 -L/usr/local/lib -Wl,-R/usr/local/lib -o regex_revalidate.la -rpath 

 regex_revalidate.lo  -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread 
libtool: link: /usr/bin/nm -B  .libs/regex_revalidate.o   | sed -n -e 's/^.*[   
 ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | 
/usr/local/bin/gsed 's/.* //' | sort | uniq > .libs/regex_revalidate.exp
libtool: link: /usr/bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/regex_revalidate.exp" > ".libs/regex_revalidate.expT"
libtool: link: mv -f ".libs/regex_revalidate.expT" ".libs/regex_revalidate.exp"
libtool: link: clang -shared  -fPIC -DPIC  .libs/regex_revalidate.o   
-L/usr/local/lib -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread  -mcx16 
-Wl,-R/usr/local/lib   -Wl,-soname -Wl,regex_revalidate.so 
-Wl,-retain-symbols-file -Wl,.libs/regex_revalidate.exp -o 
.libs/regex_revalidate.so
libtool: link: ( cd ".libs" && rm -f "regex_revalidate.la" && ln -s 
"../regex_revalidate.la" "regex_revalidate.la" )
gmake[3]: Leaving directory 
'
Making all in remap_stats
gmake[3]: Entering directory 
'
gmake[3]: Nothing to be done for 'all'.
gmake[3]: Leaving directory 
'
Making all in s3_auth
gmake[3]: Entering directory 
'
depbase=`echo s3_auth.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/s3_auth -I../../../lib  
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -DDEBUG -D_DEBUG -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6  
-Qunused-arguments -std=c++11 -std=c++11 -ggdb3 -pipe -Wall 
-Wno-deprecated-declarations -Werror -Wno-invalid-offsetof -mcx16 -MT 
s3_auth.lo -MD -MP -MF $depbase.Tpo -c -o s3_auth.lo 
../../../../plugins/experimental/s3_auth/s3_auth.cc &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  clang++ -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/s3_auth -I../../../lib -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib -I/usr/local/include -Dfreebsd 
-DDEBUG -D_DEBUG -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE 
-D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6 -Qunused-arguments 
-std=c++11 -std=c++11 -ggdb3 -pipe -Wall -Wno-deprecated-declarations -Werror 
-Wno-invalid-offsetof -mcx16 -MT s3_auth.lo -MD -MP -MF .deps/s3_auth.Tpo -c 
../../../../plugins/experimental/s3_auth/s3_auth.cc  -fPIC -DPIC -o 
.libs/s3_auth.o
/bin/sh ../../../libtool  --tag=CXX   --mode=link clang++  -Qunused-arguments 
-std=c++11 -std=c++11 -ggdb3 -pipe -Wall -Wno-deprecated-declarations -Werror 
-Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 

Build failed in Jenkins: freebsd_10-master » clang,freebsd_10,release #730

[jenkins]

See 


--
[...truncated 2935 lines...]
libtool: compile:  clang -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/regex_revalidate -I../../../lib 
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6 -std=gnu99 -g -pipe -Wall 
-Wno-deprecated-declarations -Qunused-arguments -O3 -fno-strict-aliasing 
-Werror -mcx16 -MT regex_revalidate.lo -MD -MP -MF .deps/regex_revalidate.Tpo 
-c ../../../../plugins/experimental/regex_revalidate/regex_revalidate.c  -fPIC 
-DPIC -o .libs/regex_revalidate.o
/bin/sh ../../../libtool  --tag=CC   --mode=link clang  -std=gnu99 -g -pipe 
-Wall -Wno-deprecated-declarations -Qunused-arguments -O3 -fno-strict-aliasing 
-Werror -mcx16 -module -shared -avoid-version -export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
 -L/usr/local/lib -Wl,-R/usr/local/lib -o regex_revalidate.la -rpath 

 regex_revalidate.lo  -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread 
libtool: link: /usr/bin/nm -B  .libs/regex_revalidate.o   | sed -n -e 's/^.*[   
 ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | 
/usr/local/bin/gsed 's/.* //' | sort | uniq > .libs/regex_revalidate.exp
libtool: link: /usr/bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/regex_revalidate.exp" > ".libs/regex_revalidate.expT"
libtool: link: mv -f ".libs/regex_revalidate.expT" ".libs/regex_revalidate.exp"
libtool: link: clang -shared  -fPIC -DPIC  .libs/regex_revalidate.o   
-L/usr/local/lib -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread  -O3 
-mcx16 -Wl,-R/usr/local/lib   -Wl,-soname -Wl,regex_revalidate.so 
-Wl,-retain-symbols-file -Wl,.libs/regex_revalidate.exp -o 
.libs/regex_revalidate.so
libtool: link: ( cd ".libs" && rm -f "regex_revalidate.la" && ln -s 
"../regex_revalidate.la" "regex_revalidate.la" )
gmake[3]: Leaving directory 
'
Making all in remap_stats
gmake[3]: Entering directory 
'
gmake[3]: Nothing to be done for 'all'.
gmake[3]: Leaving directory 
'
Making all in s3_auth
gmake[3]: Entering directory 
'
depbase=`echo s3_auth.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/s3_auth -I../../../lib  
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6  -Qunused-arguments 
-std=c++11 -std=c++11 -g -pipe -Wall -Wno-deprecated-declarations -O3 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT s3_auth.lo -MD 
-MP -MF $depbase.Tpo -c -o s3_auth.lo 
../../../../plugins/experimental/s3_auth/s3_auth.cc &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  clang++ -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/s3_auth -I../../../lib -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib -I/usr/local/include -Dfreebsd 
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT 
-D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN 
-I/usr/local/include/tcl8.6 -Qunused-arguments -std=c++11 -std=c++11 -g -pipe 
-Wall -Wno-deprecated-declarations -O3 -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT s3_auth.lo -MD -MP -MF .deps/s3_auth.Tpo -c 
../../../../plugins/experimental/s3_auth/s3_auth.cc  -fPIC -DPIC -o 
.libs/s3_auth.o
/bin/sh ../../../libtool  --tag=CXX   --mode=link clang++  -Qunused-arguments 
-std=c++11 -std=c++11 -g -pipe -Wall -Wno-deprecated-declarations -O3 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -module 

Build failed in Jenkins: tsqa-master #1222

[jenkins]

See 

Changes:

[Bryan Call] TS-3938: Fixed FreeBSD - yet again on a different bug

--
[...truncated 1885 lines...]
return func()
  File 
"
 line 43, in setUpClass
super(TestRegressions, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 
"
 line 73, in poll_interfaces
reduce(lambda x, y: str(x) + ',' + str(y), hostports)))
Exception: Timeout waiting for interfaces: ('127.0.0.1', 33218)
 >> begin captured logging << 
root: INFO: Environment prefix is /tmp/tsqa.env.BlS1O4
root: INFO: Environment prefix is /tmp/tsqa.env.g4RZco
test_https: INFO: cp 

 

root: INFO: Environment prefix is /tmp/tsqa.env.DPR3iQ
root: INFO: Environment prefix is /tmp/tsqa.env.3gBV7S
root: INFO: Environment prefix is /tmp/tsqa.env.301q7f
root: INFO: Environment prefix is /tmp/tsqa.env.un1vir
root: INFO: Environment prefix is /tmp/tsqa.env.frjjwV
root: INFO: Environment prefix is /tmp/tsqa.env.jEUciY
root: INFO: Environment prefix is /tmp/tsqa.env.ND7PWY
root: INFO: Environment prefix is /tmp/tsqa.env.F1EcUk
root: INFO: Environment prefix is /tmp/tsqa.env.EAEdzZ
root: INFO: Environment prefix is /tmp/tsqa.env.b6SAIf
root: INFO: Environment prefix is /tmp/tsqa.env.fvFGnV
test_origin_min_keep_alive_connection: INFO: socket_server_port = 51148
test_origin_min_keep_alive_connection: INFO: starting the socket server
root: INFO: Environment prefix is /tmp/tsqa.env.4BaCao
root: INFO: Environment prefix is /tmp/tsqa.env.cWNVa5
- >> end captured logging << -

==
ERROR: test suite for 
--
Traceback (most recent call last):
  File 
"
 line 209, in run
self.setUp()
  File 
"
 line 292, in setUp
self.setupContext(ancestor)
  File 
"
 line 315, in setupContext
try_run(context, names)
  File 
"
 line 471, in try_run
return func()
  File 
"
 line 150, in setUpClass
super(DynamicHTTPEndpointCase, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 
"
 line 73, in poll_interfaces
reduce(lambda x, y: str(x) + ',' + str(y), hostports)))
Exception: Timeout waiting for interfaces: ('127.0.0.1', 40832)
 >> begin captured logging << 
root: INFO: Environment prefix is /tmp/tsqa.env.BlS1O4
root: INFO: Environment prefix is /tmp/tsqa.env.g4RZco
test_https: INFO: cp 

 

Build failed in Jenkins: tsqa-master #1221

[jenkins]

See 

Changes:

[James Peach] TS-4048: restore the Vagrantfile to life

--
[...truncated 1922 lines...]
try_run(context, names)
  File 
"
 line 471, in try_run
return func()
  File 
"
 line 150, in setUpClass
super(DynamicHTTPEndpointCase, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 
"
 line 73, in poll_interfaces
reduce(lambda x, y: str(x) + ',' + str(y), hostports)))
Exception: Timeout waiting for interfaces: ('127.0.0.1', 45894)
 >> begin captured logging << 
root: INFO: Environment prefix is /tmp/tsqa.env.XVuXL7
root: INFO: Environment prefix is /tmp/tsqa.env.UYsoeX
test_https: INFO: cp 

 

root: INFO: Environment prefix is /tmp/tsqa.env.HYoS_E
root: INFO: Environment prefix is /tmp/tsqa.env.F4Qiml
root: INFO: Environment prefix is /tmp/tsqa.env.j80bjx
root: INFO: Environment prefix is /tmp/tsqa.env.xet9Q_
root: INFO: Environment prefix is /tmp/tsqa.env.d1OfGd
root: INFO: Environment prefix is /tmp/tsqa.env.ddk28u
root: INFO: Environment prefix is /tmp/tsqa.env.fr3E_w
root: INFO: Environment prefix is /tmp/tsqa.env.nXID58
root: INFO: Environment prefix is /tmp/tsqa.env.ke4cx_
root: INFO: Environment prefix is /tmp/tsqa.env.Ohep_V
root: INFO: Environment prefix is /tmp/tsqa.env.e5UbaT
test_origin_min_keep_alive_connection: INFO: socket_server_port = 51875
test_origin_min_keep_alive_connection: INFO: starting the socket server
root: INFO: Environment prefix is /tmp/tsqa.env.dDB0IU
root: INFO: Environment prefix is /tmp/tsqa.env.QBq1DH
tsqa.environment: INFO: Starting build (d133993325226bee52737bbab4e1cbc1): 
configure {'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'enable-linux-native-aio': None, 'disable-dependency-tracking': None}
root: INFO: Environment prefix is /tmp/tsqa.env.OFM2yg
- >> end captured logging << -

==
ERROR: test suite for 
--
Traceback (most recent call last):
  File 
"
 line 209, in run
self.setUp()
  File 
"
 line 292, in setUp
self.setupContext(ancestor)
  File 
"
 line 315, in setupContext
try_run(context, names)
  File 
"
 line 471, in try_run
return func()
  File 
"
 line 150, in setUpClass
super(DynamicHTTPEndpointCase, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 

[jira] [Commented] (TS-3938) Add hardening (fortify) as an option to configure

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169853#comment-15169853
 ] 

ASF subversion and git services commented on TS-3938:
-

Commit 5731dbb80bf734a6aaecb0092a19404d7d08100a in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5731dbb ]

TS-3938: Fixed FreeBSD - yet again on a different bug


> Add hardening (fortify) as an option to configure
> -
>
> Key: TS-3938
> URL: https://issues.apache.org/jira/browse/TS-3938
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: sometime
>
>
> It might be useful to add an option, e.g. --with-hardening, such that we can 
> build with various hardening compiler options. For example. I've used
> {code}
> CC="/opt/gcc5/bin/gcc"; export CC
> CXX="/opt/gcc5/bin/g++"; export CXX
> CFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CFLAGS
> CXXFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CXXFLAGS
> CPPFLAGS="-D_FORTIFY_SOURCE=2"; export CPPFLAGS
> LDFLAGS="-Wl,-z,relro -Wl,-z,now"; export LDFLAGS
> "./configure" \
> "--enable-experimental-plugins" \
> "--prefix=/opt/ats" \
> "CC=/opt/gcc5/bin/gcc" \
> "CXX=/opt/gcc5/bin/g++" \
> "CFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CXXFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CPPFLAGS=-D_FORTIFY_SOURCE=2" \
> "LDFLAGS=-Wl,-z,relro -Wl,-z,now" \
> "$@"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to all requests during cache refresh.

[Sudheer Vinukonda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda reassigned TS-4238:
-

Assignee: Sudheer Vinukonda

> Enhance Open Write Fail Action feature to allow serving stale copy to all 
> requests during cache refresh.
> 
>
> Key: TS-4238
> URL: https://issues.apache.org/jira/browse/TS-4238
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> This is a follow up enhancement for TS-3549 (and related jiras). Open Write 
> Fail Action feature developed with TS-3549 currently allows returning a stale 
> copy to every client (based on a cache open write failure), except the first 
> client that initiated a cache revalidation. This jira is opened to enhance 
> the feature to support returning the stale copy even to the first client, 
> essentially triggering the revalidation in the background (ala background 
> fill feature), so as to be able to use the feature as a substitute for SWR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4237) Enhance Open Write Fail Action feature to support an option to honor SWR RFC headers.

[Sudheer Vinukonda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda reassigned TS-4237:
-

Assignee: Sudheer Vinukonda

> Enhance Open Write Fail Action feature to support an option to honor SWR RFC 
> headers.
> -
>
> Key: TS-4237
> URL: https://issues.apache.org/jira/browse/TS-4237
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>
> This is a follow up enhancement for TS-3549 (and related jiras). Open Write 
> Fail Action feature developed with TS-3549 currently supports the following 
> options:
> https://docs.trafficserver.apache.org/en/6.0.x/reference/configuration/records.config.en.html#proxy-config-http-cache-open-write-fail-action
> {code}
> 0 = default, disable cache and goto origin server
> 1 = return a 502 error on a cache miss
> 2 = serve stale if object’s age is under 
> proxy.config.http.cache.max_stale_age, else, goto origin server
> {code}
> This jira is opened to enhance the feature to support a new option to serve 
> stale honoring the SWR RFC headers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4048) Broken Vagrantfile in a lot of ways

[James Peach (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach resolved TS-4048.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: (was: sometime)
   6.2.0

> Broken Vagrantfile in a lot of ways
> ---
>
> Key: TS-4048
> URL: https://issues.apache.org/jira/browse/TS-4048
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Tools
>Reporter: Christoph Keller
>Assignee: James Peach
>Priority: Minor
> Fix For: 6.2.0
>
>
> The Vagrant-File seems to be broken.
> 1. I tried to "vagrant up centos64" which failed due to files that could not 
> be downloaded during provisioning.
> 2. Saucy Images are no longer available and should be removed from 
> Vagrantfile.
> 3. I guess it would be better to use sshfs instead of nfs for the shared 
> folder due to the fact that a lot of people use encrypted home-directories 
> these days which makes mounting the shared folder fail. You don't even get a 
> proper errormessage for that.
> I didn't check all resources refered to by either Vagrantfile or the puppet 
> files but i guess there are even more broken links.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4048) Broken Vagrantfile in a lot of ways

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169831#comment-15169831
 ] 

ASF GitHub Bot commented on TS-4048:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/490#issuecomment-18948
  
Thanks @christoph-k86!


> Broken Vagrantfile in a lot of ways
> ---
>
> Key: TS-4048
> URL: https://issues.apache.org/jira/browse/TS-4048
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Tools
>Reporter: Christoph Keller
>Priority: Minor
> Fix For: sometime
>
>
> The Vagrant-File seems to be broken.
> 1. I tried to "vagrant up centos64" which failed due to files that could not 
> be downloaded during provisioning.
> 2. Saucy Images are no longer available and should be removed from 
> Vagrantfile.
> 3. I guess it would be better to use sshfs instead of nfs for the shared 
> folder due to the fact that a lot of people use encrypted home-directories 
> these days which makes mounting the shared folder fail. You don't even get a 
> proper errormessage for that.
> I didn't check all resources refered to by either Vagrantfile or the puppet 
> files but i guess there are even more broken links.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4048) Broken Vagrantfile in a lot of ways

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169826#comment-15169826
 ] 

ASF GitHub Bot commented on TS-4048:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/490


> Broken Vagrantfile in a lot of ways
> ---
>
> Key: TS-4048
> URL: https://issues.apache.org/jira/browse/TS-4048
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Tools
>Reporter: Christoph Keller
>Priority: Minor
> Fix For: sometime
>
>
> The Vagrant-File seems to be broken.
> 1. I tried to "vagrant up centos64" which failed due to files that could not 
> be downloaded during provisioning.
> 2. Saucy Images are no longer available and should be removed from 
> Vagrantfile.
> 3. I guess it would be better to use sshfs instead of nfs for the shared 
> folder due to the fact that a lot of people use encrypted home-directories 
> these days which makes mounting the shared folder fail. You don't even get a 
> proper errormessage for that.
> I didn't check all resources refered to by either Vagrantfile or the puppet 
> files but i guess there are even more broken links.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4048) Broken Vagrantfile in a lot of ways

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169824#comment-15169824
 ] 

ASF subversion and git services commented on TS-4048:
-

Commit f057de3f2c94f00a8e58c2652ca8fed2221b2809 in trafficserver's branch 
refs/heads/master from [~hoody]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f057de3 ]

TS-4048: restore the Vagrantfile to life

  - removed a lot of broken stuff
  - added omnios and forced updates of packagelists
  - added OmniOS, speed up vm's with more cores and switch jessie
image to one with guest additions
  - we don't need thos puppet-files anymore because we use a shell
provisioner
  - added some boxes and fixed omnios
  - use prebuilt tcl instead of compiling
  - added license information
  - added optional dependencies

This closes #490.


> Broken Vagrantfile in a lot of ways
> ---
>
> Key: TS-4048
> URL: https://issues.apache.org/jira/browse/TS-4048
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Tools
>Reporter: Christoph Keller
>Priority: Minor
> Fix For: sometime
>
>
> The Vagrant-File seems to be broken.
> 1. I tried to "vagrant up centos64" which failed due to files that could not 
> be downloaded during provisioning.
> 2. Saucy Images are no longer available and should be removed from 
> Vagrantfile.
> 3. I guess it would be better to use sshfs instead of nfs for the shared 
> folder due to the fact that a lot of people use encrypted home-directories 
> these days which makes mounting the shared folder fail. You don't even get a 
> proper errormessage for that.
> I didn't check all resources refered to by either Vagrantfile or the puppet 
> files but i guess there are even more broken links.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4237) Enhance Open Write Fail Action feature to support an option to honor SWR RFC headers.

[Sudheer Vinukonda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda updated TS-4237:
--
Summary: Enhance Open Write Fail Action feature to support an option to 
honor SWR RFC headers.  (was: Enhance Open Write Fail Action feature to support 
an option to honor SWR RFC header.)

> Enhance Open Write Fail Action feature to support an option to honor SWR RFC 
> headers.
> -
>
> Key: TS-4237
> URL: https://issues.apache.org/jira/browse/TS-4237
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Sudheer Vinukonda
>
> This is a follow up enhancement for TS-3549 (and related jiras). Open Write 
> Fail Action feature developed with TS-3549 currently supports the following 
> options:
> https://docs.trafficserver.apache.org/en/6.0.x/reference/configuration/records.config.en.html#proxy-config-http-cache-open-write-fail-action
> {code}
> 0 = default, disable cache and goto origin server
> 1 = return a 502 error on a cache miss
> 2 = serve stale if object’s age is under 
> proxy.config.http.cache.max_stale_age, else, goto origin server
> {code}
> This jira is opened to enhance the feature to support a new option to serve 
> stale honoring the SWR RFC headers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to all requests during cache refresh.

[Sudheer Vinukonda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda updated TS-4238:
--
Summary: Enhance Open Write Fail Action feature to allow serving stale copy 
to all requests during cache refresh.  (was: Enhance Open Write Fail Action 
feature to allow serving stale copy to all requests while refreshing)

> Enhance Open Write Fail Action feature to allow serving stale copy to all 
> requests during cache refresh.
> 
>
> Key: TS-4238
> URL: https://issues.apache.org/jira/browse/TS-4238
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Sudheer Vinukonda
>
> This is a follow up enhancement for TS-3549 (and related jiras). Open Write 
> Fail Action feature developed with TS-3549 currently allows returning a stale 
> copy to every client (based on a cache open write failure), except the first 
> client that initiated a cache revalidation. This jira is opened to enhance 
> the feature to support returning the stale copy even to the first client, 
> essentially triggering the revalidation in the background (ala background 
> fill feature), so as to be able to use the feature as a substitute for SWR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to all requests while refreshing

[Sudheer Vinukonda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda updated TS-4238:
--
Summary: Enhance Open Write Fail Action feature to allow serving stale copy 
to all requests while refreshing  (was: Enhance Open Write Fail Action feature 
to allow serving stale copy to even the first client that initiated a refresh.)

> Enhance Open Write Fail Action feature to allow serving stale copy to all 
> requests while refreshing
> ---
>
> Key: TS-4238
> URL: https://issues.apache.org/jira/browse/TS-4238
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Sudheer Vinukonda
>
> This is a follow up enhancement for TS-3549 (and related jiras). Open Write 
> Fail Action feature developed with TS-3549 currently allows returning a stale 
> copy to every client (based on a cache open write failure), except the first 
> client that initiated a cache revalidation. This jira is opened to enhance 
> the feature to support returning the stale copy even to the first client, 
> essentially triggering the revalidation in the background (ala background 
> fill feature), so as to be able to use the feature as a substitute for SWR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: tsqa-master #1220

[jenkins]

See 

Changes:

[James Peach] TS-3938: Add hardening (fortify) as an option to configure

--
[...truncated 1922 lines...]
try_run(context, names)
  File 
"
 line 471, in try_run
return func()
  File 
"
 line 150, in setUpClass
super(DynamicHTTPEndpointCase, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 
"
 line 73, in poll_interfaces
reduce(lambda x, y: str(x) + ',' + str(y), hostports)))
Exception: Timeout waiting for interfaces: ('127.0.0.1', 36542)
 >> begin captured logging << 
root: INFO: Environment prefix is /tmp/tsqa.env.7g2b5E
root: INFO: Environment prefix is /tmp/tsqa.env.gIN27q
test_https: INFO: cp 

 

root: INFO: Environment prefix is /tmp/tsqa.env.QziHEP
root: INFO: Environment prefix is /tmp/tsqa.env.tWv7aU
root: INFO: Environment prefix is /tmp/tsqa.env.xYijej
root: INFO: Environment prefix is /tmp/tsqa.env.vaaGnj
root: INFO: Environment prefix is /tmp/tsqa.env.Wme6_w
root: INFO: Environment prefix is /tmp/tsqa.env.WLnF0B
root: INFO: Environment prefix is /tmp/tsqa.env.um9zSQ
root: INFO: Environment prefix is /tmp/tsqa.env.VX0UVd
root: INFO: Environment prefix is /tmp/tsqa.env.PH4X7b
root: INFO: Environment prefix is /tmp/tsqa.env.KU4CrM
root: INFO: Environment prefix is /tmp/tsqa.env.qdWFwa
test_origin_min_keep_alive_connection: INFO: socket_server_port = 48561
test_origin_min_keep_alive_connection: INFO: starting the socket server
root: INFO: Environment prefix is /tmp/tsqa.env.6B4sla
root: INFO: Environment prefix is /tmp/tsqa.env.CysAlv
tsqa.environment: INFO: Starting build (d133993325226bee52737bbab4e1cbc1): 
configure {'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'enable-linux-native-aio': None, 'disable-dependency-tracking': None}
root: INFO: Environment prefix is /tmp/tsqa.env.chGXMv
- >> end captured logging << -

==
ERROR: test suite for 
--
Traceback (most recent call last):
  File 
"
 line 209, in run
self.setUp()
  File 
"
 line 292, in setUp
self.setupContext(ancestor)
  File 
"
 line 315, in setupContext
try_run(context, names)
  File 
"
 line 471, in try_run
return func()
  File 
"
 line 150, in setUpClass
super(DynamicHTTPEndpointCase, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 

[jira] [Created] (TS-4238) Enhance Open Write Fail Action feature to allow serving stale copy to even the first client that initiated a refresh.

[Sudheer Vinukonda (JIRA)]

Sudheer Vinukonda created TS-4238:
-

 Summary: Enhance Open Write Fail Action feature to allow serving 
stale copy to even the first client that initiated a refresh.
 Key: TS-4238
 URL: https://issues.apache.org/jira/browse/TS-4238
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP
Reporter: Sudheer Vinukonda


This is a follow up enhancement for TS-3549 (and related jiras). Open Write 
Fail Action feature developed with TS-3549 currently allows returning a stale 
copy to every client (based on a cache open write failure), except the first 
client that initiated a cache revalidation. This jira is opened to enhance the 
feature to support returning the stale copy even to the first client, 
essentially triggering the revalidation in the background (ala background fill 
feature), so as to be able to use the feature as a substitute for SWR.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: freebsd_10-master » clang,freebsd_10,debug #729

[jenkins]

See 


--
[...truncated 2943 lines...]
libtool: compile:  clang -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/regex_revalidate -I../../../lib 
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -DDEBUG -D_DEBUG -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6 
-std=gnu99 -ggdb3 -pipe -Wall -Wno-deprecated-declarations -Qunused-arguments 
-Werror -mcx16 -MT regex_revalidate.lo -MD -MP -MF .deps/regex_revalidate.Tpo 
-c ../../../../plugins/experimental/regex_revalidate/regex_revalidate.c  -fPIC 
-DPIC -o .libs/regex_revalidate.o
/bin/sh ../../../libtool  --tag=CC   --mode=link clang  -std=gnu99 -ggdb3 -pipe 
-Wall -Wno-deprecated-declarations -Qunused-arguments -Werror -mcx16 -module 
-shared -avoid-version -export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
 -L/usr/local/lib -Wl,-R/usr/local/lib -o regex_revalidate.la -rpath 

 regex_revalidate.lo  -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread 
libtool: link: /usr/bin/nm -B  .libs/regex_revalidate.o   | sed -n -e 's/^.*[   
 ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | 
/usr/local/bin/gsed 's/.* //' | sort | uniq > .libs/regex_revalidate.exp
libtool: link: /usr/bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/regex_revalidate.exp" > ".libs/regex_revalidate.expT"
libtool: link: mv -f ".libs/regex_revalidate.expT" ".libs/regex_revalidate.exp"
libtool: link: clang -shared  -fPIC -DPIC  .libs/regex_revalidate.o   
-L/usr/local/lib -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread  -mcx16 
-Wl,-R/usr/local/lib   -Wl,-soname -Wl,regex_revalidate.so 
-Wl,-retain-symbols-file -Wl,.libs/regex_revalidate.exp -o 
.libs/regex_revalidate.so
libtool: link: ( cd ".libs" && rm -f "regex_revalidate.la" && ln -s 
"../regex_revalidate.la" "regex_revalidate.la" )
gmake[3]: Leaving directory 
'
Making all in remap_stats
gmake[3]: Entering directory 
'
gmake[3]: Nothing to be done for 'all'.
gmake[3]: Leaving directory 
'
Making all in s3_auth
gmake[3]: Entering directory 
'
depbase=`echo s3_auth.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/s3_auth -I../../../lib  
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -DDEBUG -D_DEBUG -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6  
-Qunused-arguments -std=c++11 -std=c++11 -ggdb3 -pipe -Wall 
-Wno-deprecated-declarations -Werror -Wno-invalid-offsetof -mcx16 -MT 
s3_auth.lo -MD -MP -MF $depbase.Tpo -c -o s3_auth.lo 
../../../../plugins/experimental/s3_auth/s3_auth.cc &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  clang++ -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/s3_auth -I../../../lib -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib -I/usr/local/include -Dfreebsd 
-DDEBUG -D_DEBUG -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE 
-D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6 -Qunused-arguments 
-std=c++11 -std=c++11 -ggdb3 -pipe -Wall -Wno-deprecated-declarations -Werror 
-Wno-invalid-offsetof -mcx16 -MT s3_auth.lo -MD -MP -MF .deps/s3_auth.Tpo -c 
../../../../plugins/experimental/s3_auth/s3_auth.cc  -fPIC -DPIC -o 
.libs/s3_auth.o
/bin/sh ../../../libtool  --tag=CXX   --mode=link clang++  -Qunused-arguments 
-std=c++11 -std=c++11 -ggdb3 -pipe -Wall -Wno-deprecated-declarations -Werror 
-Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 

Build failed in Jenkins: freebsd_10-master » clang,freebsd_10,release #729

[jenkins]

See 


--
[...truncated 2942 lines...]
libtool: compile:  clang -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/regex_revalidate -I../../../lib 
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6 -std=gnu99 -g -pipe -Wall 
-Wno-deprecated-declarations -Qunused-arguments -O3 -fno-strict-aliasing 
-Werror -mcx16 -MT regex_revalidate.lo -MD -MP -MF .deps/regex_revalidate.Tpo 
-c ../../../../plugins/experimental/regex_revalidate/regex_revalidate.c  -fPIC 
-DPIC -o .libs/regex_revalidate.o
/bin/sh ../../../libtool  --tag=CC   --mode=link clang  -std=gnu99 -g -pipe 
-Wall -Wno-deprecated-declarations -Qunused-arguments -O3 -fno-strict-aliasing 
-Werror -mcx16 -module -shared -avoid-version -export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
 -L/usr/local/lib -Wl,-R/usr/local/lib -o regex_revalidate.la -rpath 

 regex_revalidate.lo  -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread 
libtool: link: /usr/bin/nm -B  .libs/regex_revalidate.o   | sed -n -e 's/^.*[   
 ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | 
/usr/local/bin/gsed 's/.* //' | sort | uniq > .libs/regex_revalidate.exp
libtool: link: /usr/bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/regex_revalidate.exp" > ".libs/regex_revalidate.expT"
libtool: link: mv -f ".libs/regex_revalidate.expT" ".libs/regex_revalidate.exp"
libtool: link: clang -shared  -fPIC -DPIC  .libs/regex_revalidate.o   
-L/usr/local/lib -lexecinfo -lpcre -lexpat -llzma -lz -lcrypt -lpthread  -O3 
-mcx16 -Wl,-R/usr/local/lib   -Wl,-soname -Wl,regex_revalidate.so 
-Wl,-retain-symbols-file -Wl,.libs/regex_revalidate.exp -o 
.libs/regex_revalidate.so
libtool: link: ( cd ".libs" && rm -f "regex_revalidate.la" && ln -s 
"../regex_revalidate.la" "regex_revalidate.la" )
gmake[3]: Leaving directory 
'
Making all in remap_stats
gmake[3]: Entering directory 
'
gmake[3]: Nothing to be done for 'all'.
gmake[3]: Leaving directory 
'
Making all in s3_auth
gmake[3]: Entering directory 
'
depbase=`echo s3_auth.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile clang++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/s3_auth -I../../../lib  
-I../../../proxy/api -I../../../../proxy/api -I../../../../lib 
-I/usr/local/include -Dfreebsd -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 
-D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 
-DOPENSSL_NO_SSL_INTERN -I/usr/local/include/tcl8.6  -Qunused-arguments 
-std=c++11 -std=c++11 -g -pipe -Wall -Wno-deprecated-declarations -O3 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT s3_auth.lo -MD 
-MP -MF $depbase.Tpo -c -o s3_auth.lo 
../../../../plugins/experimental/s3_auth/s3_auth.cc &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  clang++ -DHAVE_CONFIG_H -I. 
-I../../../../plugins/experimental/s3_auth -I../../../lib -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib -I/usr/local/include -Dfreebsd 
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT 
-D__STDC_LIMIT_MACROS=1 -D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN 
-I/usr/local/include/tcl8.6 -Qunused-arguments -std=c++11 -std=c++11 -g -pipe 
-Wall -Wno-deprecated-declarations -O3 -fno-strict-aliasing -Werror 
-Wno-invalid-offsetof -mcx16 -MT s3_auth.lo -MD -MP -MF .deps/s3_auth.Tpo -c 
../../../../plugins/experimental/s3_auth/s3_auth.cc  -fPIC -DPIC -o 
.libs/s3_auth.o
/bin/sh ../../../libtool  --tag=CXX   --mode=link clang++  -Qunused-arguments 
-std=c++11 -std=c++11 -g -pipe -Wall -Wno-deprecated-declarations -O3 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -module 

[jira] [Created] (TS-4237) Enhance Open Write Fail Action feature to support an option to honor SWR RFC header.

[Sudheer Vinukonda (JIRA)]

Sudheer Vinukonda created TS-4237:
-

 Summary: Enhance Open Write Fail Action feature to support an 
option to honor SWR RFC header.
 Key: TS-4237
 URL: https://issues.apache.org/jira/browse/TS-4237
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP
Reporter: Sudheer Vinukonda


This is a follow up enhancement for TS-3549 (and related jiras). Open Write 
Fail Action feature developed with TS-3549 currently supports the following 
options:

https://docs.trafficserver.apache.org/en/6.0.x/reference/configuration/records.config.en.html#proxy-config-http-cache-open-write-fail-action

{code}
0 = default, disable cache and goto origin server
1 = return a 502 error on a cache miss
2 = serve stale if object’s age is under proxy.config.http.cache.max_stale_age, 
else, goto origin server
{code}

This jira is opened to enhance the feature to support a new option to serve 
stale honoring the SWR RFC headers.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3938) Add hardening (fortify) as an option to configure

[Bryan Call (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call resolved TS-3938.

Resolution: Fixed

> Add hardening (fortify) as an option to configure
> -
>
> Key: TS-3938
> URL: https://issues.apache.org/jira/browse/TS-3938
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: sometime
>
>
> It might be useful to add an option, e.g. --with-hardening, such that we can 
> build with various hardening compiler options. For example. I've used
> {code}
> CC="/opt/gcc5/bin/gcc"; export CC
> CXX="/opt/gcc5/bin/g++"; export CXX
> CFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CFLAGS
> CXXFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CXXFLAGS
> CPPFLAGS="-D_FORTIFY_SOURCE=2"; export CPPFLAGS
> LDFLAGS="-Wl,-z,relro -Wl,-z,now"; export LDFLAGS
> "./configure" \
> "--enable-experimental-plugins" \
> "--prefix=/opt/ats" \
> "CC=/opt/gcc5/bin/gcc" \
> "CXX=/opt/gcc5/bin/g++" \
> "CFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CXXFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CPPFLAGS=-D_FORTIFY_SOURCE=2" \
> "LDFLAGS=-Wl,-z,relro -Wl,-z,now" \
> "$@"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3938) Add hardening (fortify) as an option to configure

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169789#comment-15169789
 ] 

ASF subversion and git services commented on TS-3938:
-

Commit 099ac19f5fecc12999a7648790cb611704989e85 in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=099ac19 ]

TS-3938: Add hardening (fortify) as an option to configure

This closes #497.


> Add hardening (fortify) as an option to configure
> -
>
> Key: TS-3938
> URL: https://issues.apache.org/jira/browse/TS-3938
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: sometime
>
>
> It might be useful to add an option, e.g. --with-hardening, such that we can 
> build with various hardening compiler options. For example. I've used
> {code}
> CC="/opt/gcc5/bin/gcc"; export CC
> CXX="/opt/gcc5/bin/g++"; export CXX
> CFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CFLAGS
> CXXFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CXXFLAGS
> CPPFLAGS="-D_FORTIFY_SOURCE=2"; export CPPFLAGS
> LDFLAGS="-Wl,-z,relro -Wl,-z,now"; export LDFLAGS
> "./configure" \
> "--enable-experimental-plugins" \
> "--prefix=/opt/ats" \
> "CC=/opt/gcc5/bin/gcc" \
> "CXX=/opt/gcc5/bin/g++" \
> "CFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CXXFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CPPFLAGS=-D_FORTIFY_SOURCE=2" \
> "LDFLAGS=-Wl,-z,relro -Wl,-z,now" \
> "$@"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3938) Add hardening (fortify) as an option to configure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169791#comment-15169791
 ] 

ASF GitHub Bot commented on TS-3938:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/497


> Add hardening (fortify) as an option to configure
> -
>
> Key: TS-3938
> URL: https://issues.apache.org/jira/browse/TS-3938
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: sometime
>
>
> It might be useful to add an option, e.g. --with-hardening, such that we can 
> build with various hardening compiler options. For example. I've used
> {code}
> CC="/opt/gcc5/bin/gcc"; export CC
> CXX="/opt/gcc5/bin/g++"; export CXX
> CFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CFLAGS
> CXXFLAGS="-fstack-protector -fno-omit-frame-pointer"; export CXXFLAGS
> CPPFLAGS="-D_FORTIFY_SOURCE=2"; export CPPFLAGS
> LDFLAGS="-Wl,-z,relro -Wl,-z,now"; export LDFLAGS
> "./configure" \
> "--enable-experimental-plugins" \
> "--prefix=/opt/ats" \
> "CC=/opt/gcc5/bin/gcc" \
> "CXX=/opt/gcc5/bin/g++" \
> "CFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CXXFLAGS=-fstack-protector -fno-omit-frame-pointer" \
> "CPPFLAGS=-D_FORTIFY_SOURCE=2" \
> "LDFLAGS=-Wl,-z,relro -Wl,-z,now" \
> "$@"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4236) Allow alternate eviction to be smarter by examining RAM cache LRU

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4236:
-

 Summary: Allow alternate eviction to be smarter by examining RAM 
cache LRU
 Key: TS-4236
 URL: https://issues.apache.org/jira/browse/TS-4236
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cache
Reporter: Leif Hedstrom


Right now, when you fill up all alternate (variant) slots for a URL, we 
seemingly evict a "random" object out of the cache. This could for example be 
the most commonly retrieved object. This behavior can easily lead to excessive 
cache churning.

We've tossed around ideas of using the RAM cache LRU information to help with 
cache evacuation. Maybe as an extension (maybe easier?) to that we could 
leverage information from the RAM cache LRU to decide which of the existing 
alternates, if any, is best to throw away. For example, if 2 out of 3 existing 
alternates are also in the RAM cache, it would make sense to replace the 3rd 
one that is only on the disk cache.

This gives us a poor mans LRU implementation for the cache alternates as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4235) Deprecate fuzzy cache revalidation ?

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-4235:
-

Assignee: Leif Hedstrom

> Deprecate fuzzy cache revalidation ?
> 
>
> Key: TS-4235
> URL: https://issues.apache.org/jira/browse/TS-4235
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> I'm starting this as a discussion here. I think there are good reasons to 
> deprecate (for now) and later remove the fuzz logic. These configs are 
> currently in place:
> {code}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT, 
> "0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> The reason for eliminating these are:
> 1) They are difficult to setup correctly, particularly if you have a mix of 
> various cache TTL on objects.
> 2) Currently, they have next to no value, since you lock out all other 
> readers from the object anyways. So you are likely to benefit / use this only 
> for objects which are infrequently accessed.
> 3) With the new proxy.config.http.cache.open_write_fail_action it's possible 
> that #2 improves, but in that case, I'd argue that if you allow it to serve 
> stale, you are better off letting it expire and not "prematurely" revalidate 
> the object.
> 4) It seems to cause confusing behavior as it is today (with default 
> settings), e.g. anything with less than 240s TTL is likely to trip up and 
> prematurely expire long before intended (this is why we added the 
> proxy.config.http.cache.fuzz.min_time option, but it's disabled by default, 
> and makes configuration even more complicated).
> So what does everyone think? Is anyone actually using and relying on the fuzz 
> logic? It feels better to spend some time on adding more features to the 
> fail_action feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4235) Deprecate fuzzy cache revalidation ?

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4235:
--
Fix Version/s: 6.2.0

> Deprecate fuzzy cache revalidation ?
> 
>
> Key: TS-4235
> URL: https://issues.apache.org/jira/browse/TS-4235
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, HTTP
>Reporter: Leif Hedstrom
> Fix For: 6.2.0
>
>
> I'm starting this as a discussion here. I think there are good reasons to 
> deprecate (for now) and later remove the fuzz logic. These configs are 
> currently in place:
> {code}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT, 
> "0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> The reason for eliminating these are:
> 1) They are difficult to setup correctly, particularly if you have a mix of 
> various cache TTL on objects.
> 2) Currently, they have next to no value, since you lock out all other 
> readers from the object anyways. So you are likely to benefit / use this only 
> for objects which are infrequently accessed.
> 3) With the new proxy.config.http.cache.open_write_fail_action it's possible 
> that #2 improves, but in that case, I'd argue that if you allow it to serve 
> stale, you are better off letting it expire and not "prematurely" revalidate 
> the object.
> 4) It seems to cause confusing behavior as it is today (with default 
> settings), e.g. anything with less than 240s TTL is likely to trip up and 
> prematurely expire long before intended (this is why we added the 
> proxy.config.http.cache.fuzz.min_time option, but it's disabled by default, 
> and makes configuration even more complicated).
> So what does everyone think? Is anyone actually using and relying on the fuzz 
> logic? It feels better to spend some time on adding more features to the 
> fail_action feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4235) Deprecate fuzzy cache revalidation ?

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4235:
-

 Summary: Deprecate fuzzy cache revalidation ?
 Key: TS-4235
 URL: https://issues.apache.org/jira/browse/TS-4235
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, HTTP
Reporter: Leif Hedstrom


I'm starting this as a discussion here. I think there are good reasons to 
deprecate (for now) and later remove the fuzz logic. These configs are 
currently in place:

{code}
  {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240", 
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
  {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0", 
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
  {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT, 
"0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
{code}

The reason for eliminating these are:

1) They are difficult to setup correctly, particularly if you have a mix of 
various cache TTL on objects.

2) Currently, they have next to no value, since you lock out all other readers 
from the object anyways. So you are likely to benefit / use this only for 
objects which are infrequently accessed.

3) With the new proxy.config.http.cache.open_write_fail_action it's possible 
that #2 improves, but in that case, I'd argue that if you allow it to serve 
stale, you are better off letting it expire and not "prematurely" revalidate 
the object.

4) It seems to cause confusing behavior as it is today (with default settings), 
e.g. anything with less than 240s TTL is likely to trip up and prematurely 
expire long before intended (this is why we added the 
proxy.config.http.cache.fuzz.min_time option, but it's disabled by default, and 
makes configuration even more complicated).


So what does everyone think? Is anyone actually using and relying on the fuzz 
logic? It feels better to spend some time on adding more features to the 
fail_action feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (TS-4232) Crash in HostDB，During debug message generating

[song (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

song updated TS-4232:
-
Comment: was deleted

(was: Yes，my mistake!!)

> Crash in HostDB，During debug message generating
> ---
>
> Key: TS-4232
> URL: https://issues.apache.org/jira/browse/TS-4232
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Oknet Xu
>  Labels: crash
> Fix For: 6.2.0
>
>
> STACK TRACE：
> {code}
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x7fec78d2cf52]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fec76cfb8d0]
> /usr/bin/traffic_server(+0x2acc5f)[0x7fec78edec5f]
> /usr/bin/traffic_server(HostDBContinuation::dnsEvent(int, 
> HostEnt*)+0x370)[0x7fec78ee3130]
> /usr/bin/traffic_server(DNSEntry::postEvent(int, Event*)+0x4b)[0x7fec78ec8feb]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x7fec78fa4ee0]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x7fec78fa5aef]
> /usr/bin/traffic_server(+0x3722da)[0x7fec78fa42da]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fec76cf40a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec75ca204d]
> Segmentation fault (core dumped)
> {code}
> gdb with core file
> {code}
> Core was generated by `/usr/bin/traffic_server'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> 612 Debug("hostdb", "RR of %d with %d good, 1st IP = %s", 
> r->rr()->rrcount, r->rr()->good, ats_ip_ntop(r->ip(), ipb, sizeof ipb))
> (gdb) bt
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> #1  reply_to_cont (cont=0x7fec6d375a10, r=0x7fec718beec0, is_srv=false) at 
> HostDB.cc:585
> #2  0x7fec78ee3130 in HostDBContinuation::dnsEvent (this=, 
> event=, e=)
> at HostDB.cc:1682
> #3  0x7fec78ec8feb in handleEvent (data=, event=600, 
> this=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #4  DNSEntry::postEvent (this=0x7fec6d236b10) at DNS.cc:1267
> #5  0x7fec78fa4ee0 in handleEvent (data=0x7fec64164fe0, event=1, 
> this=) at I_Continuation.h:146
> #6  EThread::process_event (this=this@entry=0x7fec73e3f010, 
> e=e@entry=0x7fec64164fe0, calling_code=1) at UnixEThread.cc:131
> #7  0x7fec78fa5aef in EThread::execute (this=0x7fec73e3f010) at 
> UnixEThread.cc:182
> #8  0x7fec78fa42da in spawn_thread_internal (a=0x7fec7b6d1af0) at 
> Thread.cc:86
> #9  0x7fec76cf40a4 in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #10 0x7fec75ca204d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) p r
> $1 = (HostDBInfo *) 0x7fec718beec0
> (gdb) p *r
> Cannot access memory at address 0x7fec718beec0
> (gdb) p ipb
> $2 = 
> "175.25.168.40\000\000\000p+\377x\354\177\000\000\366\377\377\377\000\000\000\000
>  \367\025d\354\177\000\000\240\234\243s\354\177"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4232) Crash in HostDB，During debug message generating

[song (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169771#comment-15169771
 ] 

song commented on TS-4232:
--

Yes，my mistake!!

> Crash in HostDB，During debug message generating
> ---
>
> Key: TS-4232
> URL: https://issues.apache.org/jira/browse/TS-4232
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Oknet Xu
>  Labels: crash
> Fix For: 6.2.0
>
>
> STACK TRACE：
> {code}
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x7fec78d2cf52]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fec76cfb8d0]
> /usr/bin/traffic_server(+0x2acc5f)[0x7fec78edec5f]
> /usr/bin/traffic_server(HostDBContinuation::dnsEvent(int, 
> HostEnt*)+0x370)[0x7fec78ee3130]
> /usr/bin/traffic_server(DNSEntry::postEvent(int, Event*)+0x4b)[0x7fec78ec8feb]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x7fec78fa4ee0]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x7fec78fa5aef]
> /usr/bin/traffic_server(+0x3722da)[0x7fec78fa42da]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fec76cf40a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec75ca204d]
> Segmentation fault (core dumped)
> {code}
> gdb with core file
> {code}
> Core was generated by `/usr/bin/traffic_server'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> 612 Debug("hostdb", "RR of %d with %d good, 1st IP = %s", 
> r->rr()->rrcount, r->rr()->good, ats_ip_ntop(r->ip(), ipb, sizeof ipb))
> (gdb) bt
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> #1  reply_to_cont (cont=0x7fec6d375a10, r=0x7fec718beec0, is_srv=false) at 
> HostDB.cc:585
> #2  0x7fec78ee3130 in HostDBContinuation::dnsEvent (this=, 
> event=, e=)
> at HostDB.cc:1682
> #3  0x7fec78ec8feb in handleEvent (data=, event=600, 
> this=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #4  DNSEntry::postEvent (this=0x7fec6d236b10) at DNS.cc:1267
> #5  0x7fec78fa4ee0 in handleEvent (data=0x7fec64164fe0, event=1, 
> this=) at I_Continuation.h:146
> #6  EThread::process_event (this=this@entry=0x7fec73e3f010, 
> e=e@entry=0x7fec64164fe0, calling_code=1) at UnixEThread.cc:131
> #7  0x7fec78fa5aef in EThread::execute (this=0x7fec73e3f010) at 
> UnixEThread.cc:182
> #8  0x7fec78fa42da in spawn_thread_internal (a=0x7fec7b6d1af0) at 
> Thread.cc:86
> #9  0x7fec76cf40a4 in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #10 0x7fec75ca204d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) p r
> $1 = (HostDBInfo *) 0x7fec718beec0
> (gdb) p *r
> Cannot access memory at address 0x7fec718beec0
> (gdb) p ipb
> $2 = 
> "175.25.168.40\000\000\000p+\377x\354\177\000\000\366\377\377\377\000\000\000\000
>  \367\025d\354\177\000\000\240\234\243s\354\177"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4234) ATS on AARCH64 use spinlock for SSL locking

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4234:
--
Fix Version/s: sometime

> ATS on AARCH64 use spinlock for SSL locking
> ---
>
> Key: TS-4234
> URL: https://issues.apache.org/jira/browse/TS-4234
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Shay Gal-On
> Fix For: sometime
>
>
> Currently on aarch64 mutex locking can be slower then necessary under load. 
> The patch below adds an option to substitute the mutex in ssl locking 
> callback with a spinlock using gcc intrinsics.
> diff -Nau -x Makefile -x .Tpo -x .deps 
> orig-trafficserver-5.3.2/iocore/net/SSLUtils.cc 
> trafficserver-5.3.2/iocore/net/SSLUtils.cc
> --- orig-trafficserver-5.3.2/iocore/net/SSLUtils.cc 2015-09-08 
> 13:05:06.0 -0700
> +++ trafficserver-5.3.2/iocore/net/SSLUtils.cc  2016-02-26 11:44:55.709451000 
> -0800
> @@ -119,9 +119,17 @@
>  #endif
> -static pthread_mutex_t *mutex_buf = NULL;
>  static bool open_ssl_initialized = false;
> +#ifdef SSL_USE_SPINLOCK
> +#include "Spinlock.h"
> +#define SSL_locking_callback SSL_locking_callback_spinlock
> +static Spinlock *spinlock_buf = NULL;
> +#else
> +#define SSL_locking_callback SSL_locking_callback_mutex
> +static pthread_mutex_t *mutex_buf = NULL;
> +#endif
> +
>  RecRawStatBlock *ssl_rsb = NULL;
>  static InkHashTable *ssl_cipher_name_table = NULL;
> @@ -135,9 +143,24 @@
>  {
>return (unsigned long)pthread_self();
>  }
> +#ifdef SSL_USE_SPINLOCK
> +static void
> +SSL_locking_callback_spinlock(int mode, int type, const char * /* file 
> ATS_UNUSED */, int /* line ATS_UNUSED */)
> +{
> +  ink_assert(type < CRYPTO_num_locks());
> +  if (mode & CRYPTO_LOCK) {
> +   spinlock_buf[type].lock();
> +  } else if (mode & CRYPTO_UNLOCK) {
> +   spinlock_buf[type].unlock();
> +  } else {
> +Debug("ssl", "invalid SSL locking mode 0x%x", mode);
> +ink_assert(0);
> +  }
> +}
> +#else
>  static void
> -SSL_locking_callback(int mode, int type, const char * /* file ATS_UNUSED */, 
> int /* line ATS_UNUSED */)
> +SSL_locking_callback_mutex(int mode, int type, const char * /* file 
> ATS_UNUSED */, int /* line ATS_UNUSED */)
>  {
>ink_assert(type < CRYPTO_num_locks());
> @@ -150,6 +173,7 @@
>  ink_assert(0);
>}
>  }
> +#endif
>  static bool
>  SSL_CTX_add_extra_chain_cert_file(SSL_CTX *ctx, const char *chainfile)
> @@ -758,11 +782,14 @@
>  SSL_load_error_strings();
>  SSL_library_init();
> +#ifdef SSL_USE_SPINLOCK
> +spinlock_buf = new Spinlock[CRYPTO_num_locks()];
> +#else
>  mutex_buf = (pthread_mutex_t *)OPENSSL_malloc(CRYPTO_num_locks() * 
> sizeof(pthread_mutex_t));
> -
>  for (int i = 0; i < CRYPTO_num_locks(); i++) {
>pthread_mutex_init(_buf[i], NULL);
>  }
> +#endif
>  CRYPTO_set_locking_callback(SSL_locking_callback);
>  CRYPTO_set_id_callback(SSL_pthreads_thread_id);
> diff -Nau -x Makefile -x .Tpo -x .deps 
> orig-trafficserver-5.3.2/iocore/net/Spinlock.h 
> trafficserver-5.3.2/iocore/net/Spinlock.h
> --- orig-trafficserver-5.3.2/iocore/net/Spinlock.h  1969-12-31 
> 16:00:00.0 -0800
> +++ trafficserver-5.3.2/iocore/net/Spinlock.h   2016-02-26 11:34:06.359451000 
> -0800
> @@ -0,0 +1,38 @@
> +/** @file
> +
> +Author: Shay Gal-On
> +
> +A class implementing a simple spinlock using GCC atomics,
> +using sched_yield while lock fails.
> +
> +*/
> +
> +#include 
> +
> +class Spinlock
> +{
> +public:
> +int _data;
> +
> +public:
> +bool try_lock()
> +{
> +int r = __sync_lock_test_and_set( &_data, 1 );
> +return r == 0;
> +}
> +
> +void lock()
> +{
> +for( unsigned k = 0; !try_lock(); ++k )
> +{
> + sched_yield();
> +}
> +}
> +
> +void unlock()
> +{
> +__sync_lock_release( &_data );
> +}
> +};
> +
> +



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4226) have to use origin url rather than user url to make regex_revalidate work

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4226:
--
Assignee: Phil Sorber

> have to use origin url rather than user url  to make regex_revalidate work
> --
>
> Key: TS-4226
> URL: https://issues.apache.org/jira/browse/TS-4226
> Project: Traffic Server
>  Issue Type: New Feature
>Affects Versions: 5.3.2
>Reporter: zhxiaom5
>Assignee: Phil Sorber
> Fix For: sometime
>
>
> I am using  regex_revalidate,and the plugin works fine.
> but the plugin works like this ,if your remap.config is like this
> {code}
> map test.com test-origin.com
> {code}
> ,and you have to use  origin url rather than user url to make the plugin 
> works.
>  I wander is there any way or any ts api could make user url works too?
> thinks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4226) have to use origin url rather than user url to make regex_revalidate work

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169760#comment-15169760
 ] 

Leif Hedstrom commented on TS-4226:
---

[~psudaemon] Any thoughts?

> have to use origin url rather than user url  to make regex_revalidate work
> --
>
> Key: TS-4226
> URL: https://issues.apache.org/jira/browse/TS-4226
> Project: Traffic Server
>  Issue Type: New Feature
>Affects Versions: 5.3.2
>Reporter: zhxiaom5
> Fix For: sometime
>
>
> I am using  regex_revalidate,and the plugin works fine.
> but the plugin works like this ,if your remap.config is like this
> {code}
> map test.com test-origin.com
> {code}
> ,and you have to use  origin url rather than user url to make the plugin 
> works.
>  I wander is there any way or any ts api could make user url works too?
> thinks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4232) Crash in HostDB，During debug message generating

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4232:
--
Labels: crash  (was: )

> Crash in HostDB，During debug message generating
> ---
>
> Key: TS-4232
> URL: https://issues.apache.org/jira/browse/TS-4232
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Oknet Xu
>  Labels: crash
> Fix For: 6.2.0
>
>
> STACK TRACE：
> {code}
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x7fec78d2cf52]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fec76cfb8d0]
> /usr/bin/traffic_server(+0x2acc5f)[0x7fec78edec5f]
> /usr/bin/traffic_server(HostDBContinuation::dnsEvent(int, 
> HostEnt*)+0x370)[0x7fec78ee3130]
> /usr/bin/traffic_server(DNSEntry::postEvent(int, Event*)+0x4b)[0x7fec78ec8feb]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x7fec78fa4ee0]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x7fec78fa5aef]
> /usr/bin/traffic_server(+0x3722da)[0x7fec78fa42da]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fec76cf40a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec75ca204d]
> Segmentation fault (core dumped)
> {code}
> gdb with core file
> {code}
> Core was generated by `/usr/bin/traffic_server'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> 612 Debug("hostdb", "RR of %d with %d good, 1st IP = %s", 
> r->rr()->rrcount, r->rr()->good, ats_ip_ntop(r->ip(), ipb, sizeof ipb))
> (gdb) bt
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> #1  reply_to_cont (cont=0x7fec6d375a10, r=0x7fec718beec0, is_srv=false) at 
> HostDB.cc:585
> #2  0x7fec78ee3130 in HostDBContinuation::dnsEvent (this=, 
> event=, e=)
> at HostDB.cc:1682
> #3  0x7fec78ec8feb in handleEvent (data=, event=600, 
> this=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #4  DNSEntry::postEvent (this=0x7fec6d236b10) at DNS.cc:1267
> #5  0x7fec78fa4ee0 in handleEvent (data=0x7fec64164fe0, event=1, 
> this=) at I_Continuation.h:146
> #6  EThread::process_event (this=this@entry=0x7fec73e3f010, 
> e=e@entry=0x7fec64164fe0, calling_code=1) at UnixEThread.cc:131
> #7  0x7fec78fa5aef in EThread::execute (this=0x7fec73e3f010) at 
> UnixEThread.cc:182
> #8  0x7fec78fa42da in spawn_thread_internal (a=0x7fec7b6d1af0) at 
> Thread.cc:86
> #9  0x7fec76cf40a4 in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #10 0x7fec75ca204d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) p r
> $1 = (HostDBInfo *) 0x7fec718beec0
> (gdb) p *r
> Cannot access memory at address 0x7fec718beec0
> (gdb) p ipb
> $2 = 
> "175.25.168.40\000\000\000p+\377x\354\177\000\000\366\377\377\377\000\000\000\000
>  \367\025d\354\177\000\000\240\234\243s\354\177"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4232) Crash in HostDB，During debug message generating

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4232:
--
Fix Version/s: 6.2.0

> Crash in HostDB，During debug message generating
> ---
>
> Key: TS-4232
> URL: https://issues.apache.org/jira/browse/TS-4232
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Oknet Xu
>  Labels: crash
> Fix For: 6.2.0
>
>
> STACK TRACE：
> {code}
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x7fec78d2cf52]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fec76cfb8d0]
> /usr/bin/traffic_server(+0x2acc5f)[0x7fec78edec5f]
> /usr/bin/traffic_server(HostDBContinuation::dnsEvent(int, 
> HostEnt*)+0x370)[0x7fec78ee3130]
> /usr/bin/traffic_server(DNSEntry::postEvent(int, Event*)+0x4b)[0x7fec78ec8feb]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x7fec78fa4ee0]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x7fec78fa5aef]
> /usr/bin/traffic_server(+0x3722da)[0x7fec78fa42da]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fec76cf40a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec75ca204d]
> Segmentation fault (core dumped)
> {code}
> gdb with core file
> {code}
> Core was generated by `/usr/bin/traffic_server'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> 612 Debug("hostdb", "RR of %d with %d good, 1st IP = %s", 
> r->rr()->rrcount, r->rr()->good, ats_ip_ntop(r->ip(), ipb, sizeof ipb))
> (gdb) bt
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> #1  reply_to_cont (cont=0x7fec6d375a10, r=0x7fec718beec0, is_srv=false) at 
> HostDB.cc:585
> #2  0x7fec78ee3130 in HostDBContinuation::dnsEvent (this=, 
> event=, e=)
> at HostDB.cc:1682
> #3  0x7fec78ec8feb in handleEvent (data=, event=600, 
> this=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #4  DNSEntry::postEvent (this=0x7fec6d236b10) at DNS.cc:1267
> #5  0x7fec78fa4ee0 in handleEvent (data=0x7fec64164fe0, event=1, 
> this=) at I_Continuation.h:146
> #6  EThread::process_event (this=this@entry=0x7fec73e3f010, 
> e=e@entry=0x7fec64164fe0, calling_code=1) at UnixEThread.cc:131
> #7  0x7fec78fa5aef in EThread::execute (this=0x7fec73e3f010) at 
> UnixEThread.cc:182
> #8  0x7fec78fa42da in spawn_thread_internal (a=0x7fec7b6d1af0) at 
> Thread.cc:86
> #9  0x7fec76cf40a4 in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #10 0x7fec75ca204d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) p r
> $1 = (HostDBInfo *) 0x7fec718beec0
> (gdb) p *r
> Cannot access memory at address 0x7fec718beec0
> (gdb) p ipb
> $2 = 
> "175.25.168.40\000\000\000p+\377x\354\177\000\000\366\377\377\377\000\000\000\000
>  \367\025d\354\177\000\000\240\234\243s\354\177"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4226) have to use origin url rather than user url to make regex_revalidate work

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4226:
--
Description: 
I am using  regex_revalidate,and the plugin works fine.
but the plugin works like this ,if your remap.config is like this
{code}
map test.com test-origin.com
{code}

,and you have to use  origin url rather than user url to make the plugin works.
 I wander is there any way or any ts api could make user url works too?
thinks


  was:
I am using  regex_revalidate,and the plugin works fine.
but the plugin works like this ,if your remap.config is like this
map test.com test-origin.com,and you have to use  origin url rather than user 
url to make the plugin works.
 I wander is there any way or any ts api could make user url works too?
thinks



> have to use origin url rather than user url  to make regex_revalidate work
> --
>
> Key: TS-4226
> URL: https://issues.apache.org/jira/browse/TS-4226
> Project: Traffic Server
>  Issue Type: New Feature
>Affects Versions: 5.3.2
>Reporter: zhxiaom5
> Fix For: sometime
>
>
> I am using  regex_revalidate,and the plugin works fine.
> but the plugin works like this ,if your remap.config is like this
> {code}
> map test.com test-origin.com
> {code}
> ,and you have to use  origin url rather than user url to make the plugin 
> works.
>  I wander is there any way or any ts api could make user url works too?
> thinks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4226) have to use origin url rather than user url to make regex_revalidate work

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4226:
--
Fix Version/s: sometime

> have to use origin url rather than user url  to make regex_revalidate work
> --
>
> Key: TS-4226
> URL: https://issues.apache.org/jira/browse/TS-4226
> Project: Traffic Server
>  Issue Type: New Feature
>Affects Versions: 5.3.2
>Reporter: zhxiaom5
> Fix For: sometime
>
>
> I am using  regex_revalidate,and the plugin works fine.
> but the plugin works like this ,if your remap.config is like this
> {code}
> map test.com test-origin.com
> {code}
> ,and you have to use  origin url rather than user url to make the plugin 
> works.
>  I wander is there any way or any ts api could make user url works too?
> thinks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4233) ATS on AARCH64 with 64K page kernel crashes

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4233:
--
Fix Version/s: sometime

> ATS on AARCH64 with 64K page kernel crashes
> ---
>
> Key: TS-4233
> URL: https://issues.apache.org/jira/browse/TS-4233
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Shay Gal-On
> Fix For: sometime
>
>
> Tested on linux aarch64 Cavium ThunderX platform, 4.2 kernel configured with 
> 64K pages. Crashes are caused by 2 issues:
> 1. Freelist pointer versioning sign extends upper 16 bits. Does not work well 
> for 48b va on aarch64.
> Patch:
> --- orig-trafficserver-5.3.2/lib/ts/ink_queue.h 2015-09-08 13:05:06.0 
> -0700
> +++ trafficserver-5.3.2/lib/ts/ink_queue.h  2016-02-18 09:02:36.899451000 
> -0800
> @@ -135,11 +135,16 @@
>  #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) \
>(_x).s.pointer = _p;   \
>(_x).s.version = _v
> -#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__) || 
> defined(__aarch64__)
> +#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__)
>  #define FREELIST_POINTER(_x) \
>((void *)(intptr_t)(_x).data) << 16) >> 16) | 
> (((~intptr_t)(_x).data) << 16 >> 63) - 1)) >> 48) << 48))) // sign extend
>  #define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
>  #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
> intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
> +#elif defined(__aarch64__)
> +#define FREELIST_POINTER(_x) \
> +  ((void *)(intptr_t)(_x).data) & 0xULL  // clear 
> the version
> +#define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
> +#define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
> intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
>  #else
>  #error "unsupported processor"
>  #endif
> 2. The iocore cache sets the STORE_BLOCK_SIZE to 8k. However, in order to 
> mmap files, the size has to be a multiple of kernel page size, so that with 
> 64K pages it is possible to get bad offsets when remapping the cache blocks. 
> Following patch wraps the block size, and adds configure check for 64K pages 
> to override it in that case.
> diff -Naur orig-trafficserver-5.3.2/iocore/cache/I_Store.h 
> trafficserver-5.3.2/iocore/cache/I_Store.h
> --- orig-trafficserver-5.3.2/iocore/cache/I_Store.h 2015-09-08 
> 13:05:06.0 -0700
> +++ trafficserver-5.3.2/iocore/cache/I_Store.h  2016-02-18 08:52:32.459451000 
> -0800
> @@ -33,7 +33,9 @@
>  #include "libts.h"
> +#ifndef STORE_BLOCK_SIZE
>  #define STORE_BLOCK_SIZE 8192
> +#endif
>  #define STORE_BLOCK_SHIFT 13
>  #define DEFAULT_HW_SECTOR_SIZE 512
> --- orig-trafficserver-5.3.2/configure.ac   2015-09-08 13:05:06.0 
> -0700
> +++ trafficserver-5.3.2/configure.ac2016-02-26 11:09:12.099451000 -0800
> @@ -1324,6 +1324,14 @@
>TS_ADDTO(CFLAGS, [-mcx16])
>TS_ADDTO(CXXFLAGS, [-mcx16])
>  ])
> +AC_MSG_CHECKING([TESTING KERNEL PAGE SIZE])
> +kernel_page_size=`getconf PAGE_SIZE`
> +AS_IF([test "x${kernel_page_size}" = "x65536"],
> +[
> +  TS_ADDTO(CXXFLAGS, [-DSTORE_BLOCK_SIZE=65536])
> +]
> +)
> +AC_MSG_RESULT([$kernel_page_size])
>  # Check for POSIX capabilities library.
>  # If we don't find it, disable checking for header.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4220) DNSHandler::mainEvent

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169759#comment-15169759
 ] 

Leif Hedstrom commented on TS-4220:
---

[~amc] So this is "works as expected" ?

> DNSHandler::mainEvent
> -
>
> Key: TS-4220
> URL: https://issues.apache.org/jira/browse/TS-4220
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: song
> Fix For: sometime
>
>
> Dear all
>   failover_now return false when the name server's mark is not expiring, and 
> we need to call rr_failure to mark the name server as down.
> Thx!!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4220) DNSHandler::mainEvent

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4220:
--
Fix Version/s: sometime

> DNSHandler::mainEvent
> -
>
> Key: TS-4220
> URL: https://issues.apache.org/jira/browse/TS-4220
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: song
> Fix For: sometime
>
>
> Dear all
>   failover_now return false when the name server's mark is not expiring, and 
> we need to call rr_failure to mark the name server as down.
> Thx!!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4225) sync_cache_dir_on_shutdown not called ?

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4225:
--
Fix Version/s: 6.2.0

> sync_cache_dir_on_shutdown not called ?
> ---
>
> Key: TS-4225
> URL: https://issues.apache.org/jira/browse/TS-4225
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Fang
> Fix For: 6.2.0
>
>
> enable cache_dir_sync debug tag, and restart traffic server.
> there is no "sync started" log from sync_cache_dir_on_shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4223) new config will not reload success ERROR: [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169757#comment-15169757
 ] 

Leif Hedstrom commented on TS-4223:
---

I'm unable to reproduce this, when I do it, it reloads the config and I see e.g.

{code}
[Feb 26 20:39:02.737] Manager {0x7fc71b1e9700} NOTE: User has changed config 
file remap.config
{code}


Did you make any other changes? Permissions problems? Did you enable the option 
to make records.config immutable? Anything else?

> new config will not reload success  ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)
> -
>
> Key: TS-4223
> URL: https://issues.apache.org/jira/browse/TS-4223
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: bettydramit
>Priority: Critical
> Fix For: sometime
>
>
> update to 6.1.1
> when exec traffic_ctl config reload
> lot of  [Feb 23 14:20:13.554] Manager {0x7f4216adb840} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4) at 
> manager.log 
> traffic.out
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> new config will not reload success



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4225) sync_cache_dir_on_shutdown not called ?

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4225:
--
Assignee: Alan M. Carroll

> sync_cache_dir_on_shutdown not called ?
> ---
>
> Key: TS-4225
> URL: https://issues.apache.org/jira/browse/TS-4225
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Fang
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> enable cache_dir_sync debug tag, and restart traffic server.
> there is no "sync started" log from sync_cache_dir_on_shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4223) new config will not reload success ERROR: [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4223:
--
Fix Version/s: sometime

> new config will not reload success  ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4)
> -
>
> Key: TS-4223
> URL: https://issues.apache.org/jira/browse/TS-4223
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: bettydramit
>Priority: Critical
> Fix For: sometime
>
>
> update to 6.1.1
> when exec traffic_ctl config reload
> lot of  [Feb 23 14:20:13.554] Manager {0x7f4216adb840} ERROR: 
> [LocalManager::pollMgmtProcessServer] select failed or was interrupted (4) at 
> manager.log 
> traffic.out
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> traffic_ctl: configuration reload request failed: [13] Operation not 
> permitted.
> new config will not reload success



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4225) sync_cache_dir_on_shutdown not called ?

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169758#comment-15169758
 ] 

Leif Hedstrom commented on TS-4225:
---

We might need to have [~amc] take a look at this?

> sync_cache_dir_on_shutdown not called ?
> ---
>
> Key: TS-4225
> URL: https://issues.apache.org/jira/browse/TS-4225
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Fang
>Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> enable cache_dir_sync debug tag, and restart traffic server.
> there is no "sync started" log from sync_cache_dir_on_shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4233) ATS on AARCH64 with 64K page kernel crashes

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169728#comment-15169728
 ] 

Leif Hedstrom commented on TS-4233:
---

Can you put this in a github pull request please?


> ATS on AARCH64 with 64K page kernel crashes
> ---
>
> Key: TS-4233
> URL: https://issues.apache.org/jira/browse/TS-4233
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Shay Gal-On
>
> Tested on linux aarch64 Cavium ThunderX platform, 4.2 kernel configured with 
> 64K pages. Crashes are caused by 2 issues:
> 1. Freelist pointer versioning sign extends upper 16 bits. Does not work well 
> for 48b va on aarch64.
> Patch:
> --- orig-trafficserver-5.3.2/lib/ts/ink_queue.h 2015-09-08 13:05:06.0 
> -0700
> +++ trafficserver-5.3.2/lib/ts/ink_queue.h  2016-02-18 09:02:36.899451000 
> -0800
> @@ -135,11 +135,16 @@
>  #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) \
>(_x).s.pointer = _p;   \
>(_x).s.version = _v
> -#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__) || 
> defined(__aarch64__)
> +#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__)
>  #define FREELIST_POINTER(_x) \
>((void *)(intptr_t)(_x).data) << 16) >> 16) | 
> (((~intptr_t)(_x).data) << 16 >> 63) - 1)) >> 48) << 48))) // sign extend
>  #define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
>  #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
> intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
> +#elif defined(__aarch64__)
> +#define FREELIST_POINTER(_x) \
> +  ((void *)(intptr_t)(_x).data) & 0xULL  // clear 
> the version
> +#define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
> +#define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
> intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
>  #else
>  #error "unsupported processor"
>  #endif
> 2. The iocore cache sets the STORE_BLOCK_SIZE to 8k. However, in order to 
> mmap files, the size has to be a multiple of kernel page size, so that with 
> 64K pages it is possible to get bad offsets when remapping the cache blocks. 
> Following patch wraps the block size, and adds configure check for 64K pages 
> to override it in that case.
> diff -Naur orig-trafficserver-5.3.2/iocore/cache/I_Store.h 
> trafficserver-5.3.2/iocore/cache/I_Store.h
> --- orig-trafficserver-5.3.2/iocore/cache/I_Store.h 2015-09-08 
> 13:05:06.0 -0700
> +++ trafficserver-5.3.2/iocore/cache/I_Store.h  2016-02-18 08:52:32.459451000 
> -0800
> @@ -33,7 +33,9 @@
>  #include "libts.h"
> +#ifndef STORE_BLOCK_SIZE
>  #define STORE_BLOCK_SIZE 8192
> +#endif
>  #define STORE_BLOCK_SHIFT 13
>  #define DEFAULT_HW_SECTOR_SIZE 512
> --- orig-trafficserver-5.3.2/configure.ac   2015-09-08 13:05:06.0 
> -0700
> +++ trafficserver-5.3.2/configure.ac2016-02-26 11:09:12.099451000 -0800
> @@ -1324,6 +1324,14 @@
>TS_ADDTO(CFLAGS, [-mcx16])
>TS_ADDTO(CXXFLAGS, [-mcx16])
>  ])
> +AC_MSG_CHECKING([TESTING KERNEL PAGE SIZE])
> +kernel_page_size=`getconf PAGE_SIZE`
> +AS_IF([test "x${kernel_page_size}" = "x65536"],
> +[
> +  TS_ADDTO(CXXFLAGS, [-DSTORE_BLOCK_SIZE=65536])
> +]
> +)
> +AC_MSG_RESULT([$kernel_page_size])
>  # Check for POSIX capabilities library.
>  # If we don't find it, disable checking for header.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4234) ATS on AARCH64 use spinlock for SSL locking

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169720#comment-15169720
 ] 

Leif Hedstrom commented on TS-4234:
---

Can you put this on a github pull request please? Also, the header on any new 
files should include the normal ASF license blurb (just copy from any existing 
C / C++ file).

> ATS on AARCH64 use spinlock for SSL locking
> ---
>
> Key: TS-4234
> URL: https://issues.apache.org/jira/browse/TS-4234
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Shay Gal-On
>
> Currently on aarch64 mutex locking can be slower then necessary under load. 
> The patch below adds an option to substitute the mutex in ssl locking 
> callback with a spinlock using gcc intrinsics.
> diff -Nau -x Makefile -x .Tpo -x .deps 
> orig-trafficserver-5.3.2/iocore/net/SSLUtils.cc 
> trafficserver-5.3.2/iocore/net/SSLUtils.cc
> --- orig-trafficserver-5.3.2/iocore/net/SSLUtils.cc 2015-09-08 
> 13:05:06.0 -0700
> +++ trafficserver-5.3.2/iocore/net/SSLUtils.cc  2016-02-26 11:44:55.709451000 
> -0800
> @@ -119,9 +119,17 @@
>  #endif
> -static pthread_mutex_t *mutex_buf = NULL;
>  static bool open_ssl_initialized = false;
> +#ifdef SSL_USE_SPINLOCK
> +#include "Spinlock.h"
> +#define SSL_locking_callback SSL_locking_callback_spinlock
> +static Spinlock *spinlock_buf = NULL;
> +#else
> +#define SSL_locking_callback SSL_locking_callback_mutex
> +static pthread_mutex_t *mutex_buf = NULL;
> +#endif
> +
>  RecRawStatBlock *ssl_rsb = NULL;
>  static InkHashTable *ssl_cipher_name_table = NULL;
> @@ -135,9 +143,24 @@
>  {
>return (unsigned long)pthread_self();
>  }
> +#ifdef SSL_USE_SPINLOCK
> +static void
> +SSL_locking_callback_spinlock(int mode, int type, const char * /* file 
> ATS_UNUSED */, int /* line ATS_UNUSED */)
> +{
> +  ink_assert(type < CRYPTO_num_locks());
> +  if (mode & CRYPTO_LOCK) {
> +   spinlock_buf[type].lock();
> +  } else if (mode & CRYPTO_UNLOCK) {
> +   spinlock_buf[type].unlock();
> +  } else {
> +Debug("ssl", "invalid SSL locking mode 0x%x", mode);
> +ink_assert(0);
> +  }
> +}
> +#else
>  static void
> -SSL_locking_callback(int mode, int type, const char * /* file ATS_UNUSED */, 
> int /* line ATS_UNUSED */)
> +SSL_locking_callback_mutex(int mode, int type, const char * /* file 
> ATS_UNUSED */, int /* line ATS_UNUSED */)
>  {
>ink_assert(type < CRYPTO_num_locks());
> @@ -150,6 +173,7 @@
>  ink_assert(0);
>}
>  }
> +#endif
>  static bool
>  SSL_CTX_add_extra_chain_cert_file(SSL_CTX *ctx, const char *chainfile)
> @@ -758,11 +782,14 @@
>  SSL_load_error_strings();
>  SSL_library_init();
> +#ifdef SSL_USE_SPINLOCK
> +spinlock_buf = new Spinlock[CRYPTO_num_locks()];
> +#else
>  mutex_buf = (pthread_mutex_t *)OPENSSL_malloc(CRYPTO_num_locks() * 
> sizeof(pthread_mutex_t));
> -
>  for (int i = 0; i < CRYPTO_num_locks(); i++) {
>pthread_mutex_init(_buf[i], NULL);
>  }
> +#endif
>  CRYPTO_set_locking_callback(SSL_locking_callback);
>  CRYPTO_set_id_callback(SSL_pthreads_thread_id);
> diff -Nau -x Makefile -x .Tpo -x .deps 
> orig-trafficserver-5.3.2/iocore/net/Spinlock.h 
> trafficserver-5.3.2/iocore/net/Spinlock.h
> --- orig-trafficserver-5.3.2/iocore/net/Spinlock.h  1969-12-31 
> 16:00:00.0 -0800
> +++ trafficserver-5.3.2/iocore/net/Spinlock.h   2016-02-26 11:34:06.359451000 
> -0800
> @@ -0,0 +1,38 @@
> +/** @file
> +
> +Author: Shay Gal-On
> +
> +A class implementing a simple spinlock using GCC atomics,
> +using sched_yield while lock fails.
> +
> +*/
> +
> +#include 
> +
> +class Spinlock
> +{
> +public:
> +int _data;
> +
> +public:
> +bool try_lock()
> +{
> +int r = __sync_lock_test_and_set( &_data, 1 );
> +return r == 0;
> +}
> +
> +void lock()
> +{
> +for( unsigned k = 0; !try_lock(); ++k )
> +{
> + sched_yield();
> +}
> +}
> +
> +void unlock()
> +{
> +__sync_lock_release( &_data );
> +}
> +};
> +
> +



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4222) Seg faults while processing ssl_multicert.config

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4222:
--
Summary: Seg faults while processing ssl_multicert.config  (was: ATS 6.2.0 
seg faults while processing ssl_multicert.config)

> Seg faults while processing ssl_multicert.config
> 
>
> Key: TS-4222
> URL: https://issues.apache.org/jira/browse/TS-4222
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 6.2.0
>Reporter: Prakhar Rudra
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.2, 6.2.0
>
>
> ATS version 6.2.0 segment fault error while checking config using 
> traffic_server -Cverify_config
> It occurs after  "INFO: Successfully loaded plugin.config"
> only entry in ssl_multicert.config is as below,
> dest_ip=* ssl_cert_name=fullchain1.pem ssl_key_name=privkey1.pem
> gdb --args traffic_server -Cverify_config
> (gdb) run
> yields
> INFO: Successfully loaded plugin.config
> Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) print SSLConfigParams::load_ssl_file_cb
> $1 = (load_ssl_file_func) 0x0
> Thanks jpeach
> Details:
> http://pastebin.com/K0876r2T
> http://pastebin.com/iP5MAYLu
> Thanks
> Pulling the info from the above pastebin's to jira for posterity.
> {code}
> git clone https://github.com/tatsuhiro-t/spdylay.git
> cd spdylay/
> autoreconf -if
> automake
> autoconf
> ./configure --prefix=/usr
> make
> make install
> cd ../trafficserver/
> autoreconf -if
> export PKG_CONFIG_PATH=/usr/lib/pkgconfig
> ./configure --enable-spdy --enable-experimental-plugins 
> --enable-linux-native-aio --with-zlib=/root/c/ats/zlib-1.2.8 
> --with-pcre=/root/c/ats/pcre-8.38 
> --with-openssl=/root/c/ats/openssl-1.0.1f[WITH CLOUDFLARE PATCH]
> **
> gdb --args traffic_server -Cverify_config
> ...standard info..
> (gdb) run
> Starting program: /usr/local/bin/traffic_server -Cverify_config
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> traffic_server: using root directory '/usr/local'
> [New Thread 0x71f55700 (LWP 19595)]
> NOTE: VERIFY
> [New Thread 0x70c16700 (LWP 19596)]
> [New Thread 0x70a14700 (LWP 19597)]
> INFO:Successfully loaded remap.config
> INFO: Successfully loaded records.config
> INFO: Successfully loaded plugin.config
> Thread 1 "traffic_server" received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) bt full
> #0  0x in ?? ()
> No symbol table info available.
> #1  0x00789374 in SSLInitServerContext 
> (params=params@entry=0x117a140, sslMultCertSettings=..., certList=...)
> at SSLUtils.cc:1384
> bio = {_r = 0x1181f50}
> cert = 0x1182100
> ca = 
> certname = 
> cert_tok = {_data = , _delimiter = 44 ',', _mode = 0, 
> _escape = 92 '\\', _start = ,
>   _length = }
> key_tok = {_data = , _delimiter = 44 ',', _mode = 0, 
> _escape = 92 '\\', _start = 0,
>   _length = }
> ca_tok = {_data = , _delimiter = 44 ',', _mode = 0, 
> _escape = 92 '\\', _start = 0,
>   _length = }
> server_verify_client = 
> completeServerCertPath = 
> ctx = 
> digest = {digest = 0x0, engine = 0x77ffe4e0, flags = 
> 140737488346576, md_data = 0x1f7ff7600, pctx = 0x77ffe188,
>   update = 0x7fffddc0}
> ca_list = 0x0
> hash_buf = 
> "\277\037D\000\000\000\000\000~KgY\000\000\000\000\377\377\377\377\000\000\000\000@\241\027\001\000\000\000\000\b\206\271\367\377\177\000\000\000v\377\367\377\177\000\000)\371\203\000\000\000\000\000\000l\231\365\377\177\000"
> hash_len = 0
> __FUNCTION__ = "SSLInitServerContext"
> additional_cache_flags = 
> ud = {_configParams = 0x117a140, _serverDialog = 0x0, _serverCert = 
> 0x117cef0 "fullchain1.pem",
>   _serverKey = 0x117ceb0 "privkey1.pem"}
> #2  0x0078a370 in ssl_store_ssl_context 
> (params=params@entry=0x117a140, lookup=lookup@entry=0x117c550,
> sslMultCertSettings=...) at SSLUtils.cc:1666
> cert_list = {n = 1, i = 0, v = 0x7fffded8, e = {0x1182100, 0x0, 
> 0x0, 0x0}}
> ctx = 
> keyblock = 
> inserted = 
> #3  0x0078b5e5 in SSLParseCertificateConfiguration 
> (params=params@entry=0x117a140, lookup=lookup@entry=0x117c550)
> at SSLUtils.cc:1902
> sslMultiCertSettings = {session_ticket_enabled = 1, addr = 
> {> = {
>   _r = 0x0}, }, cert = 
> {> = {
>   _r = 0x117ce90 "fullchain1.pem"}, },
>   first_cert = 
> 

[jira] [Updated] (TS-4228) traffic_manager can hang in a tight read() loop

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4228:
--
Backport to Version:   (was: 6.1.2)

> traffic_manager can hang in a tight read() loop 
> 
>
> Key: TS-4228
> URL: https://issues.apache.org/jira/browse/TS-4228
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.2, 6.2.0
>
>
> Under certain conditions, traffic_server does not seem to proxy the cop 
> health check properly to the traffic_manager. Due to poor error handling in 
> the manager thread, this can cause it to run indefinitely in a read() loop.
> I think we should strengthen the code in manager, to check FD with a poll() 
> before every read and write, and allow it to fail after a certain timeout 
> (based on Cop's behavior) such that at least we end up killing the request 
> and manager thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4228) traffic_manager can hang in a tight read() loop

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4228:
--
Fix Version/s: 6.1.2

> traffic_manager can hang in a tight read() loop 
> 
>
> Key: TS-4228
> URL: https://issues.apache.org/jira/browse/TS-4228
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.2, 6.2.0
>
>
> Under certain conditions, traffic_server does not seem to proxy the cop 
> health check properly to the traffic_manager. Due to poor error handling in 
> the manager thread, this can cause it to run indefinitely in a read() loop.
> I think we should strengthen the code in manager, to check FD with a poll() 
> before every read and write, and allow it to fail after a certain timeout 
> (based on Cop's behavior) such that at least we end up killing the request 
> and manager thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4228) traffic_manager can hang in a tight read() loop

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169682#comment-15169682
 ] 

ASF subversion and git services commented on TS-4228:
-

Commit 55e815578e8327c3f8c584af5f81914d0d80593d in trafficserver's branch 
refs/heads/6.1.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=55e8155 ]

TS-4228 Adds better error handling in the synthetic checks

In traffic_manager, the thread that handles the request from
traffic_cop (via traffic_server) does not deal well with various
(obscure) error conditions.

(cherry picked from commit 9bf5beb3625038ada8de89850d35dfc561220b77)


> traffic_manager can hang in a tight read() loop 
> 
>
> Key: TS-4228
> URL: https://issues.apache.org/jira/browse/TS-4228
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.1.2, 6.2.0
>
>
> Under certain conditions, traffic_server does not seem to proxy the cop 
> health check properly to the traffic_manager. Due to poor error handling in 
> the manager thread, this can cause it to run indefinitely in a read() loop.
> I think we should strengthen the code in manager, to check FD with a poll() 
> before every read and write, and allow it to fail after a certain timeout 
> (based on Cop's behavior) such that at least we end up killing the request 
> and manager thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4234) ATS on AARCH64 use spinlock for SSL locking

[Shay Gal-On (JIRA)]

Shay Gal-On created TS-4234:
---

 Summary: ATS on AARCH64 use spinlock for SSL locking
 Key: TS-4234
 URL: https://issues.apache.org/jira/browse/TS-4234
 Project: Traffic Server
  Issue Type: Improvement
  Components: SSL
Reporter: Shay Gal-On


Currently on aarch64 mutex locking can be slower then necessary under load. The 
patch below adds an option to substitute the mutex in ssl locking callback with 
a spinlock using gcc intrinsics.

diff -Nau -x Makefile -x .Tpo -x .deps 
orig-trafficserver-5.3.2/iocore/net/SSLUtils.cc 
trafficserver-5.3.2/iocore/net/SSLUtils.cc
--- orig-trafficserver-5.3.2/iocore/net/SSLUtils.cc 2015-09-08 
13:05:06.0 -0700
+++ trafficserver-5.3.2/iocore/net/SSLUtils.cc  2016-02-26 11:44:55.709451000 
-0800
@@ -119,9 +119,17 @@
 #endif


-static pthread_mutex_t *mutex_buf = NULL;
 static bool open_ssl_initialized = false;

+#ifdef SSL_USE_SPINLOCK
+#include "Spinlock.h"
+#define SSL_locking_callback SSL_locking_callback_spinlock
+static Spinlock *spinlock_buf = NULL;
+#else
+#define SSL_locking_callback SSL_locking_callback_mutex
+static pthread_mutex_t *mutex_buf = NULL;
+#endif
+
 RecRawStatBlock *ssl_rsb = NULL;
 static InkHashTable *ssl_cipher_name_table = NULL;

@@ -135,9 +143,24 @@
 {
   return (unsigned long)pthread_self();
 }
+#ifdef SSL_USE_SPINLOCK
+static void
+SSL_locking_callback_spinlock(int mode, int type, const char * /* file 
ATS_UNUSED */, int /* line ATS_UNUSED */)
+{
+  ink_assert(type < CRYPTO_num_locks());

+  if (mode & CRYPTO_LOCK) {
+   spinlock_buf[type].lock();
+  } else if (mode & CRYPTO_UNLOCK) {
+   spinlock_buf[type].unlock();
+  } else {
+Debug("ssl", "invalid SSL locking mode 0x%x", mode);
+ink_assert(0);
+  }
+}
+#else
 static void
-SSL_locking_callback(int mode, int type, const char * /* file ATS_UNUSED */, 
int /* line ATS_UNUSED */)
+SSL_locking_callback_mutex(int mode, int type, const char * /* file ATS_UNUSED 
*/, int /* line ATS_UNUSED */)
 {
   ink_assert(type < CRYPTO_num_locks());

@@ -150,6 +173,7 @@
 ink_assert(0);
   }
 }
+#endif

 static bool
 SSL_CTX_add_extra_chain_cert_file(SSL_CTX *ctx, const char *chainfile)
@@ -758,11 +782,14 @@
 SSL_load_error_strings();
 SSL_library_init();

+#ifdef SSL_USE_SPINLOCK
+spinlock_buf = new Spinlock[CRYPTO_num_locks()];
+#else
 mutex_buf = (pthread_mutex_t *)OPENSSL_malloc(CRYPTO_num_locks() * 
sizeof(pthread_mutex_t));
-
 for (int i = 0; i < CRYPTO_num_locks(); i++) {
   pthread_mutex_init(_buf[i], NULL);
 }
+#endif

 CRYPTO_set_locking_callback(SSL_locking_callback);
 CRYPTO_set_id_callback(SSL_pthreads_thread_id);
diff -Nau -x Makefile -x .Tpo -x .deps 
orig-trafficserver-5.3.2/iocore/net/Spinlock.h 
trafficserver-5.3.2/iocore/net/Spinlock.h
--- orig-trafficserver-5.3.2/iocore/net/Spinlock.h  1969-12-31 
16:00:00.0 -0800
+++ trafficserver-5.3.2/iocore/net/Spinlock.h   2016-02-26 11:34:06.359451000 
-0800
@@ -0,0 +1,38 @@
+/** @file
+
+Author: Shay Gal-On
+
+A class implementing a simple spinlock using GCC atomics,
+using sched_yield while lock fails.
+
+*/
+
+#include 
+
+class Spinlock
+{
+public:
+int _data;
+
+public:
+bool try_lock()
+{
+int r = __sync_lock_test_and_set( &_data, 1 );
+return r == 0;
+}
+
+void lock()
+{
+for( unsigned k = 0; !try_lock(); ++k )
+{
+ sched_yield();
+}
+}
+
+void unlock()
+{
+__sync_lock_release( &_data );
+}
+};
+
+




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4233) ATS on AARCH64 with 64K page kernel crashes

[Shay Gal-On (JIRA)]

Shay Gal-On created TS-4233:
---

 Summary: ATS on AARCH64 with 64K page kernel crashes
 Key: TS-4233
 URL: https://issues.apache.org/jira/browse/TS-4233
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Shay Gal-On


Tested on linux aarch64 Cavium ThunderX platform, 4.2 kernel configured with 
64K pages. Crashes are caused by 2 issues:

1. Freelist pointer versioning sign extends upper 16 bits. Does not work well 
for 48b va on aarch64.
Patch:

--- orig-trafficserver-5.3.2/lib/ts/ink_queue.h 2015-09-08 13:05:06.0 
-0700
+++ trafficserver-5.3.2/lib/ts/ink_queue.h  2016-02-18 09:02:36.899451000 
-0800
@@ -135,11 +135,16 @@
 #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) \
   (_x).s.pointer = _p;   \
   (_x).s.version = _v
-#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__) || 
defined(__aarch64__)
+#elif defined(__x86_64__) || defined(__ia64__) || defined(__powerpc64__)
 #define FREELIST_POINTER(_x) \
   ((void *)(intptr_t)(_x).data) << 16) >> 16) | 
(((~intptr_t)(_x).data) << 16 >> 63) - 1)) >> 48) << 48))) // sign extend
 #define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
 #define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
+#elif defined(__aarch64__)
+#define FREELIST_POINTER(_x) \
+  ((void *)(intptr_t)(_x).data) & 0xULL  // clear the 
version
+#define FREELIST_VERSION(_x) (((intptr_t)(_x).data) >> 48)
+#define SET_FREELIST_POINTER_VERSION(_x, _p, _v) (_x).data = 
intptr_t)(_p)) & 0xULL) | (((_v)&0xULL) << 48))
 #else
 #error "unsupported processor"
 #endif

2. The iocore cache sets the STORE_BLOCK_SIZE to 8k. However, in order to mmap 
files, the size has to be a multiple of kernel page size, so that with 64K 
pages it is possible to get bad offsets when remapping the cache blocks. 
Following patch wraps the block size, and adds configure check for 64K pages to 
override it in that case.
diff -Naur orig-trafficserver-5.3.2/iocore/cache/I_Store.h 
trafficserver-5.3.2/iocore/cache/I_Store.h
--- orig-trafficserver-5.3.2/iocore/cache/I_Store.h 2015-09-08 
13:05:06.0 -0700
+++ trafficserver-5.3.2/iocore/cache/I_Store.h  2016-02-18 08:52:32.459451000 
-0800
@@ -33,7 +33,9 @@

 #include "libts.h"

+#ifndef STORE_BLOCK_SIZE
 #define STORE_BLOCK_SIZE 8192
+#endif
 #define STORE_BLOCK_SHIFT 13
 #define DEFAULT_HW_SECTOR_SIZE 512

--- orig-trafficserver-5.3.2/configure.ac   2015-09-08 13:05:06.0 
-0700
+++ trafficserver-5.3.2/configure.ac2016-02-26 11:09:12.099451000 -0800
@@ -1324,6 +1324,14 @@
   TS_ADDTO(CFLAGS, [-mcx16])
   TS_ADDTO(CXXFLAGS, [-mcx16])
 ])
+AC_MSG_CHECKING([TESTING KERNEL PAGE SIZE])
+kernel_page_size=`getconf PAGE_SIZE`
+AS_IF([test "x${kernel_page_size}" = "x65536"],
+[
+  TS_ADDTO(CXXFLAGS, [-DSTORE_BLOCK_SIZE=65536])
+]
+)
+AC_MSG_RESULT([$kernel_page_size])

 # Check for POSIX capabilities library.
 # If we don't find it, disable checking for header.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: tsqa-master #1219

[jenkins]

See 

Changes:

[Sudheer Vinukonda] Doc updates

[Leif Hedstrom] TS-4228 Adds better error handling in the synthetic checks

--
[...truncated 1922 lines...]
try_run(context, names)
  File 
"
 line 471, in try_run
return func()
  File 
"
 line 150, in setUpClass
super(DynamicHTTPEndpointCase, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 
"
 line 73, in poll_interfaces
reduce(lambda x, y: str(x) + ',' + str(y), hostports)))
Exception: Timeout waiting for interfaces: ('127.0.0.1', 35930)
 >> begin captured logging << 
root: INFO: Environment prefix is /tmp/tsqa.env.SfMy2l
root: INFO: Environment prefix is /tmp/tsqa.env.4NxpHt
test_https: INFO: cp 

 

root: INFO: Environment prefix is /tmp/tsqa.env.GiE7Eq
root: INFO: Environment prefix is /tmp/tsqa.env.r9ecaH
root: INFO: Environment prefix is /tmp/tsqa.env.HtH7cl
root: INFO: Environment prefix is /tmp/tsqa.env.XpE8JX
root: INFO: Environment prefix is /tmp/tsqa.env.03Spij
root: INFO: Environment prefix is /tmp/tsqa.env.hC3qZo
root: INFO: Environment prefix is /tmp/tsqa.env.YPYQfE
root: INFO: Environment prefix is /tmp/tsqa.env.diwKy_
root: INFO: Environment prefix is /tmp/tsqa.env.4zFAa5
root: INFO: Environment prefix is /tmp/tsqa.env.DUr1vR
root: INFO: Environment prefix is /tmp/tsqa.env.c6zX1P
test_origin_min_keep_alive_connection: INFO: socket_server_port = 45037
test_origin_min_keep_alive_connection: INFO: starting the socket server
root: INFO: Environment prefix is /tmp/tsqa.env.8do6ud
root: INFO: Environment prefix is /tmp/tsqa.env.qlatfo
tsqa.environment: INFO: Starting build (d133993325226bee52737bbab4e1cbc1): 
configure {'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'enable-linux-native-aio': None, 'disable-dependency-tracking': None}
root: INFO: Environment prefix is /tmp/tsqa.env.ROoxNB
- >> end captured logging << -

==
ERROR: test suite for 
--
Traceback (most recent call last):
  File 
"
 line 209, in run
self.setUp()
  File 
"
 line 292, in setUp
self.setupContext(ancestor)
  File 
"
 line 315, in setupContext
try_run(context, names)
  File 
"
 line 471, in try_run
return func()
  File 
"
 line 150, in setUpClass
super(DynamicHTTPEndpointCase, cls).setUpClass()
  File 
"
 line 86, in setUpClass
cls.environment.start()
  File 
"
 line 450, in start
self.__exec_cop()
  File 
"
 line 297, in __exec_cop
tsqa.utils.poll_interfaces(self.hostports)
  File 

[jira] [Commented] (TS-4228) traffic_manager can hang in a tight read() loop

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169296#comment-15169296
 ] 

ASF subversion and git services commented on TS-4228:
-

Commit 9bf5beb3625038ada8de89850d35dfc561220b77 in trafficserver's branch 
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9bf5beb ]

TS-4228 Adds better error handling in the synthetic checks

In traffic_manager, the thread that handles the request from
traffic_cop (via traffic_server) does not deal well with various
(obscure) error conditions.


> traffic_manager can hang in a tight read() loop 
> 
>
> Key: TS-4228
> URL: https://issues.apache.org/jira/browse/TS-4228
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.2.0
>
>
> Under certain conditions, traffic_server does not seem to proxy the cop 
> health check properly to the traffic_manager. Due to poor error handling in 
> the manager thread, this can cause it to run indefinitely in a read() loop.
> I think we should strengthen the code in manager, to check FD with a poll() 
> before every read and write, and allow it to fail after a certain timeout 
> (based on Cop's behavior) such that at least we end up killing the request 
> and manager thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4228) traffic_manager can hang in a tight read() loop

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169230#comment-15169230
 ] 

ASF GitHub Bot commented on TS-4228:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/500#issuecomment-189338072
  
Looks good. Merge it.


> traffic_manager can hang in a tight read() loop 
> 
>
> Key: TS-4228
> URL: https://issues.apache.org/jira/browse/TS-4228
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.2.0
>
>
> Under certain conditions, traffic_server does not seem to proxy the cop 
> health check properly to the traffic_manager. Due to poor error handling in 
> the manager thread, this can cause it to run indefinitely in a read() loop.
> I think we should strengthen the code in manager, to check FD with a poll() 
> before every read and write, and allow it to fail after a certain timeout 
> (based on Cop's behavior) such that at least we end up killing the request 
> and manager thread.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4232) Crash in HostDB，During debug message generating

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15169206#comment-15169206
 ] 

Leif Hedstrom commented on TS-4232:
---

We're seeing a crasher in HostDB as well, related to (we think) round-robin 
issues, TS-4207. We've been running with two alternative builds in production, 
both of which seem to avoid that specific crasher:

1) One build draconically reverted almost all changes to HostDB from 5.3.x to 
6.1.

2) In another, we added an additional check to make sure r->rr() is not NULL 
(which clearly should not happen).


#2 does indeed trip (rarely), indicating that we have some issues in the HostDB 
causing some sort of corruption and/or bad lookups, or perhaps locking issues. 
Masa commented on TS-4207 with a very interesting bug (and fix), which might be 
worth testing as well.

> Crash in HostDB，During debug message generating
> ---
>
> Key: TS-4232
> URL: https://issues.apache.org/jira/browse/TS-4232
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Oknet Xu
>
> STACK TRACE：
> {code}
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x7fec78d2cf52]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fec76cfb8d0]
> /usr/bin/traffic_server(+0x2acc5f)[0x7fec78edec5f]
> /usr/bin/traffic_server(HostDBContinuation::dnsEvent(int, 
> HostEnt*)+0x370)[0x7fec78ee3130]
> /usr/bin/traffic_server(DNSEntry::postEvent(int, Event*)+0x4b)[0x7fec78ec8feb]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x7fec78fa4ee0]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x7fec78fa5aef]
> /usr/bin/traffic_server(+0x3722da)[0x7fec78fa42da]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fec76cf40a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec75ca204d]
> Segmentation fault (core dumped)
> {code}
> gdb with core file
> {code}
> Core was generated by `/usr/bin/traffic_server'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> 612 Debug("hostdb", "RR of %d with %d good, 1st IP = %s", 
> r->rr()->rrcount, r->rr()->good, ats_ip_ntop(r->ip(), ipb, sizeof ipb))
> (gdb) bt
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> #1  reply_to_cont (cont=0x7fec6d375a10, r=0x7fec718beec0, is_srv=false) at 
> HostDB.cc:585
> #2  0x7fec78ee3130 in HostDBContinuation::dnsEvent (this=, 
> event=, e=)
> at HostDB.cc:1682
> #3  0x7fec78ec8feb in handleEvent (data=, event=600, 
> this=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #4  DNSEntry::postEvent (this=0x7fec6d236b10) at DNS.cc:1267
> #5  0x7fec78fa4ee0 in handleEvent (data=0x7fec64164fe0, event=1, 
> this=) at I_Continuation.h:146
> #6  EThread::process_event (this=this@entry=0x7fec73e3f010, 
> e=e@entry=0x7fec64164fe0, calling_code=1) at UnixEThread.cc:131
> #7  0x7fec78fa5aef in EThread::execute (this=0x7fec73e3f010) at 
> UnixEThread.cc:182
> #8  0x7fec78fa42da in spawn_thread_internal (a=0x7fec7b6d1af0) at 
> Thread.cc:86
> #9  0x7fec76cf40a4 in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #10 0x7fec75ca204d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) p r
> $1 = (HostDBInfo *) 0x7fec718beec0
> (gdb) p *r
> Cannot access memory at address 0x7fec718beec0
> (gdb) p ipb
> $2 = 
> "175.25.168.40\000\000\000p+\377x\354\177\000\000\366\377\377\377\000\000\000\000
>  \367\025d\354\177\000\000\240\234\243s\354\177"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4220) DNSHandler::mainEvent

[Alan M. Carroll (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168940#comment-15168940
 ] 

Alan M. Carroll commented on TS-4220:
-

I'm not seeing the problem here. {{failover_now}} checks if the DNS server has 
been unresponsive for too long, returning {{true}} if that is the case, meaning 
the nameserver is unavailable for Traffic Server. In that case {{rr_failure}} 
should be called because that is the method that updates the internal state to 
mark that nameserver as down. Further, changing the sense of the check would 
mean doing a retry immediately when the nameserver is marked down, which 
doesn't seem to be the intent the just prior {{for}} loop is run to do such 
retries after some time,{{DNS_PRIMARY_RETRY_PERIOD}}, has gone by.

It seems to me the current logic is therefore correct - call {{rr_failure}} if 
{{failover_now}} returns {{true}}. You can see the same logic in the non-round 
robin case a few lines below. 

> DNSHandler::mainEvent
> -
>
> Key: TS-4220
> URL: https://issues.apache.org/jira/browse/TS-4220
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: song
>
> Dear all
>   failover_now return false when the name server's mark is not expiring, and 
> we need to call rr_failure to mark the name server as down.
> Thx!!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4232) Crash in HostDB，During debug message generating

[song (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15168738#comment-15168738
 ] 

song commented on TS-4232:
--

Please try to print the hostDB.data and hostDB.totalsize. 

> Crash in HostDB，During debug message generating
> ---
>
> Key: TS-4232
> URL: https://issues.apache.org/jira/browse/TS-4232
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Oknet Xu
>
> STACK TRACE：
> {code}
> /usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xa2)[0x7fec78d2cf52]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fec76cfb8d0]
> /usr/bin/traffic_server(+0x2acc5f)[0x7fec78edec5f]
> /usr/bin/traffic_server(HostDBContinuation::dnsEvent(int, 
> HostEnt*)+0x370)[0x7fec78ee3130]
> /usr/bin/traffic_server(DNSEntry::postEvent(int, Event*)+0x4b)[0x7fec78ec8feb]
> /usr/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x90)[0x7fec78fa4ee0]
> /usr/bin/traffic_server(EThread::execute()+0x67f)[0x7fec78fa5aef]
> /usr/bin/traffic_server(+0x3722da)[0x7fec78fa42da]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fec76cf40a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec75ca204d]
> Segmentation fault (core dumped)
> {code}
> gdb with core file
> {code}
> Core was generated by `/usr/bin/traffic_server'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> 612 Debug("hostdb", "RR of %d with %d good, 1st IP = %s", 
> r->rr()->rrcount, r->rr()->good, ats_ip_ntop(r->ip(), ipb, sizeof ipb))
> (gdb) bt
> #0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
> cont=0x7fec6d375a10) at HostDB.cc:612
> #1  reply_to_cont (cont=0x7fec6d375a10, r=0x7fec718beec0, is_srv=false) at 
> HostDB.cc:585
> #2  0x7fec78ee3130 in HostDBContinuation::dnsEvent (this=, 
> event=, e=)
> at HostDB.cc:1682
> #3  0x7fec78ec8feb in handleEvent (data=, event=600, 
> this=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #4  DNSEntry::postEvent (this=0x7fec6d236b10) at DNS.cc:1267
> #5  0x7fec78fa4ee0 in handleEvent (data=0x7fec64164fe0, event=1, 
> this=) at I_Continuation.h:146
> #6  EThread::process_event (this=this@entry=0x7fec73e3f010, 
> e=e@entry=0x7fec64164fe0, calling_code=1) at UnixEThread.cc:131
> #7  0x7fec78fa5aef in EThread::execute (this=0x7fec73e3f010) at 
> UnixEThread.cc:182
> #8  0x7fec78fa42da in spawn_thread_internal (a=0x7fec7b6d1af0) at 
> Thread.cc:86
> #9  0x7fec76cf40a4 in start_thread () from 
> /lib/x86_64-linux-gnu/libpthread.so.0
> #10 0x7fec75ca204d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) p r
> $1 = (HostDBInfo *) 0x7fec718beec0
> (gdb) p *r
> Cannot access memory at address 0x7fec718beec0
> (gdb) p ipb
> $2 = 
> "175.25.168.40\000\000\000p+\377x\354\177\000\000\366\377\377\377\000\000\000\000
>  \367\025d\354\177\000\000\240\234\243s\354\177"
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4232) Crash in HostDB，During debug message generating

[Oknet Xu (JIRA)]

Oknet Xu created TS-4232:


 Summary: Crash in HostDB，During debug message generating
 Key: TS-4232
 URL: https://issues.apache.org/jira/browse/TS-4232
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Oknet Xu


STACK TRACE：
{code}
/usr/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
void*)+0xa2)[0x7fec78d2cf52]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7fec76cfb8d0]
/usr/bin/traffic_server(+0x2acc5f)[0x7fec78edec5f]
/usr/bin/traffic_server(HostDBContinuation::dnsEvent(int, 
HostEnt*)+0x370)[0x7fec78ee3130]
/usr/bin/traffic_server(DNSEntry::postEvent(int, Event*)+0x4b)[0x7fec78ec8feb]
/usr/bin/traffic_server(EThread::process_event(Event*, 
int)+0x90)[0x7fec78fa4ee0]
/usr/bin/traffic_server(EThread::execute()+0x67f)[0x7fec78fa5aef]
/usr/bin/traffic_server(+0x3722da)[0x7fec78fa42da]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7fec76cf40a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec75ca204d]
Segmentation fault (core dumped)
{code}

gdb with core file

{code}
Core was generated by `/usr/bin/traffic_server'.
Program terminated with signal 11, Segmentation fault.
#0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
cont=0x7fec6d375a10) at HostDB.cc:612

612 Debug("hostdb", "RR of %d with %d good, 1st IP = %s", 
r->rr()->rrcount, r->rr()->good, ats_ip_ntop(r->ip(), ipb, sizeof ipb))
(gdb) bt
#0  0x7fec78edec5f in reply_to_cont (is_srv=false, r=0x7fec718beec0, 
cont=0x7fec6d375a10) at HostDB.cc:612
#1  reply_to_cont (cont=0x7fec6d375a10, r=0x7fec718beec0, is_srv=false) at 
HostDB.cc:585
#2  0x7fec78ee3130 in HostDBContinuation::dnsEvent (this=, 
event=, e=)
at HostDB.cc:1682
#3  0x7fec78ec8feb in handleEvent (data=, event=600, 
this=)
at ../../iocore/eventsystem/I_Continuation.h:146
#4  DNSEntry::postEvent (this=0x7fec6d236b10) at DNS.cc:1267
#5  0x7fec78fa4ee0 in handleEvent (data=0x7fec64164fe0, event=1, 
this=) at I_Continuation.h:146
#6  EThread::process_event (this=this@entry=0x7fec73e3f010, 
e=e@entry=0x7fec64164fe0, calling_code=1) at UnixEThread.cc:131
#7  0x7fec78fa5aef in EThread::execute (this=0x7fec73e3f010) at 
UnixEThread.cc:182
#8  0x7fec78fa42da in spawn_thread_internal (a=0x7fec7b6d1af0) at 
Thread.cc:86
#9  0x7fec76cf40a4 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x7fec75ca204d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) p r
$1 = (HostDBInfo *) 0x7fec718beec0
(gdb) p *r
Cannot access memory at address 0x7fec718beec0
(gdb) p ipb
$2 = 
"175.25.168.40\000\000\000p+\377x\354\177\000\000\366\377\377\377\000\000\000\000
 \367\025d\354\177\000\000\240\234\243s\354\177"
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)