[jira] [Created] (TS-1920) autoconf_port is bound on 0.0.0.0
Igor Galić created TS-1920:
--
Summary: autoconf_port is bound on 0.0.0.0
Key: TS-1920
URL: https://issues.apache.org/jira/browse/TS-1920
Project: Traffic Server
Issue Type: Bug
Components: Management
Reporter: Igor Galić
{{admin.autoconf_port}} which defaults to 8083 is, unnecessarily bound on
{{0.0.0.0}}. For security reasons we should bind it to {{127.0.0.1}} by
default (and/or make it configurable).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1891) Add double-free checking for reclaimable freelist
[ https://issues.apache.org/jira/browse/TS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1891: - Attachment: (was: 0001-Add-double-free-checking-for-reclaimable-freelist-V5.patch) Add double-free checking for reclaimable freelist - Key: TS-1891 URL: https://issues.apache.org/jira/browse/TS-1891 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang double-free checking is very useful for us to analyze memory issues. So, I introduce this feature to recalimable freelist. And，we found that this checking nearly don't affect the performance, so make the checking always. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1891) Add double-free checking for reclaimable freelist
[ https://issues.apache.org/jira/browse/TS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1891: - Attachment: 0001-Add-double-free-checking-for-reclaimable-freelist-V6.patch Add more log info when mmap failed. We have verified this patch, I think it's time to merge it now. Add double-free checking for reclaimable freelist - Key: TS-1891 URL: https://issues.apache.org/jira/browse/TS-1891 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang Attachments: 0001-Add-double-free-checking-for-reclaimable-freelist-V6.patch double-free checking is very useful for us to analyze memory issues. So, I introduce this feature to recalimable freelist. And，we found that this checking nearly don't affect the performance, so make the checking always. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1913) Fix MIOBuffer::append_xmalloced()
[ https://issues.apache.org/jira/browse/TS-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665059#comment-13665059 ] Yunkai Zhang commented on TS-1913: -- We have verified this patch, I think it's time to merge it now. Fix MIOBuffer::append_xmalloced() - Key: TS-1913 URL: https://issues.apache.org/jira/browse/TS-1913 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Yunkai Zhang Attachments: 0002-Fix-MIOBuffer-append_xmalloced.patch When ATS receives a malicious request which URL is too long to hold by internal_msg_buffer, the internal_msg_buffer_size might be set to 0. As a result, the appended memory which allocated by ats_malloc() would be mistaken for the memory from ink_freelist, and would be free to ink_freelist finally. As this memory is larger than the one in ink_freelist, and all memory in the origin ink_freelist would not be reclaimed, so it wouldn't cause segment-fault, that is why we didn't notice it in the past. But after we use reclaimabe-freelist, this bug would cause segment-fault when use it to get inner meta-data or free it back to OS by unmmap(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1153: --- Description: http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html Maybe we should make use of that and link to libumem by default. was: http://developers.sun.com/solaris/articles/multiproc/multiproc.html Maybe we should make use of that and link to libumem by default. On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Labels: memory Fix For: 3.3.4 http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html Maybe we should make use of that and link to libumem by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-1153: --- Description: http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html We should make use of this and link to libumem by default on Solaris and Illumos. was: http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html Maybe we should make use of that and link to libumem by default. On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Labels: memory Fix For: 3.3.4 http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html We should make use of this and link to libumem by default on Solaris and Illumos. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665134#comment-13665134
]
Igor Galić commented on TS-1336:
Here's the same probe from our omnios system:
{noformat}
igalic@omnios-x64 % sudo /usr/sbin/dtrace -n 'syscall:::entry /execname ==
traffic_server/ { @num[probefunc] = count(); }'
dtrace: description 'syscall:::entry ' matched 232 probes
^C
fcntl14
close15
open 15
write15
rusagesys35
nanosleep65
memcntl 137
yield 256
portfs 2217
lwp_park 16893178
igalic@omnios-x64 %
{noformat}
High CPU Usage at idle
--
Key: TS-1336
URL: https://issues.apache.org/jira/browse/TS-1336
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.5, 3.0.2
Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
cores with HT)
Reporter: Greg Smolyn
Labels: A
Fix For: 3.3.4
On this unloaded system, a very basic traffic server instance is using 180%
CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
each.
top -H output:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
10689 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 5]
10693 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.51 [ET_NET 9]
10701 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.56 [ET_NET 17]
[jira] [Commented] (TS-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665149#comment-13665149
]
Igor Galić commented on TS-1336:
{preformat}
igalic@omnios-x64 % sudo /usr/sbin/plockstat -e60 -p $(pgrep traffic_server) |
gc++filt
0
Mutex block
Count nsec Lock Caller
---
1445 5878518 0x46f3050libc.so.1`__cond_timedwait+0xc8
{preformat}
High CPU Usage at idle
--
Key: TS-1336
URL: https://issues.apache.org/jira/browse/TS-1336
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.5, 3.0.2
Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
cores with HT)
Reporter: Greg Smolyn
Labels: A
Fix For: 3.3.4
On this unloaded system, a very basic traffic server instance is using 180%
CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
each.
top -H output:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
10689 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 5]
10693 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.51 [ET_NET 9]
10701 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.56 [ET_NET 17]
10702 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.53 [ET_NET 18]
10705 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 21]
1 root 20 0 24328 2256 1344 S0 0.0 0:02.53 init
2 root 20 0 000 S0 0.0 0:00.05
[jira] [Comment Edited] (TS-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665149#comment-13665149
]
Igor Galić edited comment on TS-1336 at 5/23/13 1:08 PM:
-
{noformat}
igalic@omnios-x64 % sudo /usr/sbin/plockstat -e60 -p $(pgrep traffic_server) |
gc++filt
0
Mutex block
Count nsec Lock Caller
---
1445 5878518 0x46f3050libc.so.1`__cond_timedwait+0xc8
{noformat}
was (Author: i.galic):
{preformat}
igalic@omnios-x64 % sudo /usr/sbin/plockstat -e60 -p $(pgrep traffic_server) |
gc++filt
0
Mutex block
Count nsec Lock Caller
---
1445 5878518 0x46f3050libc.so.1`__cond_timedwait+0xc8
{preformat}
High CPU Usage at idle
--
Key: TS-1336
URL: https://issues.apache.org/jira/browse/TS-1336
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.5, 3.0.2
Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
cores with HT)
Reporter: Greg Smolyn
Labels: A
Fix For: 3.3.4
On this unloaded system, a very basic traffic server instance is using 180%
CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
each.
top -H output:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
10689 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 5]
10693 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.51 [ET_NET 9]
10701 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.56 [ET_NET 17]
10702 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.53 [ET_NET 18]
[jira] [Commented] (TS-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665165#comment-13665165
]
Igor Galić commented on TS-1336:
{noformat}
PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID
15562 jenkins 3.5 3.0 0.0 0.0 0.0 48 0.0 45 608 138 .5M 0 traffic_serv/6
15562 jenkins 3.4 3.1 0.0 0.0 0.0 48 0.0 45 607 135 .5M 0 traffic_serv/9
15562 jenkins 3.4 3.1 0.0 0.0 0.0 48 0.0 45 608 134 .5M 0 traffic_serv/7
15562 jenkins 3.4 3.0 0.0 0.0 0.0 48 0.0 45 608 133 .5M 0 traffic_serv/10
15562 jenkins 3.4 3.0 0.0 0.0 0.0 48 0.0 45 607 134 .5M 0 traffic_serv/8
15562 jenkins 3.4 3.0 0.0 0.0 0.0 48 0.0 45 607 133 .5M 0 traffic_serv/12
15562 jenkins 3.4 3.0 0.0 0.0 0.0 48 0.0 45 607 132 .5M 0 traffic_serv/11
15562 jenkins 3.3 3.0 0.0 0.0 0.0 48 0.0 45 608 132 .5M 0 traffic_serv/13
15562 jenkins 0.0 0.1 0.0 0.0 0.0 0.0 97 3.3 441 0 431 0 traffic_serv/1
15562 jenkins 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 2 0 12 0 traffic_serv/5
15562 jenkins 0.0 0.0 0.0 0.0 0.0 98 0.0 2.2 213 0 213 0 traffic_serv/16
15562 jenkins 0.0 0.0 0.0 0.0 0.0 98 0.0 2.2 194 0 194 0 traffic_serv/17
15562 jenkins 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 4 0 4 0 traffic_serv/4
15562 jenkins 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 2 0 2 0 traffic_serv/3
15562 jenkins 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 traffic_serv/18
15562 jenkins 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 traffic_serv/15
15562 jenkins 0.0 0.0 0.0 0.0 0.0 100 0.0 0.0 0 0 0 0 traffic_serv/14
15562 jenkins 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 2 0 2 0 traffic_serv/2
{noformat}
unfortunately, Illumos doesn't have named threads, so we don't kno which
threads are locking which :C
High CPU Usage at idle
--
Key: TS-1336
URL: https://issues.apache.org/jira/browse/TS-1336
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.5, 3.0.2
Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
cores with HT)
Reporter: Greg Smolyn
Labels: A
Fix For: 3.3.4
On this unloaded system, a very basic traffic server instance is using 180%
CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
each.
top -H output:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
[jira] [Commented] (TS-1896) Cleanup duplication of TS_HAS_ and HAVE_ symbols
[ https://issues.apache.org/jira/browse/TS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665368#comment-13665368 ] ASF subversion and git services commented on TS-1896: - Commit fa19b0246b7f5bc43ed9ac2e913a39bc1960793d in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=fa19b02 ] TS-1896 Fix broken eventfd after previous changes, and finish cleanup Cleanup duplication of TS_HAS_ and HAVE_ symbols - Key: TS-1896 URL: https://issues.apache.org/jira/browse/TS-1896 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.3 There's a pretty significant duplication of symbols in ink_config.h.in and ink_autoconf.h.in, and I don't see a reason for this (other than confusion). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1896) Cleanup duplication of TS_HAS_ and HAVE_ symbols
[ https://issues.apache.org/jira/browse/TS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665370#comment-13665370 ] Leif Hedstrom commented on TS-1896: --- Thanks to James Peach for leading the blind (me) around the configure.ac maze. Cleanup duplication of TS_HAS_ and HAVE_ symbols - Key: TS-1896 URL: https://issues.apache.org/jira/browse/TS-1896 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.3 There's a pretty significant duplication of symbols in ink_config.h.in and ink_autoconf.h.in, and I don't see a reason for this (other than confusion). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1735) reclaimable freelist causes core in osx
[ https://issues.apache.org/jira/browse/TS-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665383#comment-13665383 ] ASF subversion and git services commented on TS-1735: - Commit 70a797599605fddffc64985c7b9c4eac8aca2987 in branch refs/heads/master from James Peach jpe...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=70a7975 ] TS-1735: use MAP_ANON to fix build error on Darwin reclaimable freelist causes core in osx --- Key: TS-1735 URL: https://issues.apache.org/jira/browse/TS-1735 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.3.3 Attachments: 0001-TS-1735-fix-initialization-of-_g_mattr.attr-V2.patch, 0001-Use-MAP_ANON-macro-to-fix-build-error-on-Darwin.patch Global variable dependency and ininitialtion order can cause reclaimable freelist to core. Reclaimable freelist depends on a global mutex attribute. (gdb) bt #0 0x7fff8fa17d46 in __kill () #1 0x7fff84824df0 in abort () #2 0x0001009ce697 in reclaimable_freelist_init (fl=value temporarily unavailable, due to optimizations, name=value temporarily unavailable, due to optimizations, type_size=value temporarily unavailable, due to optimizations, chunk_size=value temporarily unavailable, due to optimizations, alignment=value temporarily unavailable, due to optimizations) at ink_mutex.h:80 #3 0x7fff5fc13378 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () #4 0x7fff5fc13762 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () #5 0x7fff5fc1006e in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #6 0x7fff5fc0ffc4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #7 0x7fff5fc0feba in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE () #8 0x7fff5fc01fc0 in __dyld__ZN4dyld24initializeMainExecutableEv () #9 0x7fff5fc05b04 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm () #10 0x7fff5fc01397 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm () #11 0x7fff5fc0105e in __dyld__dyld_start () -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1336) High CPU Usage at idle
[
https://issues.apache.org/jira/browse/TS-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665405#comment-13665405
]
Igor Galić commented on TS-1336:
please note that the load average on the system is slowly rising: Even though
ATS isn't doing anything on this machine, after ~2 hours the load average was
46.~
High CPU Usage at idle
--
Key: TS-1336
URL: https://issues.apache.org/jira/browse/TS-1336
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.5, 3.0.2
Environment: Ubuntu 12.04 server, amd64, Xenon E5520 (4-core, 16
cores with HT)
Reporter: Greg Smolyn
Labels: A
Fix For: 3.3.4
On this unloaded system, a very basic traffic server instance is using 180%
CPU, with 3 threads ET_TASK 0, ET_TASK 1, and LOGGING taking up about 60%
each.
top -H output:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
10723 traffics 20 0 1960m 113m 4168 R 61 0.4 9:11.27 [ET_TASK 1]
10722 traffics 20 0 1960m 113m 4168 R 60 0.4 8:41.61 [ET_TASK 0]
10720 traffics 20 0 1960m 113m 4168 S 59 0.4 8:49.19 [LOGGING]
19 root 20 0 000 R 15 0.0 898:45.74 ksoftirqd/3
10 root 20 0 000 S 15 0.0 930:16.92 ksoftirqd/1
27 root 20 0 000 S 14 0.0 893:18.41 ksoftirqd/5
35 root 20 0 000 S 14 0.0 888:54.41 ksoftirqd/7
3 root 20 0 000 S8 0.0 942:48.39 ksoftirqd/0
15 root 20 0 000 S7 0.0 906:40.98 ksoftirqd/2
23 root 20 0 000 S7 0.0 907:30.33 ksoftirqd/4
31 root 20 0 000 S7 0.0 898:13.05 ksoftirqd/6
13530 root 20 0 98.2m 3244 2572 S1 0.0 29:28.86 flip_server
9425 root 20 0 17568 1592 1060 R0 0.0 0:04.16 top
10689 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 5]
10693 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.51 [ET_NET 9]
10701 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.56 [ET_NET 17]
10702 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.53 [ET_NET 18]
10705 traffics 20 0 1960m 113m 4168 S0 0.4 0:00.54 [ET_NET 21]
1 root 20 0 24328 2256 1344 S0 0.0 0:02.53 init
2 root 20 0 000 S0 0.0 0:00.05 kthreadd
stracing the ET_TASK threads showed a repeating set of calls to futex:
futex(0x946ca4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 255405471,
{1341604150, 0},
[jira] [Updated] (TS-1918) 3.2.x - SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1918: Backport to Version: (was: 3.3.5) 3.2.x - SSL hangs after origin handshake Key: TS-1918 URL: https://issues.apache.org/jira/browse/TS-1918 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1918) 3.2.x - SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1918. - Resolution: Fixed 3.2.x - SSL hangs after origin handshake Key: TS-1918 URL: https://issues.apache.org/jira/browse/TS-1918 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Fix For: 3.2.5 When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1918) 3.2.x - SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1918: Fix Version/s: 3.2.5 3.2.x - SSL hangs after origin handshake Key: TS-1918 URL: https://issues.apache.org/jira/browse/TS-1918 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Fix For: 3.2.5 When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1918) 3.2.x - SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1918: --- Assignee: Igor Galić (was: James Peach) 3.2.x - SSL hangs after origin handshake Key: TS-1918 URL: https://issues.apache.org/jira/browse/TS-1918 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: Igor Galić Fix For: 3.2.5 When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1921) reclaimable freelist stuck in infinite loop
James Peach created TS-1921:
---
Summary: reclaimable freelist stuck in infinite loop
Key: TS-1921
URL: https://issues.apache.org/jira/browse/TS-1921
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
{code}
flathead:build jpeach$ ./libtool --mode=execute lldb -- ./proxy/traffic_server
-R 1 -r SDK_API_TSNetVConn
Current executable set to '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64).
...
(lldb) run
Process 65112 launched: '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64)
...
Process 65112 stopped
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop reason
= signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
147 if (chunk_size 1) {
148/* make alignment to be (2^N * page_size),
149 * but not larger than MAX_CHUNK_BYTE_SIZE */
- 150while (alignment chunk_byte_size)
151 alignment = 1;
152 }
153}
(lldb) p alignment
(uint32_t) $0 = 0
(lldb) p chunk_byte_size
(uint32_t) $1 = 0
...
(lldb) bt
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop reason
= signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
frame #1: 0x000100c0094a
libtsutil.3.dylib`reclaimable_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 282 at
ink_queue_ext.cc:471
frame #2: 0x000100bffec1
libtsutil.3.dylib`ink_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 49 at
ink_queue.cc:89
frame #3: 0x000100175621
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:87
frame #4: 0x000100174e71
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:88
frame #5: 0x000100bf3367 libtsutil.3.dylib`__cxx_global_var_init + 39
at Arena.cc:33
frame #6: 0x000100bf3379 libtsutil.3.dylib`_GLOBAL__I_a + 9 at
Arena.cc:88
frame #7: 0x7fff5fc13378
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const) + 236
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1756) Crash report: kill_tunnel
[
https://issues.apache.org/jira/browse/TS-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665648#comment-13665648
]
Richard Hesse commented on TS-1756:
---
Looks like the crashing has stopped in 3.3.3/master.
Crash report: kill_tunnel
-
Key: TS-1756
URL: https://issues.apache.org/jira/browse/TS-1756
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Core, HTTP
Affects Versions: 3.2.4
Reporter: helaku
Fix For: 3.3.3
centos 5.9 x64 ts3.2.4 debug log
{code}
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] State
Transition: API_CACHE_LOOKUP_COMPLETE - SERVE_FROM_CACHE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466]
perform_cache_write_action CACHE_DO_SERVE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding
producer 'cache read'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding
consumer 'user agent'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) tunnel_run
started, p_arg is NULL
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_cs) tcp_init_cwnd_set 1
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
[SelectFromAlternates] # alternates = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
[SelectFromAlternates] 1 alternates for this cached doc
[alts] There are 1 alternates for this request header.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match
for ACCEPT CHARSET
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match
for ACCEPT ENCODING
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
[calculate_quality_accept_language_match]: response hdr does not have
content-language.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Type and Accept 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Type and Accept-Charset 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Encoding and Accept-Encoding 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021]
[HttpSM::main_handler, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021]
[HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Language and Accept-Language 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Mult's
Quality Factor: 1.002001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
--End of Alternate--
NOTE: Traffic Server received Sig 11: Segmentation fault
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) type =
'image', subtype = 'jpeg'/usr/local/trafficserver-3.2.4/bin/traffic_server -
STACK TRACE:
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) Using
default image vary headers
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: Returning final Q = 1.002
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: Returning final Q = 1.002
[jira] [Commented] (TS-1728) Need a way to assign storage entries to volumes
[ https://issues.apache.org/jira/browse/TS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665739#comment-13665739 ] ASF subversion and git services commented on TS-1728: - Commit e8658bf9040cd4f413891a60caa2df854f21125a in branch refs/heads/issues/TS-1728 from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e8658bf ] TS-1728: Cast float to int64_t Need a way to assign storage entries to volumes --- Key: TS-1728 URL: https://issues.apache.org/jira/browse/TS-1728 Project: Traffic Server Issue Type: Wish Components: Cache Reporter: Jan van Doorn Assignee: Phil Sorber Priority: Minor Fix For: 3.3.3 Attachments: vol.patch See http://www.knutsel.com/vol/compare/ for a write up and some test results on this. We are proposing a simple way to hard link storage.config entries to volume.config and thus hosting.config entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1756) Crash report: kill_tunnel
[
https://issues.apache.org/jira/browse/TS-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1756:
--
Fix Version/s: (was: 3.3.3)
Crash report: kill_tunnel
-
Key: TS-1756
URL: https://issues.apache.org/jira/browse/TS-1756
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Core, HTTP
Affects Versions: 3.2.4
Reporter: helaku
centos 5.9 x64 ts3.2.4 debug log
{code}
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] State
Transition: API_CACHE_LOOKUP_COMPLETE - SERVE_FROM_CACHE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466]
perform_cache_write_action CACHE_DO_SERVE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding
producer 'cache read'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding
consumer 'user agent'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) tunnel_run
started, p_arg is NULL
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_cs) tcp_init_cwnd_set 1
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
[SelectFromAlternates] # alternates = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
[SelectFromAlternates] 1 alternates for this cached doc
[alts] There are 1 alternates for this request header.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match
for ACCEPT CHARSET
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match
for ACCEPT ENCODING
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
[calculate_quality_accept_language_match]: response hdr does not have
content-language.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Type and Accept 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Type and Accept-Charset 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Encoding and Accept-Encoding 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021]
[HttpSM::main_handler, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021]
[HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Language and Accept-Language 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Mult's
Quality Factor: 1.002001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
--End of Alternate--
NOTE: Traffic Server received Sig 11: Segmentation fault
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) type =
'image', subtype = 'jpeg'/usr/local/trafficserver-3.2.4/bin/traffic_server -
STACK TRACE:
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match) Using
default image vary headers
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: CalcVariability says variability = 0
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: Returning final Q = 1.002
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: Returning final Q = 1.002
[alts] alternate #1 (Q = 1.002) has these request/response hdrs:
GET
[jira] [Created] (TS-1922) proxy.config.admin.autoconf.pac_filename is not used as expected
Leif Hedstrom created TS-1922:
-
Summary: proxy.config.admin.autoconf.pac_filename is not used as
expected
Key: TS-1922
URL: https://issues.apache.org/jira/browse/TS-1922
Project: Traffic Server
Issue Type: Bug
Components: Management
Reporter: Leif Hedstrom
It seems that we have a config
{code}
proxy.config.admin.autoconf.pac_filename
{code}
to specify the proxy.pac file name. However, the code is hardocoded to use
proxy.pac.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1920) autoconf_port is bound on 0.0.0.0
[
https://issues.apache.org/jira/browse/TS-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665939#comment-13665939
]
Leif Hedstrom commented on TS-1920:
---
Isn't TS-1920 and TS-1885 the same thing? Also, this port is technically
supposed to be for fetching e.g. /proxy.pac file from, so at at a minimum, the
bind IP has to be configurable. I'd suggest we use the same syntax as for the
other bind ports.
autoconf_port is bound on 0.0.0.0
-
Key: TS-1920
URL: https://issues.apache.org/jira/browse/TS-1920
Project: Traffic Server
Issue Type: Bug
Components: Management
Reporter: Igor Galić
{{admin.autoconf_port}} which defaults to 8083 is, unnecessarily bound on
{{0.0.0.0}}. For security reasons we should bind it to {{127.0.0.1}} by
default (and/or make it configurable).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
