[
https://issues.apache.org/jira/browse/TS-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586477#comment-13586477
]
Leif Hedstrom commented on TS-1320:
-----------------------------------
Does this look right? Rebased on current master, and changed the while()
slightly:
{code}
diff --git a/iocore/net/SSLNetVConnection.cc b/iocore/net/SSLNetVConnection.cc
index 1af06d4..ee57ad9 100644
--- a/iocore/net/SSLNetVConnection.cc
+++ b/iocore/net/SSLNetVConnection.cc
@@ -258,11 +258,11 @@ SSLNetVConnection::net_read_io(NetHandler *nh, EThread
*lthread)
if (ret == SSL_READ_READY || ret == SSL_READ_ERROR_NONE) {
bytes += r;
}
-
- } while (ret == SSL_READ_READY || ret == SSL_READ_ERROR_NONE);
+ ink_debug_assert(bytes >= 0);
+ } while ((ret == SSL_READ_READY && bytes == 0) || ret ==
SSL_READ_ERROR_NONE);
if (bytes > 0) {
- if (ret == SSL_READ_WOULD_BLOCK) {
+ if (ret == SSL_READ_WOULD_BLOCK || ret == SSL_READ_READY) {
if (readSignalAndUpdate(VC_EVENT_READ_READY) != EVENT_CONT) {
Debug("ssl", "ssl_read_from_net, readSignal != EVENT_CONT");
return;
@@ -273,8 +273,8 @@ SSLNetVConnection::net_read_io(NetHandler *nh, EThread
*lthread)
switch (ret) {
case SSL_READ_ERROR_NONE:
case SSL_READ_READY:
- // how did we exit the while loop above? should never happen.
- ink_debug_assert(false);
+ readReschedule(nh);
+ return;
break;
case SSL_WRITE_WOULD_BLOCK:
case SSL_READ_WOULD_BLOCK:
{code}
> Reading from SSL origin can starve sending data to client
> ---------------------------------------------------------
>
> Key: TS-1320
> URL: https://issues.apache.org/jira/browse/TS-1320
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
> Affects Versions: 3.0.4
> Reporter: William Bardwell
> Assignee: Leif Hedstrom
> Priority: Minor
> Fix For: 3.3.1
>
>
> When we had a fast connection doing SSL to an origin server, and a slower
> connection to the client, and not very much CPU, the SSL VConn code would
> start to spin reading data from the origin server, and not breaking out of
> the loop at all to send data to the client. As a result the throughput to
> the client would drop to zero and ATS would get a bit bigger. So my proposed
> patch is to have the SSL VConn code not stay in its loop when it has some
> data that it has read, this matches how non-SSL network VConn's work. My one
> concern with this is that there might have been a good reason for that
> looping, and that this might slow down cases when things are working properly.
--
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
