[jira] [Commented] (TS-3080) OpenSSL implementation of TLS session cache is very slow.
[
https://issues.apache.org/jira/browse/TS-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179861#comment-14179861
]
Wei Sun commented on TS-3080:
-
I think this is good work for improving openssl built-in session cache.
To add to [~bcall]'s comment #4, we built a SSL Session Reuse (including
session ticket and session Id) system that has been running on edge servers for
several months. A few work include:
1. Rewrote session ticket part to integrate with our internal key management in
terms of security needs. It is able to rotate the keys periodically;
2. Built an external session cache based on mdbm+redis, it stores 8 millions+
encrypted entries that are shared across multiple hosts in a production cluster
(without server side latency penalty). We turned off OpenSSL internal cache,
didn't run into the {{SSL_CTX_flush_sessions}} issue since the api seems only
checks sessions stored in the internal cache;
3. The system can be integrated with other framework.
We also plan to get rid of a few internal key related stuff and contribute the
library (along with an ats plugin) if someone is interested.
OpenSSL implementation of TLS session cache is very slow.
-
Key: TS-3080
URL: https://issues.apache.org/jira/browse/TS-3080
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 5.2.0
The OpenSSL implementation of TLS session caching is very slow, we attempted
to use it and it's locking and blows up at only a few hundred QPS. I'm going
to develop a new TLS session cache in TS that is more performant under
highload.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3151) Segfault on background fill
Acacio Centeno created TS-3151:
--
Summary: Segfault on background fill
Key: TS-3151
URL: https://issues.apache.org/jira/browse/TS-3151
Project: Traffic Server
Issue Type: Bug
Reporter: Acacio Centeno
On rare occasions, a background fill will fail and lead to a segfault, with the
following stacktrace:
#0 0x0060cb6d in HttpSM::tunnel_handler_ua (this=0x2aaac2bb0750,
event=104, char=0x2aaac2bb1c60) at HttpSM.cc:3171
#1 0x00652bbe in HttpTunnel::consumer_handler (this=0x2aaac2bb1b48,
event=104, char=0x2aaac2bb1c60) at HttpTunnel.cc:1294
#2 0x006532be in HttpTunnel::main_handler (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at HttpTunnel.cc:1525
#3 0x004ebc5e in Continuation::handleEvent (this=0x2aaac2bb1b48,
event=104, data=0x2aab6c0036d0) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x0076b140 in write_signal_and_update (event=104,
vc=0x2aab6c003560) at UnixNetVConnection.cc:153
#5 0x0076b23e in write_signal_done (event=104, nh=0x2f4e2ba0,
vc=0x2aab6c003560) at UnixNetVConnection.cc:180
#6 0x0076c047 in write_to_net_io (nh=0x2f4e2ba0,
vc=0x2aab6c003560, thread=0x2f4df010) at UnixNetVConnection.cc:471
#7 0x0076ba17 in write_to_net (nh=0x2f4e2ba0, vc=0x2aab6c003560,
thread=0x2f4df010) at UnixNetVConnection.cc:352
#8 0x00765216 in NetHandler::mainNetEvent (this=0x2f4e2ba0,
event=5, long double=0x1f87bd0) at UnixNet.cc:415
#9 0x004ebc5e in Continuation::handleEvent (this=0x2f4e2ba0,
event=5, data=0x1f87bd0) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x0078beea in EThread::process_event (this=0x2f4df010, long
double=0x1f87bd0, calling_code=5) at UnixEThread.cc:145
#11 0x0078c3f4 in EThread::execute (this=0x2f4df010) at
UnixEThread.cc:269
#12 0x0078b448 in spawn_thread_internal (signed char=0x1f48c20) at
Thread.cc:88
#13 0x2c97a9d1 in start_thread () from /lib64/libpthread.so.0
#14 0x2d61c86d in clone () from /lib64/libc.so.6
This seems close to the issue reported on
https://issues.apache.org/jira/browse/TS-2705
Except that in our case, server_entry-vc-server_vc was NULL, so maybe the
appropriate solution would be to add that to the check done in
is_bg_fill_necessary, like:
if (c-producer-alive // something there to read
server_entry server_entry-vc server_entry-vc-server_vc //
from an origin server
c-producer-num_consumers 1 // with someone else reading it
) {
...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3152) We offer up H2-14 on current master, even when it's not working / supported
Leif Hedstrom created TS-3152:
-
Summary: We offer up H2-14 on current master, even when it's not
working / supported
Key: TS-3152
URL: https://issues.apache.org/jira/browse/TS-3152
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Leif Hedstrom
E.g.
{code}
[root@ats ~]# /usr/local/bin/nghttp -v https://www.ogre.com
[ 0.112][NPN] server offers:
* spdy/3.1
* spdy/3
* h2-14
* http/1.1
* http/1.0
The negotiated protocol: h2-14
...
[ 0.156] send SETTINGS frame length=0, flags=0x01, stream_id=0
; ACK
(niv=0)
[ERROR] Network error
Some requests were not processed. total=1, processed=0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3152) We offer up H2-14 on current master, even when it's not working / supported
[
https://issues.apache.org/jira/browse/TS-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180477#comment-14180477
]
Leif Hedstrom commented on TS-3152:
---
Also, reading the docs, server_ports implies that if you specify ssl, it will
by default offer up all supported protocols for NPN/ALPN. But H2-14 ought to
not be one of those :).
We offer up H2-14 on current master, even when it's not working / supported
---
Key: TS-3152
URL: https://issues.apache.org/jira/browse/TS-3152
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Leif Hedstrom
E.g.
{code}
[root@ats ~]# /usr/local/bin/nghttp -v https://www.ogre.com
[ 0.112][NPN] server offers:
* spdy/3.1
* spdy/3
* h2-14
* http/1.1
* http/1.0
The negotiated protocol: h2-14
...
[ 0.156] send SETTINGS frame length=0, flags=0x01, stream_id=0
; ACK
(niv=0)
[ERROR] Network error
Some requests were not processed. total=1, processed=0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3152) We offer up H2-14 on current master, even when it's not working / supported
[
https://issues.apache.org/jira/browse/TS-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180678#comment-14180678
]
Alan M. Carroll commented on TS-3152:
-
It's even worse. We offer SPDY even if SPDY wasn't configured and compiled.
That should fixed.
We offer up H2-14 on current master, even when it's not working / supported
---
Key: TS-3152
URL: https://issues.apache.org/jira/browse/TS-3152
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Leif Hedstrom
Fix For: 5.2.0
E.g.
{code}
[root@ats ~]# /usr/local/bin/nghttp -v https://www.ogre.com
[ 0.112][NPN] server offers:
* spdy/3.1
* spdy/3
* h2-14
* http/1.1
* http/1.0
The negotiated protocol: h2-14
...
[ 0.156] send SETTINGS frame length=0, flags=0x01, stream_id=0
; ACK
(niv=0)
[ERROR] Network error
Some requests were not processed. total=1, processed=0
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180738#comment-14180738 ] Scott Beardsley commented on TS-3026: - I believe this is fixed, ya? [~sudheerv] SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Assignee: Brian Geffon Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png, TS-3026.diff Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3026: -- Fix Version/s: (was: sometime) 5.2.0 SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Assignee: Brian Geffon Fix For: 5.2.0 Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png, TS-3026.diff Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180740#comment-14180740 ] Sudheer Vinukonda commented on TS-3026: --- [~sc0ttbeardsley] : Yes, this is fixed - updating the status to Resolved. SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Assignee: Brian Geffon Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png, TS-3026.diff Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
