[jira] [Updated] (TS-2182) Setting proxy.config.net.sock_recv_buffer_size_out seriously affects performance
[
https://issues.apache.org/jira/browse/TS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2182:
--
Fix Version/s: (was: 5.1.0)
Setting proxy.config.net.sock_recv_buffer_size_out seriously affects
performance
Key: TS-2182
URL: https://issues.apache.org/jira/browse/TS-2182
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Network
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
I still need to do some more testing, but setting
{code}
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 256K
{code}
on my box reduces throughput to a (fast, local) Origin by about 1000x.
Throughput went from 18MB/sec to 15KB/sec. Removing this setting, restored
normal performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2869) make check causes this error on latest Ubuntu
[ https://issues.apache.org/jira/browse/TS-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016842#comment-14016842 ] Leif Hedstrom commented on TS-2869: --- Which version of ATS is that ? make check causes this error on latest Ubuntu - Key: TS-2869 URL: https://issues.apache.org/jira/browse/TS-2869 Project: Traffic Server Issue Type: Bug Components: Build Reporter: sujata tibrewala make[3]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' CXX test_Buffer-test_Buffer.o make[3]: *** No rule to make target `../../lib/records/librecprocess.a', needed by `test_Buffer'. Stop. make[3]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sujata/trafficserver/iocore' make: *** [check-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2868) set hsts error
[
https://issues.apache.org/jira/browse/TS-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016863#comment-14016863
]
Bryan Call commented on TS-2868:
Yeah, we should get this into 5.0.0
set hsts error
--
Key: TS-2868
URL: https://issues.apache.org/jira/browse/TS-2868
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.0.0
Reporter: bettydramit
Assignee: Bryan Call
Labels: hsts
Fix For: 5.0.0
{code:xml}
traffic_line -s proxy.config.ssl.hsts_max_age -v 3600
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2776) Core dump inside openssl library
[
https://issues.apache.org/jira/browse/TS-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016872#comment-14016872
]
ASF subversion and git services commented on TS-2776:
-
Commit 9c6bb37b39504056683835038aa17fcaedb3c31d in trafficserver's branch
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9c6bb37 ]
TS-2776: Core dump inside openssl library
Changed the version check to runtime and added a debug statement
Core dump inside openssl library
Key: TS-2776
URL: https://issues.apache.org/jira/browse/TS-2776
Project: Traffic Server
Issue Type: Bug
Components: SPDY, SSL
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Priority: Blocker
Labels: spdy, yahoo
Fix For: 5.0.0
During production testing of SPDY (w/ ATS compiled from master repo), noticed
the below core from open ssl library. This core showed up after fixing a few
other core dumps and memory leaks (refer TS-2742, TS-2743, TS-2750, TS-2765,
TS-2767 etc) and happened once so far, after running stable for 30+ hours on
a production host.
{code}
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
[TrafficManager] == Cleaning up and reissuing signal #15
[TrafficManager] == signal #15
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b7dff1f6500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6db57f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x418)[0x6ef488]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x6e3ee3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x7109ff]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x43b)[0x71122b]
/home/y/bin/traffic_server[0x70fdaa]
/lib64/libpthread.so.0(+0x3297207851)[0x2b7dff1ee851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
{code}
gdb output below:
{code}
(gdb) bt
#0 0x00331622b2e7 in ?? () from /usr/lib64/libssl.so.10
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=value optimized
out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
#3 SSLNetVConnection::load_buffer_and_write (this=0x2b7f42c7ca70,
towrite=207693, wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30,
buf=value optimized out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:399
#4 0x006ef488 in write_to_net_io (nh=0x2b7e0f89ac10,
vc=0x2b7f42c7ca70, thread=0x2b7e0f897010) at UnixNetVConnection.cc:527
#5 0x006e3ee3 in NetHandler::mainNetEvent (this=0x2b7e0f89ac10,
event=value optimized out, e=value optimized out) at UnixNet.cc:400
#6 0x007109ff in handleEvent (this=0x2b7e0f897010, e=0x31ae0d0,
calling_code=5) at I_Continuation.h:146
#7 EThread::process_event (this=0x2b7e0f897010, e=0x31ae0d0, calling_code=5)
at UnixEThread.cc:145
#8 0x0071122b in EThread::execute (this=0x2b7e0f897010) at
UnixEThread.cc:269
#9 0x0070fdaa in spawn_thread_internal (a=0x2f8fbe0) at Thread.cc:88
#10 0x2b7dff1ee851 in start_thread () from /lib64/libpthread.so.0
#11 0x003296ee890d in clone () from /lib64/libc.so.6
(gdb) up
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
(gdb) up
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=value optimized
out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
90SSLNetVConnection.cc: No such file or directory.
in SSLNetVConnection.cc
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2776) Core dump inside openssl library
[
https://issues.apache.org/jira/browse/TS-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016874#comment-14016874
]
ASF subversion and git services commented on TS-2776:
-
Commit 9c6bb37b39504056683835038aa17fcaedb3c31d in trafficserver's branch
refs/heads/5.0.x from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9c6bb37 ]
TS-2776: Core dump inside openssl library
Changed the version check to runtime and added a debug statement
Core dump inside openssl library
Key: TS-2776
URL: https://issues.apache.org/jira/browse/TS-2776
Project: Traffic Server
Issue Type: Bug
Components: SPDY, SSL
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Priority: Blocker
Labels: spdy, yahoo
Fix For: 5.0.0
During production testing of SPDY (w/ ATS compiled from master repo), noticed
the below core from open ssl library. This core showed up after fixing a few
other core dumps and memory leaks (refer TS-2742, TS-2743, TS-2750, TS-2765,
TS-2767 etc) and happened once so far, after running stable for 30+ hours on
a production host.
{code}
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
[TrafficManager] == Cleaning up and reissuing signal #15
[TrafficManager] == signal #15
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b7dff1f6500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6db57f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x418)[0x6ef488]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x6e3ee3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x7109ff]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x43b)[0x71122b]
/home/y/bin/traffic_server[0x70fdaa]
/lib64/libpthread.so.0(+0x3297207851)[0x2b7dff1ee851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
{code}
gdb output below:
{code}
(gdb) bt
#0 0x00331622b2e7 in ?? () from /usr/lib64/libssl.so.10
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=value optimized
out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
#3 SSLNetVConnection::load_buffer_and_write (this=0x2b7f42c7ca70,
towrite=207693, wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30,
buf=value optimized out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:399
#4 0x006ef488 in write_to_net_io (nh=0x2b7e0f89ac10,
vc=0x2b7f42c7ca70, thread=0x2b7e0f897010) at UnixNetVConnection.cc:527
#5 0x006e3ee3 in NetHandler::mainNetEvent (this=0x2b7e0f89ac10,
event=value optimized out, e=value optimized out) at UnixNet.cc:400
#6 0x007109ff in handleEvent (this=0x2b7e0f897010, e=0x31ae0d0,
calling_code=5) at I_Continuation.h:146
#7 EThread::process_event (this=0x2b7e0f897010, e=0x31ae0d0, calling_code=5)
at UnixEThread.cc:145
#8 0x0071122b in EThread::execute (this=0x2b7e0f897010) at
UnixEThread.cc:269
#9 0x0070fdaa in spawn_thread_internal (a=0x2f8fbe0) at Thread.cc:88
#10 0x2b7dff1ee851 in start_thread () from /lib64/libpthread.so.0
#11 0x003296ee890d in clone () from /lib64/libc.so.6
(gdb) up
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
(gdb) up
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=value optimized
out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
90SSLNetVConnection.cc: No such file or directory.
in SSLNetVConnection.cc
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2753) Add more SPDY and HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016886#comment-14016886 ] Bryan Call commented on TS-2753: [~sunwei] I don't think it would be a good idea to move the stat to include the timing information for an additional round trip that includes the data sent after the handshake is over. This is not part of the handshake. If you want to approximate the timing of two round trips you can double the existing stat. This would be a better approximation of the full handshake time. Browser can and do make connections and will be idle before sending data. Your numbers showed that the second round trip was 2.75x as long as the first one. Add more SPDY and HTTPS statistics --- Key: TS-2753 URL: https://issues.apache.org/jira/browse/TS-2753 Project: Traffic Server Issue Type: Improvement Components: SPDY Reporter: Wei Sun Assignee: Bryan Call Labels: spdy, yahoo Fix For: 5.0.0 Attachments: TS-2753_1.diff, TS-2802_2.diff Adding stats to spdy helps monitoring and troubleshooting, it would be good to define and add spdy specific stats. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2870) Update SPDY defaults to better match our other defaults
[ https://issues.apache.org/jira/browse/TS-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2870: -- Issue Type: Improvement (was: Bug) Update SPDY defaults to better match our other defaults --- Key: TS-2870 URL: https://issues.apache.org/jira/browse/TS-2870 Project: Traffic Server Issue Type: Improvement Components: Configuration, SPDY Reporter: Leif Hedstrom Fix For: 5.0.0 I think they should match what we do for HTTP/HTTPS (by default). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2870) Update SPDY defaults to better match our other defaults
Leif Hedstrom created TS-2870: - Summary: Update SPDY defaults to better match our other defaults Key: TS-2870 URL: https://issues.apache.org/jira/browse/TS-2870 Project: Traffic Server Issue Type: Bug Components: Configuration, SPDY Reporter: Leif Hedstrom I think they should match what we do for HTTP/HTTPS (by default). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2870) Update SPDY defaults to better match our other defaults
[ https://issues.apache.org/jira/browse/TS-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2870: -- Fix Version/s: 5.0.0 Update SPDY defaults to better match our other defaults --- Key: TS-2870 URL: https://issues.apache.org/jira/browse/TS-2870 Project: Traffic Server Issue Type: Improvement Components: Configuration, SPDY Reporter: Leif Hedstrom Fix For: 5.0.0 I think they should match what we do for HTTP/HTTPS (by default). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2870) Update SPDY defaults to better match our other defaults
[
https://issues.apache.org/jira/browse/TS-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016909#comment-14016909
]
Leif Hedstrom commented on TS-2870:
---
Suggestion:
{code}
diff --git a/mgmt/RecordsConfig.cc b/mgmt/RecordsConfig.cc
index 64b5be4..22d6961 100644
--- a/mgmt/RecordsConfig.cc
+++ b/mgmt/RecordsConfig.cc
@@ -1933,11 +1933,11 @@ RecordElement RecordsConfig[] = {
//
{RECT_CONFIG, proxy.config.spdy.max_concurrent_streams_in, RECD_INT,
100, RECU_DYNAMIC, RR_NULL, RECC_STR, ^[0-9]+$, RECA_NULL}
,
- {RECT_CONFIG, proxy.config.spdy.no_activity_timeout_in, RECD_INT, 30,
RECU_DYNAMIC, RR_NULL, RECC_STR, ^[0-9]+$, RECA_NULL}
+ {RECT_CONFIG, proxy.config.spdy.no_activity_timeout_in, RECD_INT, 115,
RECU_DYNAMIC, RR_NULL, RECC_STR, ^[0-9]+$, RECA_NULL}
,
- {RECT_CONFIG, proxy.config.spdy.initial_window_size_in, RECD_INT, 65536,
RECU_DYNAMIC, RR_NULL, RECC_STR, ^[0-9]+$, RECA_NULL}
+ {RECT_CONFIG, proxy.config.spdy.initial_window_size_in, RECD_INT,
1048576, RECU_DYNAMIC, RR_NULL, RECC_STR, ^[0-9]+$, RECA_NULL}
,
- {RECT_CONFIG, proxy.config.spdy.accept_no_activity_timeout, RECD_INT,
30, RECU_DYNAMIC, RR_NULL, RECC_STR, ^[0-9]+$, RECA_NULL}
+ {RECT_CONFIG, proxy.config.spdy.accept_no_activity_timeout, RECD_INT,
120, RECU_DYNAMIC, RR_NULL, RECC_STR, ^[0-9]+$, RECA_NULL}
,
//# Add LOCAL Records Here
{code}
This matches our other defaults, and the Send Window size of what Google uses.
Update SPDY defaults to better match our other defaults
---
Key: TS-2870
URL: https://issues.apache.org/jira/browse/TS-2870
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, SPDY
Reporter: Leif Hedstrom
Fix For: 5.0.0
I think they should match what we do for HTTP/HTTPS (by default).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2870) Update SPDY defaults to better match our other defaults
[
https://issues.apache.org/jira/browse/TS-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14016913#comment-14016913
]
James Peach commented on TS-2870:
-
What is {{proxy.config.spdy.accept_no_activity_timeout}} supposed to do? Why do
we need different accept timeouts for different protocols? The implementation
of {{proxy.config.spdy.accept_no_activity_timeout}} is to add a timeout after
the accept, which is not what I expected it to to.
Update SPDY defaults to better match our other defaults
---
Key: TS-2870
URL: https://issues.apache.org/jira/browse/TS-2870
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, SPDY
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
I think they should match what we do for HTTP/HTTPS (by default).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2870) Update SPDY defaults to better match our other defaults
[ https://issues.apache.org/jira/browse/TS-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2870: - Assignee: Leif Hedstrom Update SPDY defaults to better match our other defaults --- Key: TS-2870 URL: https://issues.apache.org/jira/browse/TS-2870 Project: Traffic Server Issue Type: Improvement Components: Configuration, SPDY Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 I think they should match what we do for HTTP/HTTPS (by default). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2868) Error setting HSTS max age with traffic_line
[
https://issues.apache.org/jira/browse/TS-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2868:
---
Summary: Error setting HSTS max age with traffic_line (was: set hsts error)
Error setting HSTS max age with traffic_line
Key: TS-2868
URL: https://issues.apache.org/jira/browse/TS-2868
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.0.0
Reporter: bettydramit
Assignee: Bryan Call
Labels: hsts
Fix For: 5.0.0
{code:xml}
traffic_line -s proxy.config.ssl.hsts_max_age -v 3600
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2868) Error setting HSTS max age with traffic_line
[
https://issues.apache.org/jira/browse/TS-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-2868.
Resolution: Fixed
Fix it to use a regular expression instead of an int range. There was a
problem with int range and using the values -1 and 2147483648. I will file
another bug on that.
Error setting HSTS max age with traffic_line
Key: TS-2868
URL: https://issues.apache.org/jira/browse/TS-2868
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.0.0
Reporter: bettydramit
Assignee: Bryan Call
Labels: hsts
Fix For: 5.0.0
{code:xml}
traffic_line -s proxy.config.ssl.hsts_max_age -v 3600
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2871) traffic_line not accepting certain int values
Bryan Call created TS-2871: -- Summary: traffic_line not accepting certain int values Key: TS-2871 URL: https://issues.apache.org/jira/browse/TS-2871 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Bryan Call traffic_line has problem with accepting values like -1 and 2147483648 for configuration option that have those as acceptable integer values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2871) traffic_line not accepting certain int values
[ https://issues.apache.org/jira/browse/TS-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2871: --- Fix Version/s: 5.1.0 traffic_line not accepting certain int values - Key: TS-2871 URL: https://issues.apache.org/jira/browse/TS-2871 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Bryan Call Fix For: 5.1.0 traffic_line has problem with accepting values like -1 and 2147483648 for configuration option that have those as acceptable integer values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2868) Error setting HSTS max age with traffic_line
[
https://issues.apache.org/jira/browse/TS-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2868:
---
Component/s: Configuration
Error setting HSTS max age with traffic_line
Key: TS-2868
URL: https://issues.apache.org/jira/browse/TS-2868
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 5.0.0
Reporter: bettydramit
Assignee: Bryan Call
Labels: hsts
Fix For: 5.0.0
{code:xml}
traffic_line -s proxy.config.ssl.hsts_max_age -v 3600
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2480) Choose the address related SSL_CTX for session ticket callback
[ https://issues.apache.org/jira/browse/TS-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2480: --- Fix Version/s: (was: 5.0.0) 5.1.0 Choose the address related SSL_CTX for session ticket callback -- Key: TS-2480 URL: https://issues.apache.org/jira/browse/TS-2480 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Wei Sun Assignee: Bryan Call Labels: review Fix For: 5.1.0 Attachments: TS-2480.diff When the dest_ip in ssl_multicert.config is not '*', the default SSL_CTX retrieved from the request when presenting session ticket or session id is not associated with any app data (certs, settings, etc), ats delays the association in SNI handling. So in the callback of SSL_CTX_set_tlsext_ticket_key_cb or SSL_CTX_sess_set_get_cb, it won't get the expected SSL_CTX, and session ticket handling will be degraded to the default behavior. I have a requirement of retrieving SSL_CTX during these two callback functions, probably I could workaround it by SSLCertificateConfig::acquire()-findInfoInHash(ip) in every callback and get the expected SSL_CTX. I'm wondering is it feasible to do it once in make_ssl_connection()? Is there any design consideration for being this (delay to overwrite the SSL_CTX in SNI handling)? I have a small patch if it is needed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2776) Core dump inside openssl library
[
https://issues.apache.org/jira/browse/TS-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-2776.
Resolution: Fixed
Traffic server hasn't cored since this fix. We will continue to test and
monitor it.
Core dump inside openssl library
Key: TS-2776
URL: https://issues.apache.org/jira/browse/TS-2776
Project: Traffic Server
Issue Type: Bug
Components: SPDY, SSL
Reporter: Sudheer Vinukonda
Assignee: Bryan Call
Priority: Blocker
Labels: spdy, yahoo
Fix For: 5.0.0
During production testing of SPDY (w/ ATS compiled from master repo), noticed
the below core from open ssl library. This core showed up after fixing a few
other core dumps and memory leaks (refer TS-2742, TS-2743, TS-2750, TS-2765,
TS-2767 etc) and happened once so far, after running stable for 30+ hours on
a production host.
{code}
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
[TrafficManager] == Cleaning up and reissuing signal #15
[TrafficManager] == signal #15
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x329720f500)[0x2b7dff1f6500]
/usr/lib64/libssl.so.10[0x331622b2e7]
/usr/lib64/libssl.so.10(ssl3_write_bytes+0x75)[0x331622b905]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection21load_buffer_and_writeElRlS0_R17MIOBufferAccessorRi+0xdf)[0x6db57f]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x418)[0x6ef488]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x283)[0x6e3ee3]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x7109ff]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x43b)[0x71122b]
/home/y/bin/traffic_server[0x70fdaa]
/lib64/libpthread.so.0(+0x3297207851)[0x2b7dff1ee851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
[E. Mgmt] log == [TrafficManager] using root directory '/home/y'
[example_prep.sh] Checking/Moving old cores...
[TrafficServer] using root directory '/home/y'
{code}
gdb output below:
{code}
(gdb) bt
#0 0x00331622b2e7 in ?? () from /usr/lib64/libssl.so.10
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=value optimized
out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
#3 SSLNetVConnection::load_buffer_and_write (this=0x2b7f42c7ca70,
towrite=207693, wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30,
buf=value optimized out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:399
#4 0x006ef488 in write_to_net_io (nh=0x2b7e0f89ac10,
vc=0x2b7f42c7ca70, thread=0x2b7e0f897010) at UnixNetVConnection.cc:527
#5 0x006e3ee3 in NetHandler::mainNetEvent (this=0x2b7e0f89ac10,
event=value optimized out, e=value optimized out) at UnixNet.cc:400
#6 0x007109ff in handleEvent (this=0x2b7e0f897010, e=0x31ae0d0,
calling_code=5) at I_Continuation.h:146
#7 EThread::process_event (this=0x2b7e0f897010, e=0x31ae0d0, calling_code=5)
at UnixEThread.cc:145
#8 0x0071122b in EThread::execute (this=0x2b7e0f897010) at
UnixEThread.cc:269
#9 0x0070fdaa in spawn_thread_internal (a=0x2f8fbe0) at Thread.cc:88
#10 0x2b7dff1ee851 in start_thread () from /lib64/libpthread.so.0
#11 0x003296ee890d in clone () from /lib64/libc.so.6
(gdb) up
#1 0x00331622b905 in ssl3_write_bytes () from /usr/lib64/libssl.so.10
(gdb) up
#2 0x006db57f in do_SSL_write (this=0x2b7f42c7ca70, towrite=207693,
wattempted=@0x2b7e111aec28, total_wrote=@0x2b7e111aec30, buf=value optimized
out, needs=@0x2b7e111aec38)
at SSLNetVConnection.cc:90
90SSLNetVConnection.cc: No such file or directory.
in SSLNetVConnection.cc
(gdb)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2872) Setting Send Window for SPDY
Leif Hedstrom created TS-2872:
-
Summary: Setting Send Window for SPDY
Key: TS-2872
URL: https://issues.apache.org/jira/browse/TS-2872
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SPDY
Reporter: Leif Hedstrom
My assumption had been that setting e.g.
{code}
CONFIG proxy.config.spdy.initial_window_size_in INT 1048576
{code}
would increase the Send Window as reported by e.g. Chrome. But alas, it does
not. [~briang] sent me some patches to fix this, but that also seems to run
into another issue where configurations are not loaded properly for SPD. Still
investigating.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2870) Update SPDY defaults to better match our other defaults
[ https://issues.apache.org/jira/browse/TS-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2870. --- Resolution: Fixed Update SPDY defaults to better match our other defaults --- Key: TS-2870 URL: https://issues.apache.org/jira/browse/TS-2870 Project: Traffic Server Issue Type: Improvement Components: Configuration, SPDY Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 I think they should match what we do for HTTP/HTTPS (by default). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2873) Combine the two SPDY structs Config and SpdyConfig
[ https://issues.apache.org/jira/browse/TS-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2873: -- Fix Version/s: 5.0.0 Combine the two SPDY structs Config and SpdyConfig -- Key: TS-2873 URL: https://issues.apache.org/jira/browse/TS-2873 Project: Traffic Server Issue Type: Bug Components: Configuration, SPDY Reporter: Leif Hedstrom Fix For: 5.0.0 I can't see a reason why we need both, and the naming is very confusing. Speak up if you disagree :). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2873) Combine the two SPDY structs Config and SpdyConfig
Leif Hedstrom created TS-2873: - Summary: Combine the two SPDY structs Config and SpdyConfig Key: TS-2873 URL: https://issues.apache.org/jira/browse/TS-2873 Project: Traffic Server Issue Type: Bug Components: Configuration, SPDY Reporter: Leif Hedstrom I can't see a reason why we need both, and the naming is very confusing. Speak up if you disagree :). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2873) Combine the two SPDY structs Config and SpdyConfig
[ https://issues.apache.org/jira/browse/TS-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2873: - Assignee: Leif Hedstrom Combine the two SPDY structs Config and SpdyConfig -- Key: TS-2873 URL: https://issues.apache.org/jira/browse/TS-2873 Project: Traffic Server Issue Type: Bug Components: Configuration, SPDY Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 I can't see a reason why we need both, and the naming is very confusing. Speak up if you disagree :). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2872) Setting Send Window for SPDY
[
https://issues.apache.org/jira/browse/TS-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2872:
--
Fix Version/s: 5.0.0
Setting Send Window for SPDY
--
Key: TS-2872
URL: https://issues.apache.org/jira/browse/TS-2872
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SPDY
Reporter: Leif Hedstrom
Fix For: 5.0.0
My assumption had been that setting e.g.
{code}
CONFIG proxy.config.spdy.initial_window_size_in INT 1048576
{code}
would increase the Send Window as reported by e.g. Chrome. But alas, it does
not. [~briang] sent me some patches to fix this, but that also seems to run
into another issue where configurations are not loaded properly for SPD.
Still investigating.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2872) Setting Send Window for SPDY
[
https://issues.apache.org/jira/browse/TS-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2872:
-
Assignee: Leif Hedstrom
Setting Send Window for SPDY
--
Key: TS-2872
URL: https://issues.apache.org/jira/browse/TS-2872
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SPDY
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
My assumption had been that setting e.g.
{code}
CONFIG proxy.config.spdy.initial_window_size_in INT 1048576
{code}
would increase the Send Window as reported by e.g. Chrome. But alas, it does
not. [~briang] sent me some patches to fix this, but that also seems to run
into another issue where configurations are not loaded properly for SPD.
Still investigating.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2153) traffic_manager -tsArgs doesn't work
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2153:
--
Assignee: Jack Bates
traffic_manager -tsArgs doesn't work
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Adam Twardowski
Assignee: Jack Bates
Fix For: 5.1.0
traffic_manager -tsArgs -T 'log.*'
Running the above command on the 4.0.0 branch commit
c8931df15e33924bb459d40859a0b49331a6dbaf
resulted in no running traffic_server and the following ps output
nobody 16807 0.1 0.9 410884 18272 pts/0Sl+ 16:58 0:00
traffic_manager -tsArgs -T log.*
nobody 16816 0.0 0.0 0 0 pts/0Z+ 16:58 0:00
[traffic_manager] defunct
root 16818 0.0 0.0 103240 864 pts/1S+ 16:59 0:00 grep tr
manger.log output
--
[Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server
Args: ' -T log.*'
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup
complete
[Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE:
[LocalManager::startProxy] Launching ts process
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:
[LocalManager::startProxy] ts options must contain -M
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: (last system error 0:
Success)
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2153) traffic_manager -tsArgs doesn't work
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2153:
--
Fix Version/s: (was: sometime)
5.1.0
traffic_manager -tsArgs doesn't work
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Adam Twardowski
Fix For: 5.1.0
traffic_manager -tsArgs -T 'log.*'
Running the above command on the 4.0.0 branch commit
c8931df15e33924bb459d40859a0b49331a6dbaf
resulted in no running traffic_server and the following ps output
nobody 16807 0.1 0.9 410884 18272 pts/0Sl+ 16:58 0:00
traffic_manager -tsArgs -T log.*
nobody 16816 0.0 0.0 0 0 pts/0Z+ 16:58 0:00
[traffic_manager] defunct
root 16818 0.0 0.0 103240 864 pts/1S+ 16:59 0:00 grep tr
manger.log output
--
[Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server
Args: ' -T log.*'
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup
complete
[Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE:
[LocalManager::startProxy] Launching ts process
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:
[LocalManager::startProxy] ts options must contain -M
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: (last system error 0:
Success)
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2868) Error setting HSTS max age with traffic_line
[
https://issues.apache.org/jira/browse/TS-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017064#comment-14017064
]
ASF subversion and git services commented on TS-2868:
-
Commit 7d7cf94cd76549e3ff3191206123d96439f106f7 in trafficserver's branch
refs/heads/5.0.x from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7d7cf94 ]
Revert TS-2868: Error setting HSTS max age with traffic_line
This reverts commit 9a727b10e8e18efd9927531e86c307fa677b943f.
Error setting HSTS max age with traffic_line
Key: TS-2868
URL: https://issues.apache.org/jira/browse/TS-2868
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 5.0.0
Reporter: bettydramit
Assignee: Bryan Call
Labels: hsts
Fix For: 5.0.0
{code:xml}
traffic_line -s proxy.config.ssl.hsts_max_age -v 3600
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2868) Error setting HSTS max age with traffic_line
[
https://issues.apache.org/jira/browse/TS-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017090#comment-14017090
]
ASF subversion and git services commented on TS-2868:
-
Commit 2c757abc4eb257a670958e0b6d249a174a6ef0a6 in trafficserver's branch
refs/heads/5.0.x from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2c757ab ]
TS-2868: Error setting HSTS max age with traffic_line
Error setting HSTS max age with traffic_line
Key: TS-2868
URL: https://issues.apache.org/jira/browse/TS-2868
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 5.0.0
Reporter: bettydramit
Assignee: Bryan Call
Labels: hsts
Fix For: 5.0.0
{code:xml}
traffic_line -s proxy.config.ssl.hsts_max_age -v 3600
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2873) Cleanup SPDY configs and metrics
[ https://issues.apache.org/jira/browse/TS-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2873: -- Summary: Cleanup SPDY configs and metrics (was: Combine the two SPDY structs Config and SpdyConfig) Cleanup SPDY configs and metrics Key: TS-2873 URL: https://issues.apache.org/jira/browse/TS-2873 Project: Traffic Server Issue Type: Bug Components: Configuration, SPDY Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 I can't see a reason why we need both, and the naming is very confusing. Speak up if you disagree :). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2873) Cleanup SPDY configs and metrics
[ https://issues.apache.org/jira/browse/TS-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2873. --- Resolution: Fixed Cleanup SPDY configs and metrics Key: TS-2873 URL: https://issues.apache.org/jira/browse/TS-2873 Project: Traffic Server Issue Type: Bug Components: Configuration, SPDY Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 I can't see a reason why we need both, and the naming is very confusing. Speak up if you disagree :). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2873) Cleanup SPDY configs and metrics
[ https://issues.apache.org/jira/browse/TS-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017204#comment-14017204 ] ASF subversion and git services commented on TS-2873: - Commit cb2ca536d7412e0207a09fd9d12507950540bffb in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cb2ca53 ] TS-2873 Cleanup SPDY metrics and configs Cleanup SPDY configs and metrics Key: TS-2873 URL: https://issues.apache.org/jira/browse/TS-2873 Project: Traffic Server Issue Type: Bug Components: Configuration, SPDY Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 I can't see a reason why we need both, and the naming is very confusing. Speak up if you disagree :). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2872) Can't set Send Window for SPDY/3.1 64k
[
https://issues.apache.org/jira/browse/TS-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2872:
--
Summary: Can't set Send Window for SPDY/3.1 64k (was: Setting Send
Window for SPDY)
Can't set Send Window for SPDY/3.1 64k
--
Key: TS-2872
URL: https://issues.apache.org/jira/browse/TS-2872
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SPDY
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
My assumption had been that setting e.g.
{code}
CONFIG proxy.config.spdy.initial_window_size_in INT 1048576
{code}
would increase the Send Window as reported by e.g. Chrome. But alas, it does
not. [~briang] sent me some patches to fix this, but that also seems to run
into another issue where configurations are not loaded properly for SPD.
Still investigating.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2629) Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
[
https://issues.apache.org/jira/browse/TS-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2629:
--
Fix Version/s: (was: 5.0.0)
5.1.0
Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
---
Key: TS-2629
URL: https://issues.apache.org/jira/browse/TS-2629
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.1.0
It seems even with the default configuration:
{code}
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
{code}
ATS can create much larger orphaned logs, e.g.
{code}
$ du -h log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
442M log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2629) Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
[
https://issues.apache.org/jira/browse/TS-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2629:
--
Priority: Critical (was: Major)
Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
---
Key: TS-2629
URL: https://issues.apache.org/jira/browse/TS-2629
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: 5.1.0
It seems even with the default configuration:
{code}
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
{code}
ATS can create much larger orphaned logs, e.g.
{code}
$ du -h log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
442M log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2872) Can't set Send Window for SPDY/3.1 64k
[
https://issues.apache.org/jira/browse/TS-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017252#comment-14017252
]
ASF subversion and git services commented on TS-2872:
-
Commit 90ff1a79015a73d7906170f05c3d36fd3127e7d1 in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=90ff1a7 ]
TS-2872 Can't set Send Window for SPDY/3.1 64k.
Most of this code is Brian Geffon's fault.
Can't set Send Window for SPDY/3.1 64k
--
Key: TS-2872
URL: https://issues.apache.org/jira/browse/TS-2872
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SPDY
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
My assumption had been that setting e.g.
{code}
CONFIG proxy.config.spdy.initial_window_size_in INT 1048576
{code}
would increase the Send Window as reported by e.g. Chrome. But alas, it does
not. [~briang] sent me some patches to fix this, but that also seems to run
into another issue where configurations are not loaded properly for SPD.
Still investigating.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2872) Can't set Send Window for SPDY/3.1 64k
[
https://issues.apache.org/jira/browse/TS-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2872.
---
Resolution: Fixed
Can't set Send Window for SPDY/3.1 64k
--
Key: TS-2872
URL: https://issues.apache.org/jira/browse/TS-2872
Project: Traffic Server
Issue Type: Bug
Components: Configuration, SPDY
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
My assumption had been that setting e.g.
{code}
CONFIG proxy.config.spdy.initial_window_size_in INT 1048576
{code}
would increase the Send Window as reported by e.g. Chrome. But alas, it does
not. [~briang] sent me some patches to fix this, but that also seems to run
into another issue where configurations are not loaded properly for SPD.
Still investigating.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2868) Error setting HSTS max age with traffic_line
[
https://issues.apache.org/jira/browse/TS-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017317#comment-14017317
]
bettydramit commented on TS-2868:
-
It works
Error setting HSTS max age with traffic_line
Key: TS-2868
URL: https://issues.apache.org/jira/browse/TS-2868
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 5.0.0
Reporter: bettydramit
Assignee: Bryan Call
Labels: hsts
Fix For: 5.0.0
{code:xml}
traffic_line -s proxy.config.ssl.hsts_max_age -v 3600
traffic_line: Please correct your variable name and|or value
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2182) Setting proxy.config.net.sock_recv_buffer_size_out seriously affects performance
[
https://issues.apache.org/jira/browse/TS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017350#comment-14017350
]
Leif Hedstrom commented on TS-2182:
---
So, I can not make it perform as poorly as I saw before. However, trying many
combinations of
{code}
CONFIG proxy.config.net.sock_send_buffer_size_in INT 16M
CONFIG proxy.config.net.sock_recv_buffer_size_in INT 16M
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 16M
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 16M
{code}
with sizes from 0 (default) up to 16M, shows noticeable worse performance to
origin. I tested all 4 settings, but it's the
proxy.config.net.sock_recv_buffer_size_out that's the primary culprit. With
values from 0 - 16MB in this single setting (leaving the others at default 0),
I measure 50% slowdown compared to the default of 0. On a 70MB file fetched
over ~40ms latency, the download time went from 10s (avg) to 15s (avg).
Maybe it's something I don't understand re: to how this affects the Linux
kernel, but it seems counterintuitive that trying to modify these settings can
make it worse.
Setting proxy.config.net.sock_recv_buffer_size_out seriously affects
performance
Key: TS-2182
URL: https://issues.apache.org/jira/browse/TS-2182
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Network
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: sometime
I still need to do some more testing, but setting
{code}
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 256K
{code}
on my box reduces throughput to a (fast, local) Origin by about 1000x.
Throughput went from 18MB/sec to 15KB/sec. Removing this setting, restored
normal performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2182) Setting proxy.config.net.sock_recv_buffer_size_out seriously affects performance
[
https://issues.apache.org/jira/browse/TS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2182:
--
Fix Version/s: sometime
Setting proxy.config.net.sock_recv_buffer_size_out seriously affects
performance
Key: TS-2182
URL: https://issues.apache.org/jira/browse/TS-2182
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Network
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: sometime
I still need to do some more testing, but setting
{code}
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 256K
{code}
on my box reduces throughput to a (fast, local) Origin by about 1000x.
Throughput went from 18MB/sec to 15KB/sec. Removing this setting, restored
normal performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2866) Disable diags.show_location again
[ https://issues.apache.org/jira/browse/TS-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2866. --- Resolution: Invalid Fixed in another back port. Disable diags.show_location again - Key: TS-2866 URL: https://issues.apache.org/jira/browse/TS-2866 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom The option proxy.config.diags.show_location, which used to be off, was turned on by default. This would make sense for some debugging features, but it affects all diagnostics, and gets very verbose. I'd like to suggest we turn this back to 0 again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2860) AArch64 support
[ https://issues.apache.org/jira/browse/TS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2860: -- Fix Version/s: 5.1.0 AArch64 support --- Key: TS-2860 URL: https://issues.apache.org/jira/browse/TS-2860 Project: Traffic Server Issue Type: New Feature Components: Build, Portability Reporter: Marcin Juszkiewicz Fix For: 5.1.0 Attachments: trafficserver-aarch64.patch Out of the box traffic server does not build on AArch64 (64-bit ARM) architecture. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2860) AArch64 support
[ https://issues.apache.org/jira/browse/TS-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2860: - Assignee: Leif Hedstrom AArch64 support --- Key: TS-2860 URL: https://issues.apache.org/jira/browse/TS-2860 Project: Traffic Server Issue Type: New Feature Components: Build, Portability Reporter: Marcin Juszkiewicz Assignee: Leif Hedstrom Fix For: 5.1.0 Attachments: trafficserver-aarch64.patch Out of the box traffic server does not build on AArch64 (64-bit ARM) architecture. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2869) make check causes this error on latest Ubuntu
[ https://issues.apache.org/jira/browse/TS-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017353#comment-14017353 ] Leif Hedstrom commented on TS-2869: --- What ubuntu is that, 14.04 ? What's odd is that we run all this on our CI boxes, so something else is going wrong. See e.g. the build results on https://ci.trafficserver.apache.org/view/master/job/ubuntu_14_04-master/ make check causes this error on latest Ubuntu - Key: TS-2869 URL: https://issues.apache.org/jira/browse/TS-2869 Project: Traffic Server Issue Type: Bug Components: Build Reporter: sujata tibrewala make[3]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' CXX test_Buffer-test_Buffer.o make[3]: *** No rule to make target `../../lib/records/librecprocess.a', needed by `test_Buffer'. Stop. make[3]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sujata/trafficserver/iocore' make: *** [check-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2869) make check causes this error on latest Ubuntu
[ https://issues.apache.org/jira/browse/TS-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017358#comment-14017358 ] sujata tibrewala commented on TS-2869: -- no this is UBUNTO 13.10 make check causes this error on latest Ubuntu - Key: TS-2869 URL: https://issues.apache.org/jira/browse/TS-2869 Project: Traffic Server Issue Type: Bug Components: Build Reporter: sujata tibrewala make[3]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' CXX test_Buffer-test_Buffer.o make[3]: *** No rule to make target `../../lib/records/librecprocess.a', needed by `test_Buffer'. Stop. make[3]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sujata/trafficserver/iocore' make: *** [check-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2869) make check causes this error on latest Ubuntu
[ https://issues.apache.org/jira/browse/TS-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017362#comment-14017362 ] Leif Hedstrom commented on TS-2869: --- It looks to me like `../../lib/records/librecprocess.a is not built. But I can't tell from the truncated messages. make check causes this error on latest Ubuntu - Key: TS-2869 URL: https://issues.apache.org/jira/browse/TS-2869 Project: Traffic Server Issue Type: Bug Components: Build Reporter: sujata tibrewala make[3]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' CXX test_Buffer-test_Buffer.o make[3]: *** No rule to make target `../../lib/records/librecprocess.a', needed by `test_Buffer'. Stop. make[3]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sujata/trafficserver/iocore' make: *** [check-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2869) make check causes this error on latest Ubuntu
[ https://issues.apache.org/jira/browse/TS-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017371#comment-14017371 ] sujata tibrewala commented on TS-2869: -- btw this is all the log I got... let me try running this again. any flags I could set for the logs to be more complete make check causes this error on latest Ubuntu - Key: TS-2869 URL: https://issues.apache.org/jira/browse/TS-2869 Project: Traffic Server Issue Type: Bug Components: Build Reporter: sujata tibrewala make[3]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' CXX test_Buffer-test_Buffer.o make[3]: *** No rule to make target `../../lib/records/librecprocess.a', needed by `test_Buffer'. Stop. make[3]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sujata/trafficserver/iocore' make: *** [check-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2869) make check causes this error on latest Ubuntu
[ https://issues.apache.org/jira/browse/TS-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017373#comment-14017373 ] sujata tibrewala commented on TS-2869: -- here is the complete log I am getting: sujata@sujata-VirtualBox:~/trafficserver$ make check Making check in proxy/api/ts make[1]: Entering directory `/home/sujata/trafficserver/proxy/api/ts' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/sujata/trafficserver/proxy/api/ts' Making check in iocore make[1]: Entering directory `/home/sujata/trafficserver/iocore' Making check in eventsystem make[2]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' make test_Buffer test_Event make[3]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' make[3]: *** No rule to make target `../../lib/records/librecprocess.a', needed by `test_Buffer'. Stop. make[3]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sujata/trafficserver/iocore' make: *** [check-recursive] Error 1 sujata@sujata-VirtualBox:~/trafficserver$ make check causes this error on latest Ubuntu - Key: TS-2869 URL: https://issues.apache.org/jira/browse/TS-2869 Project: Traffic Server Issue Type: Bug Components: Build Reporter: sujata tibrewala make[3]: Entering directory `/home/sujata/trafficserver/iocore/eventsystem' CXX test_Buffer-test_Buffer.o make[3]: *** No rule to make target `../../lib/records/librecprocess.a', needed by `test_Buffer'. Stop. make[3]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/sujata/trafficserver/iocore/eventsystem' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sujata/trafficserver/iocore' make: *** [check-recursive] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
