[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4506:


Github user masaori335 commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/749#discussion_r68698335
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -8199,13 +8199,15 @@ HttpTransact::build_error_response(State *s, 
HTTPStatus status_code, const char
 if (has_ua_msie)
   s->hdr_info.client_response.value_set(MIME_FIELD_PROXY_CONNECTION, 
MIME_LEN_PROXY_CONNECTION, "close", 5);
   }
-  // Add a bunch of headers to make sure that caches between
-  // the Traffic Server and the client do not cache the error
-  // page.
+  // Make sure that caches between the Traffic Server and the client do 
not cache the error.
+  // ToDo: Not sure this matches expectation in RFC 7223.
--- End diff --

Looks a typ. RFC 7232 is correct?


> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is an ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which we are not supposed to 
> touch. Now, we do overwrite the Cc: header, so maybe we should remove that 
> too ?
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Created] (TS-4603) varargs promotion in NetworkMessage

[James Peach (JIRA)]

James Peach created TS-4603:
---

 Summary: varargs promotion in NetworkMessage
 Key: TS-4603
 URL: https://issues.apache.org/jira/browse/TS-4603
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: James Peach


Building with top-of-tree clang:

{code}
NetworkMessage.cc:137:16: error: passing an object that undergoes default 
argument promotion
  to 'va_start' has undefined behavior [-Werror,-Wvarargs]
  va_start(ap, optype);
   ^
NetworkMessage.cc:127:58: note: parameter of type 'OpType' is declared here
send_mgmt_request(const mgmt_message_sender , OpType optype, ...)
 ^
NetworkMessage.cc:147:16: error: passing an object that undergoes default 
argument promotion
  to 'va_start' has undefined behavior [-Werror,-Wvarargs]
  va_start(ap, optype);
{code}



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4506:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/749
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/366/ for details.
 



> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is an ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which we are not supposed to 
> touch. Now, we do overwrite the Cc: header, so maybe we should remove that 
> too ?
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4506:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/749
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/261/ for details.
 



> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is an ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which we are not supposed to 
> touch. Now, we do overwrite the Cc: header, so maybe we should remove that 
> too ?
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4506:
---

I've updated the PR, lets continue the discussions there (which gets cross 
posted here), such that the PR tracks all the review comments.

> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is an ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which we are not supposed to 
> touch. Now, we do overwrite the Cc: header, so maybe we should remove that 
> too ?
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Updated] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4506:
--
Description: 
Right now, when ATS generates a 304 response (Not Modified), we always remove 
the Last-Modified header. Reading the RFC, we should only remove the 
Last-Modified header if there is an ETag header. This is a simple fix, and we 
should just do it IMO.

It also always removes the Expires headers, which we are not supposed to touch. 
Now, we do overwrite the Cc: header, so maybe we should remove that too ?

>From https://tools.ietf.org/html/rfc7232#page-18:

{code}
   The server generating a 304 response MUST generate any of the
   following header fields that would have been sent in a 200 (OK)
   response to the same request: Cache-Control, Content-Location, Date,
   ETag, Expires, and Vary.

   Since the goal of a 304 response is to minimize information transfer
   when the recipient already has one or more cached representations, a
   sender SHOULD NOT generate representation metadata other than the
   above listed fields unless said metadata exists for the purpose of
   guiding cache updates (e.g., Last-Modified might be useful if the
   response does not have an ETag field).
{code}

  was:
Right now, when ATS generates a 304 response (Not Modified), we always remove 
the Last-Modified header. Reading the RFC, we should only remove the 
Last-Modified header if there is no ETag header. This is a simple fix, and we 
should just do it IMO.

It also always removes the Expires headers, which is outright wrong.

>From https://tools.ietf.org/html/rfc7232#page-18:

{code}
   The server generating a 304 response MUST generate any of the
   following header fields that would have been sent in a 200 (OK)
   response to the same request: Cache-Control, Content-Location, Date,
   ETag, Expires, and Vary.

   Since the goal of a 304 response is to minimize information transfer
   when the recipient already has one or more cached representations, a
   sender SHOULD NOT generate representation metadata other than the
   above listed fields unless said metadata exists for the purpose of
   guiding cache updates (e.g., Last-Modified might be useful if the
   response does not have an ETag field).
{code}


> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is an ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which we are not supposed to 
> touch. Now, we do overwrite the Cc: header, so maybe we should remove that 
> too ?
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4506:
---

Yes, deleting the Last-Modified unconditionally, i.e. even when there is no 
ETag, definitely causes problems. :). That's why I had to produce this patch.

> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is no ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4506:
---

Ok, let me clarify the commit msgs vs commits, and make sure it all makes sense.

Are you suggesting that we should continue to remove the Expires header? CC: 
would take precedence, but maybe we shouldn't set Cc: at all?

Finally, it seems that the RFC suggests that you should remove Last-Modified in 
most cases, except *maybe* keep it if there is no ETag.

> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is no ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-3371) Should create a global session ticket disable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3371:


Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/750#discussion_r68694184
  
--- Diff: mgmt/RecordsConfig.cc ---
@@ -1212,6 +1212,8 @@ static const RecordElement RecordsConfig[] =
   
//##
   {RECT_CONFIG, "proxy.config.ssl.enabled", RECD_INT, "0", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
   ,
+  {RECT_CONFIG, "proxy.config.ssl.session.ticket.enabled", RECD_INT, "1", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
--- End diff --

Also, I'm a bit torn on what the correct nomenclature should be. We have 
``proxy.config.ssl.server.ticket_key.filename`` so maybe this should be 
``proxy.config.ssl.server.session_ticket.enable``? But there are also quite a 
few SSL settings that don't include the ``server`` component (even though they 
are server-specific).

I believe that the original intent was that ``proxy.config.ssl.foo`` would 
apply ``foo`` to both client and server sessions. This is the way the SSL 
context options work (see ``proxy.config.ssl.compression`` for example).


> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the ATS to set the ssl_ticket_enabled=0 
> for every entry in ssl_multicert.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

[jira] [Commented] (TS-3371) Should create a global session ticket disable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3371:


Github user jpeach commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/750#discussion_r68693861
  
--- Diff: mgmt/RecordsConfig.cc ---
@@ -1212,6 +1212,8 @@ static const RecordElement RecordsConfig[] =
   
//##
   {RECT_CONFIG, "proxy.config.ssl.enabled", RECD_INT, "0", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
   ,
+  {RECT_CONFIG, "proxy.config.ssl.session.ticket.enabled", RECD_INT, "1", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
--- End diff --

``RECU_RESTART_TS`` means you need to restart Traffic Server when you 
change this setting. AFAICT you just need to touch ``ssl_mulicert.config`` and 
reload config, so this probably should be ``RECU_DYNAMIC``.


> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the ATS to set the ssl_ticket_enabled=0 
> for every entry in ssl_multicert.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[James Peach (JIRA)]

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

James Peach commented on TS-4506:
-

I interpreted the RFC quote as saying you shouldn't generate any additional 
field except for the ones that help with caching. Since Last-Modified helps 
with caching, it is OK to generate that. I don't see any requirement to not 
generate it if there is an ETag header.

I agree that unconditionally deleting it would be incorrect.

> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is no ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[William Bardwell (JIRA)]

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

William Bardwell commented on TS-4506:
--

Your patch matches the description in the initial bug ticket, but not in the 
comment and commit comment, and the patch seems backwards...(the later comments 
seem right...don't delete Last-Modified unless there is an ETag that serves the 
same purpose.)
I would argue that deleting the Last-Modified seems weird unless you are sure 
that the client did a If-None-Match...otherwise (theoretically, although seems 
pretty unlikely) they might not have an ETag to compare with...
Also isn't it removing Expires because it is hard coding Cache-Control to 
no-store?

> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is no ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-2403) Segfault when HostDB full

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-2403:


The fix for this long-term is comitted (TS-4331), for multicache its a bit 
difficult to fix this-- so I'm not sure if we want to leave this open or just 
close it as this is fixed in 7.x

> Segfault when HostDB full
> -
>
> Key: TS-2403
> URL: https://issues.apache.org/jira/browse/TS-2403
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 4.0.1
>Reporter: David Carlin
>Assignee: Thomas Jackson
>  Labels: Crash
> Fix For: sometime
>
>
> diags.log leading up to crash:
> {noformat}
> [Nov 25 10:50:23.346] Server {0x2b06c4302700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.379] Server {0x2b06c4100700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.449] Server {0x2b06c4a09700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.462] Server {0x2b06c4403700} WARNING: out of room in hostdb 
> for round-robin DNS data
> [Nov 25 10:50:23.494] Server {0x2b06bed1f540} WARNING: out of room in hostdb 
> for reverse DNS data
> [Nov 25 10:54:46.919] {0x2baa2d65b540} STATUS: opened 
> /home/y/logs/trafficserver/diags.log
> [Nov 25 10:54:46.927] {0x2baa2d65b540} NOTE: updated diags config
> [Nov 25 10:54:46.961] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:46.995] Server {0x2baa2d65b540} NOTE: ip_allow.config updated, 
> reloading
> [Nov 25 10:54:47.059] Server {0x2baa2d65b540} NOTE: cache clustering disabled
> [Nov 25 10:54:47.072] Server {0x2baa2d65b540} NOTE: logging initialized[15], 
> logging_mode = 3
> [Nov 25 10:54:47.103] Server {0x2baa2d65b540} NOTE: loading plugin 
> '/home/y/libexec64/trafficserver/quick_filter.so'
> [Nov 25 10:54:47.326] Server {0x2baa2d65b540} NOTE: loading plugin 
> '/home/y/libexec64/trafficserver/header_filter.so'
> [Nov 25 10:54:49.395] Server {0x2baa2d65b540} NOTE: traffic server running
> {noformat}
> From traffic.out:
> {noformat}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x3d07c0f500)[0x2b06be27a500]
> /home/y/bin/traffic_server(_Z14ats_ip_addr_eqPK8sockaddrS1_+0x3)[0x5e0323]
> /home/y/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x2389)[0x5df3b9]
> /home/y/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f9cd4]
> /home/y/bin/traffic_server[0x5fbd17]
> /home/y/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x8d0)[0x5fd5c0]
> /home/y/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x12)[0x5fe642]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a321f]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a3c03]
> /home/y/bin/traffic_server(main+0xb14)[0x4c5314]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3d0781ecdd]
> /home/y/bin/traffic_server[0x485a19]
> {noformat}
> Backtrace:
> {noformat}
> #0  ats_ip_addr_cmp (lhs=0x7fffdf15e778, rhs=0x8) at 
> ../../lib/ts/ink_inet.h:669
> #1  ats_ip_addr_eq (lhs=0x7fffdf15e778, rhs=0x8) at 
> ../../lib/ts/ink_inet.h:721
> #2  0x005df3b9 in restore_info (this=, 
> event=, e=) at HostDB.cc:1375
> #3  HostDBContinuation::dnsEvent (this=, event= optimized out>, e=) at HostDB.cc:1604
> #4  0x005f9cd4 in handleEvent (this=0x2b06f40a2120) at 
> ../../iocore/eventsystem/I_Continuation.h:146
> #5  DNSEntry::postEvent (this=0x2b06f40a2120) at DNS.cc:1278
> #6  0x005fbd17 in dns_result (h=0x1778380, e=0x2b06f40a2120, 
> ent=0x1913820, retry=) at DNS.cc:1230
> #7  0x005fd5c0 in dns_process (this=0x1778380) at DNS.cc:1599
> #8  DNSHandler::recv_dns (this=0x1778380) at DNS.cc:790
> #9  0x005fe642 in DNSHandler::mainEvent (this=0x1778380, event= optimized out>, e=) at DNS.cc:802
> #10 0x006a321f in handleEvent (this=0x2b06bf2d0010, e=0x2b06d8092740, 
> calling_code=5) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2b06bf2d0010, e=0x2b06d8092740, 
> calling_code=5) at UnixEThread.cc:141
> #12 0x006a3c03 in EThread::execute (this=0x2b06bf2d0010) at 
> UnixEThread.cc:265
> #13 0x004c5314 in main (argv=) at Main.cc:1690
> {noformat}
> HostDB settings:
> CONFIG proxy.config.hostdb.size INT 20
> CONFIG proxy.config.hostdb.storage_size INT 50331648
> CONFIG proxy.config.hostdb.ttl_mode INT 0
> CONFIG proxy.config.hostdb.timeout INT 1440
> CONFIG proxy.config.hostdb.strict_round_robin INT 0



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

[jira] [Resolved] (TS-3166) HostDB Upgrade

[Thomas Jackson (JIRA)]

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

Thomas Jackson resolved TS-3166.

   Resolution: Fixed
Fix Version/s: (was: sometime)
   7.0.0

> HostDB Upgrade
> --
>
> Key: TS-3166
> URL: https://issues.apache.org/jira/browse/TS-3166
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: DNS, HostDB
>Reporter: Alan M. Carroll
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Implement the HostDB upgrade as described in 
> https://cwiki.apache.org/confluence/download/attachments/47384310/ApacheCon-2014-Host-Resolution.pdf?version=1=1414085058000=v2



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

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

[Thomas Jackson (JIRA)]

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

Thomas Jackson resolved TS-4232.

Resolution: Fixed

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



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

[jira] [Resolved] (TS-4278) HostDB sync causes active transactions to block for 100's of ms

[Thomas Jackson (JIRA)]

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

Thomas Jackson resolved TS-4278.

Resolution: Fixed

I merged the new hostdb caching layer in today-- so this issue is no more!

> HostDB sync causes active transactions to block for 100's of ms
> ---
>
> Key: TS-4278
> URL: https://issues.apache.org/jira/browse/TS-4278
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Susan Hinrichs
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> When HostDB syncs to disk (by default every two minutes), active transactions 
> will block when they reach HttpSM::do_hostdb_lookup.  This is because 
> do_hostdb_lookup calls hostDBProcessor.getbyname_imm which attempts to get 
> the bucket locks.   The delays generally last for 500-1200ms.  This blocks 
> the event loop so no other actions will be performed by the net handler until 
> the lock is dropped.
> I'm assuming that the bucket locks are grabbed by the sync logic.  When I 
> increased proxy.config.cache.hostdb.sync_frequency to 1200, the every two 
> minute slow down went away.  Fortunately 
> proxy.config.cache.hostdb.sync_frequency set to 0 seems to completely 
> eliminate the sync, which will be my suggested solution internally.
> I tried reducing the size of the hostdb table, but that didn't seem to affect 
> the delay time.
> The delay only reliably exhibited on loaded system.  Running my httperf test 
> case on a machine with no other activity did not show the delays.



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/260/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Resolved] (TS-4331) Hostdb consistency problems due to MultiCache

[Thomas Jackson (JIRA)]

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

Thomas Jackson resolved TS-4331.

Resolution: Fixed

> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/365/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF subversion and git services (JIRA)]

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

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

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

TS-4331: Major re-write of hostdb (#653)

* Consolidate SRV `alive` checks to use the `alive` method on `HostDBInfo`

* TS-4331 Replace MultiCache with RefCountCache

* Misc cleanup to hostdb before cleanup

Before doing the rewrite of hostdb (TS-4331) this commit cleans up someo f the 
method names etc. to make this subsystem less confusing


> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user jacksontj closed the pull request at:

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


> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF subversion and git services (JIRA)]

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

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

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

TS-4331: Major re-write of hostdb (#653)

* Consolidate SRV `alive` checks to use the `alive` method on `HostDBInfo`

* TS-4331 Replace MultiCache with RefCountCache

* Misc cleanup to hostdb before cleanup

Before doing the rewrite of hostdb (TS-4331) this commit cleans up someo f the 
method names etc. to make this subsystem less confusing


> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF subversion and git services (JIRA)]

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

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

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

TS-4331: Major re-write of hostdb (#653)

* Consolidate SRV `alive` checks to use the `alive` method on `HostDBInfo`

* TS-4331 Replace MultiCache with RefCountCache

* Misc cleanup to hostdb before cleanup

Before doing the rewrite of hostdb (TS-4331) this commit cleans up someo f the 
method names etc. to make this subsystem less confusing


> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
 


> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/259/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/364/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/258/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/363/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/257/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Created] (TS-4602) Cleanup HttpSM's references to HostDBInfo

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4602:
--

 Summary: Cleanup HttpSM's references to HostDBInfo
 Key: TS-4602
 URL: https://issues.apache.org/jira/browse/TS-4602
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Thomas Jackson


Right now there is a copy of the record, as well as a Ptr<> to the actual item. 
Since we are now refcounted-- we should remove the copy and just make it a 
HostDBInfo* of which record in the parent we've selected.



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

[jira] [Updated] (TS-4602) Cleanup HttpSM's references to HostDBInfo

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4602:
---
Fix Version/s: 7.0.0

> Cleanup HttpSM's references to HostDBInfo
> -
>
> Key: TS-4602
> URL: https://issues.apache.org/jira/browse/TS-4602
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Right now there is a copy of the record, as well as a Ptr<> to the actual 
> item. Since we are now refcounted-- we should remove the copy and just make 
> it a HostDBInfo* of which record in the parent we've selected.



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

[jira] [Assigned] (TS-4602) Cleanup HttpSM's references to HostDBInfo

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4602:
--

Assignee: Thomas Jackson

> Cleanup HttpSM's references to HostDBInfo
> -
>
> Key: TS-4602
> URL: https://issues.apache.org/jira/browse/TS-4602
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> Right now there is a copy of the record, as well as a Ptr<> to the actual 
> item. Since we are now refcounted-- we should remove the copy and just make 
> it a HostDBInfo* of which record in the parent we've selected.



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/362/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/256/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/255/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/361/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Updated] (TS-4601) Connection error from origin_max_connection with origin_max_connections_queue set to 0 should not retry

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-4601:
---
Summary: Connection error from origin_max_connection with 
origin_max_connections_queue set to 0 should not retry  (was: Connection abort 
from origin_max_connection with origin_max_connections_queue set to 0 should 
not retry)

> Connection error from origin_max_connection with origin_max_connections_queue 
> set to 0 should not retry
> ---
>
> Key: TS-4601
> URL: https://issues.apache.org/jira/browse/TS-4601
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> While adding a metric to track the number of times a connection to origin is 
> dropped due to being over the origin_max_connections limit, I noticed that 
> the count was increments three times as fast as I expected from my 
> experiment.  My connection retry count was 3.  I changed the logic to set the 
> current attempts to max to avoid the retries in that case.
> [~jacksontj] avoiding the retries makes sense in this case, right?
> I also propose adding a proxy.process.http.origin_connections_throttled 
> metric to track how many connections to origin are being error'ed out the 
> origin_max_connection limit.  The metric is only incremented when the queue 
> is 0 or we are over the delay queued limit.



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

[jira] [Comment Edited] (TS-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[Thomas Jackson (JIRA)]

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

Thomas Jackson edited comment on TS-4509 at 6/27/16 11:30 PM:
--

Another thing I noticed while debugging something unrelated-- it seems that ATS 
specifically will not do KA (regardless of config) if the first connection 
attempt failed 
(https://github.com/apache/trafficserver/blob/master/proxy/http/HttpTransact.cc#L3864)--
 this seems like something we *don't* want, especially after the race condition 
is fixed :)


was (Author: jacksontj):
Another thing I noticed while debugging something unrelated-- it seems that ATS 
specifically will not do KA (regardless of config) if the first connection 
attempt failed 
(https://github.com/apache/trafficserver/blob/master/proxy/http/HttpTransact.cc#L3864)--
 this seems like something we *don't* want, especially after race condition is 
fixed :)

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.0.0
>
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP dumps on the system, nginx is not actually sending any form of 
> response.
> In these example cases the backend server isn't sending back any data (at 
> least as far as I can tell), so from what I understand (and the logic 
> outlined in https://issues.apache.org/jira/browse/TS-3440), it should be safe 
> to retry.
> Let me know if I can provide any other details. Or if exact scripts to 
> reproduce the issues against the example nginx backend I described above 
> would be useful, I could get that together.



--
This message was sent by Atlassian JIRA

[jira] [Updated] (TS-4601) Connection abort from origin_max_connection with origin_max_connections_queue set to 0 should not retry

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-4601:
---
Description: 
While adding a metric to track the number of times a connection to origin is 
dropped due to being over the origin_max_connections limit, I noticed that the 
count was increments three times as fast as I expected from my experiment.  My 
connection retry count was 3.  I changed the logic to set the current attempts 
to max to avoid the retries in that case.

[~jacksontj] avoiding the retries makes sense in this case, right?

I also propose adding a proxy.process.http.origin_connections_throttled metric 
to track how many connections to origin are being error'ed out the 
origin_max_connection limit.  The metric is only incremented when the queue is 
0 or we are over the delay queued limit.

  was:
While adding a metric to track the number of times a connection to origin is 
dropped due to being over the origin_max_connections limit, I noticed that the 
count was increments three times as fast as I expected from my experiment.  My 
connection retry count was 3.  I changed the logic to set the current attempts 
to max to avoid the retries in that case.

[~jacksontj] avoiding the retries makes sense in this case, right?


> Connection abort from origin_max_connection with origin_max_connections_queue 
> set to 0 should not retry
> ---
>
> Key: TS-4601
> URL: https://issues.apache.org/jira/browse/TS-4601
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> While adding a metric to track the number of times a connection to origin is 
> dropped due to being over the origin_max_connections limit, I noticed that 
> the count was increments three times as fast as I expected from my 
> experiment.  My connection retry count was 3.  I changed the logic to set the 
> current attempts to max to avoid the retries in that case.
> [~jacksontj] avoiding the retries makes sense in this case, right?
> I also propose adding a proxy.process.http.origin_connections_throttled 
> metric to track how many connections to origin are being error'ed out the 
> origin_max_connection limit.  The metric is only incremented when the queue 
> is 0 or we are over the delay queued limit.



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

[jira] [Comment Edited] (TS-4509) Dropped keep-alive connections not being re-established (TS-3959 continued)

[Thomas Jackson (JIRA)]

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

Thomas Jackson edited comment on TS-4509 at 6/27/16 11:29 PM:
--

Did some additional work on the fix today (updated my branch on github-- 
https://github.com/apache/trafficserver/commit/cff8ba1bc1e6b8236a772fbb7f00852288a0f757).
 Basically I've just added an `outstanding_bytes` method to the VConnection. 
The only thing I'm not terribly happy about is the sent byte counter-- right 
now I'm using the header size, but it would be better if there was some counter 
on the VConnection (but AFAIK there isn't one-- maybe [~amc] would know?). If 
there isn't such a counter-- adding one shouldn't be too much of a pain-- 
although to have accurate byte counter metrics I'd expect we have it somewhere 
already.


was (Author: jacksontj):
Did some additional work on the fix today (updated my branch on github-- 
https://github.com/apache/trafficserver/compare/master...jacksontj:TS-3959). 
Basically I've just added an `outstanding_bytes` method to the VConnection. The 
only thing I'm not terribly happy about is the sent byte counter-- right now 
I'm using the header size, but it would be better if there was some counter on 
the VConnection (but AFAIK there isn't one-- maybe [~amc] would know?). If 
there isn't such a counter-- adding one shouldn't be too much of a pain-- 
although to have accurate byte counter metrics I'd expect we have it somewhere 
already.

> Dropped keep-alive connections not being re-established (TS-3959 continued)
> ---
>
> Key: TS-4509
> URL: https://issues.apache.org/jira/browse/TS-4509
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.0.0
>
>
> I've observed some differences in how TrafficServer 6.0.0 behaves with 
> connection retrying and outgoing keep-alive connections. I believe the 
> changes in behavior might be related to this issue: 
> https://issues.apache.org/jira/browse/TS-3440
> I originally wasn't sure if this was a bug, but James Peach indicated it 
> sounded more like a regression on the mailing list 
> (http://mail-archives.apache.org/mod_mbox/trafficserver-users/201510.mbox/%3cba85d5a2-8b29-44a9-acdc-e7fa8d21f...@apache.org%3e).
> What I'm seeing in 6.0.0 is that if TrafficServer has some backend keep-alive 
> connections already opened, but then one of the keep-alive connections is 
> closed, the next request to TrafficServer may generate a 502 Server Hangup 
> response when attempting to reuse that connection. Previously, I think 
> TrafficServer was retrying when it encountered a closed keep-alive 
> connection, but that is no longer the case. So if you have a backend that 
> might unexpectedly close its open keep-alive connections, the only way I've 
> found to completely prevent these 502 errors in 6.0.0 is to disable outgoing 
> keepalive (proxy.config.http.keep_alive_enabled_out and 
> proxy.config.http.keep_alive_post_out settings).
> For a slightly more concrete example of what can trigger this, this is fairly 
> easy to reproduce with the following setup:
> - TrafficServer is proxying to nginx with outgoing keep-alive connections 
> enabled (the default).
> - Throw a constant stream of requests at TrafficServer.
> - While that constant stream of requests is happening, also send a regular 
> stream of SIGHUP commands to nginx to reload nginx.
> - Eventually you'll get some 502 Server Hangup responses from TrafficServer 
> among your stream of requests.
> SIGHUPs in nginx should result in zero downtime for new requests, but I think 
> what's happening is that TrafficServer may fail when an old keep-alived 
> connection is reused (it's not common, so it depends on the timing of things 
> and if the connection is from an old nginx worker that has since been shut 
> down). In TrafficServer 5.3.1 these connection failures were retried, but in 
> 6.0.0, no retries occur in this case.
> Here's some debug logs that show the difference in behavior between 6.0.0 and 
> 5.3.1. Note that differences seem to stem from how each version eventually 
> handles the "VC_EVENT_EOS" event following 
> "::state_send_server_request_header, VC_EVENT_WRITE_COMPLETE".
> 5.3.1: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_5-3-1-log-L316
> 6.0.0: 
> https://gist.github.com/GUI/0c53a6c4fdc2782b14aa#file-trafficserver_6-0-0-log-L314
> Interestingly, if I'm understand the log files correctly, it looks like 
> TraffficServer is reporting an odd empty response from these connections 
> ("HTTP/0.9 0" in 5.3.1 and "HTTP/1.0 0" in 6.0.0). However, as far as I can 
> tell from TCP 

[jira] [Created] (TS-4601) Connection abort from origin_max_connection with origin_max_connections_queue set to 0 should not retry

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-4601:
--

 Summary: Connection abort from origin_max_connection with 
origin_max_connections_queue set to 0 should not retry
 Key: TS-4601
 URL: https://issues.apache.org/jira/browse/TS-4601
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Susan Hinrichs


While adding a metric to track the number of times a connection to origin is 
dropped due to being over the origin_max_connections limit, I noticed that the 
count was increments three times as fast as I expected from my experiment.  My 
connection retry count was 3.  I changed the logic to set the current attempts 
to max to avoid the retries in that case.

[~jacksontj] avoiding the retries makes sense in this case, right?



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

[jira] [Assigned] (TS-4601) Connection abort from origin_max_connection with origin_max_connections_queue set to 0 should not retry

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-4601:
--

Assignee: Susan Hinrichs

> Connection abort from origin_max_connection with origin_max_connections_queue 
> set to 0 should not retry
> ---
>
> Key: TS-4601
> URL: https://issues.apache.org/jira/browse/TS-4601
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> While adding a metric to track the number of times a connection to origin is 
> dropped due to being over the origin_max_connections limit, I noticed that 
> the count was increments three times as fast as I expected from my 
> experiment.  My connection retry count was 3.  I changed the logic to set the 
> current attempts to max to avoid the retries in that case.
> [~jacksontj] avoiding the retries makes sense in this case, right?



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user jacksontj commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/653#discussion_r68673753
  
--- Diff: iocore/hostdb/P_RefCountCache.h ---
@@ -0,0 +1,896 @@
+/** @file
+
+  A cache (with map-esque interface) for RefCountObjs
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+#ifndef _P_RefCountCache_h_
+#define _P_RefCountCache_h_
+
+#include "I_EventSystem.h"
+#include "P_EventSystem.h" // TODO: less? just need ET_TASK
+
+#include 
+#include "ts/PriorityQueue.h"
+
+#include 
+#include 
+
+#include "ts/Vec.h"
+#include "ts/I_Version.h"
+#include 
+
+#define REFCOUNT_CACHE_EVENT_SYNC REFCOUNT_CACHE_EVENT_EVENTS_START
+
+#define REFCOUNTCACHE_MAGIC_NUMBER 0x0BAD2D9
+#define REFCOUNTCACHE_MAJOR_VERSION 1
+#define REFCOUNTCACHE_MINOR_VERSION 0
+
+// Stats
+enum RefCountCache_Stats {
+  refcountcache_current_items_stat,// current number of items
+  refcountcache_current_size_stat, // current size of cache
+  refcountcache_total_inserts_stat,// total items inserted
+  refcountcache_total_failed_inserts_stat, // total items unable to insert
+  refcountcache_total_lookups_stat,// total get() calls
+  refcountcache_total_hits_stat,   // total hits
+
+  // Persistence metrics
+  refcountcache_last_sync_time,   // seconds since epoch of last 
successful sync
+  refcountcache_last_total_items, // number of items sync last time
+  refcountcache_last_total_size,  // total size at last sync
+
+  RefCountCache_Stat_Count
+};
+
+struct RefCountCacheItemMeta {
+  uint64_t key;
+  unsigned int size;
+  ink_time_t expiry_time; // expire time as seconds since epoch
+  RefCountCacheItemMeta(uint64_t key, unsigned int size, int expire_time = 
-1) : key(key), size(size), expiry_time(expire_time) {}
+};
+
+// Layer of indirection for the hashmap-- since it needs lots of things 
inside of it
+// We'll also use this as the item header, for persisting objects to disk
+class RefCountCacheHashEntry
+{
+public:
+  Ptr item;
+  LINK(RefCountCacheHashEntry, item_link);
+
+  PriorityQueueEntry *expiry_entry;
+
+  RefCountCacheItemMeta meta;
+  void
+  set(RefCountObj *i, uint64_t key, unsigned int size, int expire_time)
+  {
+this->item = make_ptr(i);
+this->meta = RefCountCacheItemMeta(key, size, expire_time);
+  };
+  // Need a no-argument constructor to use the classAllocator
+  RefCountCacheHashEntry() : expiry_entry(NULL), meta(0, 0){};
+
+  // make these values comparable -- so we can sort them
+  bool
+  operator<(const RefCountCacheHashEntry ) const
+  {
+return this->meta.expiry_time < v2.meta.expiry_time;
+  };
+};
+// Since the hashing values are all fixed size, we can simply use a 
classAllocator to avoid mallocs
+extern ClassAllocator 
refCountCacheHashingValueAllocator;
+extern ClassAllocator 
expiryQueueEntry;
+
+struct RefCountCacheHashing {
+  typedef uint64_t ID;
+  typedef uint64_t const Key;
+  typedef RefCountCacheHashEntry Value;
+  typedef DList(RefCountCacheHashEntry, item_link) ListHead;
+
+  static ID
+  hash(Key key)
+  {
+return key;
+  }
+  static Key
+  key(Value const *value)
+  {
+return value->meta.key;
+  }
+  static bool
+  equal(Key lhs, Key rhs)
+  {
+return lhs == rhs;
+  }
+};
+
+// The RefCountCachePartition is simply a map of key -> Ptr
+// We partition the cache to reduce lock contention
+template  class RefCountCachePartition
+{
+public:
+  

[jira] [Updated] (TS-4599) Add const_iterator to TSHashMap

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4599:
---
Fix Version/s: sometime

> Add const_iterator to TSHashMap
> ---
>
> Key: TS-4599
> URL: https://issues.apache.org/jira/browse/TS-4599
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Thomas Jackson
> Fix For: sometime
>
>




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

[jira] [Created] (TS-4599) Add const_iterator to TSHashMap

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4599:
--

 Summary: Add const_iterator to TSHashMap
 Key: TS-4599
 URL: https://issues.apache.org/jira/browse/TS-4599
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Thomas Jackson






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

[jira] [Updated] (TS-4600) Make RefCountCachePartition::copy const

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4600:
---
Fix Version/s: sometime

> Make RefCountCachePartition::copy const
> --
>
> Key: TS-4600
> URL: https://issues.apache.org/jira/browse/TS-4600
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Thomas Jackson
> Fix For: sometime
>
>
> Make copy return a const



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

[jira] [Created] (TS-4600) Make RefCountCachePartition::copy const

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4600:
--

 Summary: Make RefCountCachePartition::copy const
 Key: TS-4600
 URL: https://issues.apache.org/jira/browse/TS-4600
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Thomas Jackson


Make copy return a const



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user jacksontj commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/653#discussion_r68673510
  
--- Diff: iocore/hostdb/P_RefCountCache.h ---
@@ -0,0 +1,896 @@
+/** @file
+
+  A cache (with map-esque interface) for RefCountObjs
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+#ifndef _P_RefCountCache_h_
+#define _P_RefCountCache_h_
+
+#include "I_EventSystem.h"
+#include "P_EventSystem.h" // TODO: less? just need ET_TASK
+
+#include 
+#include "ts/PriorityQueue.h"
+
+#include 
+#include 
+
+#include "ts/Vec.h"
+#include "ts/I_Version.h"
+#include 
+
+#define REFCOUNT_CACHE_EVENT_SYNC REFCOUNT_CACHE_EVENT_EVENTS_START
+
+#define REFCOUNTCACHE_MAGIC_NUMBER 0x0BAD2D9
+#define REFCOUNTCACHE_MAJOR_VERSION 1
+#define REFCOUNTCACHE_MINOR_VERSION 0
+
+// Stats
+enum RefCountCache_Stats {
+  refcountcache_current_items_stat,// current number of items
+  refcountcache_current_size_stat, // current size of cache
+  refcountcache_total_inserts_stat,// total items inserted
+  refcountcache_total_failed_inserts_stat, // total items unable to insert
+  refcountcache_total_lookups_stat,// total get() calls
+  refcountcache_total_hits_stat,   // total hits
+
+  // Persistence metrics
+  refcountcache_last_sync_time,   // seconds since epoch of last 
successful sync
+  refcountcache_last_total_items, // number of items sync last time
+  refcountcache_last_total_size,  // total size at last sync
+
+  RefCountCache_Stat_Count
+};
+
+struct RefCountCacheItemMeta {
+  uint64_t key;
+  unsigned int size;
+  ink_time_t expiry_time; // expire time as seconds since epoch
+  RefCountCacheItemMeta(uint64_t key, unsigned int size, int expire_time = 
-1) : key(key), size(size), expiry_time(expire_time) {}
+};
+
+// Layer of indirection for the hashmap-- since it needs lots of things 
inside of it
+// We'll also use this as the item header, for persisting objects to disk
+class RefCountCacheHashEntry
+{
+public:
+  Ptr item;
+  LINK(RefCountCacheHashEntry, item_link);
+
+  PriorityQueueEntry *expiry_entry;
+
+  RefCountCacheItemMeta meta;
+  void
+  set(RefCountObj *i, uint64_t key, unsigned int size, int expire_time)
+  {
+this->item = make_ptr(i);
+this->meta = RefCountCacheItemMeta(key, size, expire_time);
+  };
+  // Need a no-argument constructor to use the classAllocator
+  RefCountCacheHashEntry() : expiry_entry(NULL), meta(0, 0){};
+
+  // make these values comparable -- so we can sort them
+  bool
+  operator<(const RefCountCacheHashEntry ) const
+  {
+return this->meta.expiry_time < v2.meta.expiry_time;
+  };
+};
+// Since the hashing values are all fixed size, we can simply use a 
classAllocator to avoid mallocs
+extern ClassAllocator 
refCountCacheHashingValueAllocator;
+extern ClassAllocator 
expiryQueueEntry;
+
+struct RefCountCacheHashing {
+  typedef uint64_t ID;
+  typedef uint64_t const Key;
+  typedef RefCountCacheHashEntry Value;
+  typedef DList(RefCountCacheHashEntry, item_link) ListHead;
+
+  static ID
+  hash(Key key)
+  {
+return key;
+  }
+  static Key
+  key(Value const *value)
+  {
+return value->meta.key;
+  }
+  static bool
+  equal(Key lhs, Key rhs)
+  {
+return lhs == rhs;
+  }
+};
+
+// The RefCountCachePartition is simply a map of key -> Ptr
+// We partition the cache to reduce lock contention
+template  class RefCountCachePartition
+{
+public:
+  

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/360/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4331) Hostdb consistency problems due to MultiCache

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4331:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/653
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/254/ for details.
 



> Hostdb consistency problems due to MultiCache
> -
>
> Key: TS-4331
> URL: https://issues.apache.org/jira/browse/TS-4331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> This ticket is for the correct long term fix to TS-4207
> pulled from a comment, which wraps up the issue
> {quote}
> Leif Hedstrom I have spent a decent amount of time on this while I was OOO on 
> vacation the last couple of weeks. It seems that the root cause of this issue 
> has always existed, and that the addition of always doing hostname storing 
> (https://github.com/apache/trafficserver/commit/0e703e1e) we are just causing 
> the issue to happen all the time.
> To understand the issue I'll give a little background in how hostdb is 
> currently working. Basically hostdb is just a wrapper around this templated 
> struct called MultiCache. MultiCache is "multi" not because it is templated, 
> but because it has two types of storage (static-- blocks and dynamic-- 
> alloc). The static side of the cache can hold N HostDBInfo structs (the 
> results of DNS queries). The dynamic side is used to store the round robin 
> records and various strings associated with the record. The size of this 
> dynamic space is defined as (N x [estimated_heap_bytes_per_entry. The basic 
> problem we are running into is that we are putting too much preassure on the 
> dynamic heap-- such that the heap is getting re-used while people still have 
> references to items in that space.
> So, I've actually been working on re-writing MultiCache to allocate the 
> entire required block at once (so we don't have this problem where the parent 
> exists but not the children), but I'm not certain if we want such a change to 
> go into the 6.x branch (I'm willing to discuss if we want). If we aren't 
> comfortable with such a large change I suggest just accounting for the 
> hostname size in the estimated_heap_bytes_per_entry as a stopgap solution. 
> The maximum allowable size is 253 (so 254 with null terminator), but we could 
> pick a smaller number (~120 or so seems to be more reasonable). Alternatively 
> you can increase the number of records in hostdb (and the size accordingly) 
> to increase the dynamic heap size.
> TLDR; almost done with the long term solution, but I'm not sure if we want to 
> merge that into 6.x-- alternatively we can do a simple workaround in 6.x 
> (https://github.com/apache/trafficserver/pull/553)
> {quote}



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

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Jered Floyd (JIRA)]

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

Jered Floyd commented on TS-4468:
-

I agree; they are related.  Are you comfortable with my proposed solution? If 
so I will rewrite it against HEAD.

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



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

[jira] [Commented] (TS-4593) Extend ip_allow.config to filter destination IPs

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4593:
-

I think it's reasonable. The goal is essentially the same as for inbound 
connections. The syntax only needs to be extended to allow {{dest_ip}} which is 
a simple change. The primary use case of this is to forbid outbound connections 
to non-routable addresses which is quite difficult to do in remap. It would be 
good to put a specific check in to see if there are any outbound rules and skip 
the search/check if that's the case. I think it's a natural extension and I 
don't see a better place to do it, other than requiring a plugin which 
effectively duplicates the IP allow logic.

> Extend ip_allow.config to filter destination IPs
> 
>
> Key: TS-4593
> URL: https://issues.apache.org/jira/browse/TS-4593
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Quinn Lertratanakul
>Assignee: Quinn Lertratanakul
>Priority: Minor
> Fix For: sometime
>
>
> We want to be able to block requests to IP ranges via ip_allow.config . For 
> example, prevent ATS from remapping to origins with rfc1918 ips like 
> 10.0.0.0/8 .



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

[jira] [Updated] (TS-4598) Coverity Null-Check after deref in NetworkUtilisRemote.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4598:
--
Component/s: Network

> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4598
> URL: https://issues.apache.org/jira/browse/TS-4598
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
>  Labels: coverity
> Fix For: 7.0.0
>
>
> {code}
> ** 1237320 Dereference before null check **
> ___
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  ___
> {code}



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

[jira] [Updated] (TS-4598) Coverity Null-Check after deref in NetworkUtilisRemote.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4598:
--
Description: 
{code}
** 1237320 Dereference before null check **
___
660  event_notice = (TSMgmtEvent *)arg;
deref_ptr: Directly dereferencing pointer event_notice.
661  index= (int)event_notice->id;
662  LLQ *func_q; // list of callback functions need to call
663
664  func_q = create_queue();
665  if (!func_q) {

CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking event_notice suggests that it may be null, but 
it has already been dereferenced on all paths leading to the check.
666if (event_notice)
667  TSEventDestroy(event_notice);
668return NULL;
669  }
 ___
{code}

  was:
** 1237320 Dereference before null check **
___
660  event_notice = (TSMgmtEvent *)arg;
deref_ptr: Directly dereferencing pointer event_notice.
661  index= (int)event_notice->id;
662  LLQ *func_q; // list of callback functions need to call
663
664  func_q = create_queue();
665  if (!func_q) {

CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking event_notice suggests that it may be null, but 
it has already been dereferenced on all paths leading to the check.
666if (event_notice)
667  TSEventDestroy(event_notice);
668return NULL;
669  }
 ___



> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4598
> URL: https://issues.apache.org/jira/browse/TS-4598
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>
> {code}
> ** 1237320 Dereference before null check **
> ___
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  ___
> {code}



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

[jira] [Updated] (TS-4598) Coverity Null-Check after deref in NetworkUtilisRemote.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4598:
--
Labels: coverity  (was: )

> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4598
> URL: https://issues.apache.org/jira/browse/TS-4598
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
>  Labels: coverity
> Fix For: 7.0.0
>
>
> {code}
> ** 1237320 Dereference before null check **
> ___
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  ___
> {code}



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

[jira] [Updated] (TS-4598) Coverity Null-Check after deref in NetworkUtilisRemote.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4598:
--
Fix Version/s: 7.0.0

> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4598
> URL: https://issues.apache.org/jira/browse/TS-4598
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>
> {code}
> ** 1237320 Dereference before null check **
> ___
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  ___
> {code}



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

[jira] [Commented] (TS-4542) ASAN error with HTTP/2 priority

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4542:


I added some code to assert when doing a do_io_close() on half closed stream to 
see why it is happening.

> ASAN error with HTTP/2 priority
> ---
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x0250 (pc 
> 0x009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr::operator ProxyMutex*() const 
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*) 
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Commented] (TS-4542) ASAN error with HTTP/2 priority

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4542:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/751
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/359/ for details.
 



> ASAN error with HTTP/2 priority
> ---
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x0250 (pc 
> 0x009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr::operator ProxyMutex*() const 
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*) 
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Commented] (TS-4542) ASAN error with HTTP/2 priority

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4542:


Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/751
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/253/ for details.
 



> ASAN error with HTTP/2 priority
> ---
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x0250 (pc 
> 0x009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr::operator ProxyMutex*() const 
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*) 
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Commented] (TS-4542) ASAN error with HTTP/2 priority

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4542:


Github user bryancall closed the pull request at:

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


> ASAN error with HTTP/2 priority
> ---
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x0250 (pc 
> 0x009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr::operator ProxyMutex*() const 
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*) 
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Assigned] (TS-4598) Coverity Null-Check after deref in NetworkUtilisRemote.cc

[Tyler Stroh (JIRA)]

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

Tyler Stroh reassigned TS-4598:
---

Assignee: Tyler Stroh

> Coverity Null-Check after deref in NetworkUtilisRemote.cc
> -
>
> Key: TS-4598
> URL: https://issues.apache.org/jira/browse/TS-4598
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
>
> ** 1237320 Dereference before null check **
> ___
> 660  event_notice = (TSMgmtEvent *)arg;
>   deref_ptr: Directly dereferencing pointer event_notice.
> 661  index= (int)event_notice->id;
> 662  LLQ *func_q; // list of callback functions need to call
> 663
> 664  func_q = create_queue();
> 665  if (!func_q) {
>   
> CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking event_notice suggests that it may be null, 
> but it has already been dereferenced on all paths leading to the check.
> 666if (event_notice)
> 667  TSEventDestroy(event_notice);
> 668return NULL;
> 669  }
>  ___



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

[jira] [Created] (TS-4598) Coverity Null-Check after deref in NetworkUtilisRemote.cc

[Tyler Stroh (JIRA)]

Tyler Stroh created TS-4598:
---

 Summary: Coverity Null-Check after deref in NetworkUtilisRemote.cc
 Key: TS-4598
 URL: https://issues.apache.org/jira/browse/TS-4598
 Project: Traffic Server
  Issue Type: Bug
Reporter: Tyler Stroh


** 1237320 Dereference before null check **
___
660  event_notice = (TSMgmtEvent *)arg;
deref_ptr: Directly dereferencing pointer event_notice.
661  index= (int)event_notice->id;
662  LLQ *func_q; // list of callback functions need to call
663
664  func_q = create_queue();
665  if (!func_q) {

CID 1237320 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking event_notice suggests that it may be null, but 
it has already been dereferenced on all paths leading to the check.
666if (event_notice)
667  TSEventDestroy(event_notice);
668return NULL;
669  }
 ___




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

[jira] [Commented] (TS-4542) ASAN error with HTTP/2 priority

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4542:


GitHub user bryancall opened a pull request:

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

TS-4542: ASAN error with HTTP/2 priority



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

$ git pull https://github.com/bryancall/trafficserver TS-4542

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

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

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

This closes #751


commit a860b62741230197bdd0cd8110c466588972872a
Author: Bryan Call 
Date:   2016-06-27T21:40:33Z

TS-4542: ASAN error with HTTP/2 priority




> ASAN error with HTTP/2 priority
> ---
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x0250 (pc 
> 0x009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr::operator ProxyMutex*() const 
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*) 
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Issue Comment Deleted] (TS-4593) Extend ip_allow.config to filter destination IPs

[Quinn Lertratanakul (JIRA)]

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

Quinn Lertratanakul updated TS-4593:

Comment: was deleted

(was: Assign to me please)

> Extend ip_allow.config to filter destination IPs
> 
>
> Key: TS-4593
> URL: https://issues.apache.org/jira/browse/TS-4593
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Quinn Lertratanakul
>Assignee: Quinn Lertratanakul
>Priority: Minor
> Fix For: sometime
>
>
> We want to be able to block requests to IP ranges via ip_allow.config . For 
> example, prevent ATS from remapping to origins with rfc1918 ips like 
> 10.0.0.0/8 .



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

[jira] [Comment Edited] (TS-4593) Extend ip_allow.config to filter destination IPs

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-4593 at 6/27/16 9:29 PM:


Hmmm, I'm not positive that this belongs in ip_allow.config. Anyone care to 
comment on this? [~amc] ?

Edit: ip_allow.config is for incoming ACLs only, so adding more to it for 
outbound doesn't seem right.


was (Author: zwoop):
Hmmm, I'm not positive that this belongs in ip_allow.config. Anyone care to 
comment on this? [~amc] ?

> Extend ip_allow.config to filter destination IPs
> 
>
> Key: TS-4593
> URL: https://issues.apache.org/jira/browse/TS-4593
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Quinn Lertratanakul
>Assignee: Quinn Lertratanakul
>Priority: Minor
> Fix For: sometime
>
>
> We want to be able to block requests to IP ranges via ip_allow.config . For 
> example, prevent ATS from remapping to origins with rfc1918 ips like 
> 10.0.0.0/8 .



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

[jira] [Assigned] (TS-4542) ASAN error with HTTP/2 priority

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-4542:
--

Assignee: Bryan Call

> ASAN error with HTTP/2 priority
> ---
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x0250 (pc 
> 0x009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr::operator ProxyMutex*() const 
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*) 
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Commented] (TS-4542) ASAN error with HTTP/2 priority

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4542:


Stream closed is true, but the state is half closed:

{code}
(gdb) p stream_list.head->_state
$4 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
(gdb) p stream_list.head->closed
$5 = true
{code}

> ASAN error with HTTP/2 priority
> ---
>
> Key: TS-4542
> URL: https://issues.apache.org/jira/browse/TS-4542
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.2.0
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> ==29132==ERROR: AddressSanitizer: SEGV on unknown address 0x0250 (pc 
> 0x009a1be5 sp 0x2ae2c2ab0290 bp 0x2ae2c2ab0370 T20)
> #0 0x9a1be4 in Ptr::operator ProxyMutex*() const 
> ../../../trafficserver/lib/ts/Ptr.h:317
> #1 0x9a1be4 in Http2ConnectionState::schedule_stream(Http2Stream*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:974
> #2 0x99eb7f in Http2ConnectionState::restart_streams() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:914
> #3 0x99eb7f in rcv_window_update_frame 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:627
> #4 0x9b27c4 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:823
> #5 0x9906e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0x9906e3 in send_connection_event 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:58
> #7 0x991145 in Http2ClientSession::state_complete_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:430
> #8 0x992ba0 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #9 0x992ba0 in Http2ClientSession::state_start_frame_read(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ClientSession.cc:403
> #10 0xe2be16 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #11 0xe2be16 in read_signal_and_update 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:153
> #12 0xe2be16 in UnixNetVConnection::readSignalAndUpdate(int) 
> ../../../trafficserver/iocore/net/UnixNetVConnection.cc:1036
> #13 0xdc791e in SSLNetVConnection::net_read_io(NetHandler*, EThread*) 
> ../../../trafficserver/iocore/net/SSLNetVConnection.cc:595
> #14 0xde7db0 in NetHandler::mainNetEvent(int, Event*) 
> ../../../trafficserver/iocore/net/UnixNet.cc:513
> #15 0xea2ce9 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #16 0xea2ce9 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #17 0xea2ce9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:275
> #18 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #19 0x2ae2b8e85aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #20 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Updated] (TS-4593) Extend ip_allow.config to filter destination IPs

[Quinn Lertratanakul (JIRA)]

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

Quinn Lertratanakul updated TS-4593:

Assignee: Quinn Lertratanakul

> Extend ip_allow.config to filter destination IPs
> 
>
> Key: TS-4593
> URL: https://issues.apache.org/jira/browse/TS-4593
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Quinn Lertratanakul
>Assignee: Quinn Lertratanakul
>Priority: Minor
> Fix For: sometime
>
>
> We want to be able to block requests to IP ranges via ip_allow.config . For 
> example, prevent ATS from remapping to origins with rfc1918 ips like 
> 10.0.0.0/8 .



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

[jira] [Updated] (TS-4596) proxy.config.http.errors.log_error_pages is undocumented

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4596:
--
Fix Version/s: Docs

> proxy.config.http.errors.log_error_pages is undocumented
> 
>
> Key: TS-4596
> URL: https://issues.apache.org/jira/browse/TS-4596
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Miles Libbey
>Assignee: Jon Sime
>Priority: Minor
> Fix For: Docs
>
>
> The records.config setting 
> proxy.config.http.errors.log_error_pages
> is undocumented.
> Think that this puts any 403/404 etc errors into the error.log file (in 
> addition to the normal access logs).
> proxy/http/HttpTransact.cc:  if (s->http_config_param->errors_log_error_pages 
> && status_code >= HTTP_STATUS_BAD_REQUEST) {
> - its in INT
> - think the default is 1 (eg, true)
> - setting to 0 stops the bad requests from showing in error.log
> - Seems to be reloadable



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

[jira] [Resolved] (TS-4512) Error when building with gcc 6.1.1

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4512.

Resolution: Fixed

> Error when building with gcc 6.1.1
> --
>
> Key: TS-4512
> URL: https://issues.apache.org/jira/browse/TS-4512
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 6.2.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {code}
> In file included from LogObject.cc:40:0:
> ../../lib/ts/TestBox.h:59:1: error: 'bool {anonymous}::TestBox::check(bool, 
> const char*, ...)' defined but not used [-Werror=unused-function]
>  TestBox::check(bool result, char const *fmt, ...)
>  ^~~
> {code}



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

[jira] [Commented] (TS-3371) Should create a global session ticket disable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3371:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/750
  
Also fix the merge conflicts and squash the commits down to one please :)


> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the ATS to set the ssl_ticket_enabled=0 
> for every entry in ssl_multicert.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

[jira] [Assigned] (TS-4596) proxy.config.http.errors.log_error_pages is undocumented

[Miles Libbey (JIRA)]

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

Miles Libbey reassigned TS-4596:


Assignee: Miles Libbey

> proxy.config.http.errors.log_error_pages is undocumented
> 
>
> Key: TS-4596
> URL: https://issues.apache.org/jira/browse/TS-4596
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Miles Libbey
>Assignee: Miles Libbey
>Priority: Minor
>
> The records.config setting 
> proxy.config.http.errors.log_error_pages
> is undocumented.
> Think that this puts any 403/404 etc errors into the error.log file (in 
> addition to the normal access logs).
> proxy/http/HttpTransact.cc:  if (s->http_config_param->errors_log_error_pages 
> && status_code >= HTTP_STATUS_BAD_REQUEST) {
> - its in INT
> - think the default is 1 (eg, true)
> - setting to 0 stops the bad requests from showing in error.log
> - Seems to be reloadable



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

[jira] [Created] (TS-4596) proxy.config.http.errors.log_error_pages is undocumented

[Miles Libbey (JIRA)]

Miles Libbey created TS-4596:


 Summary: proxy.config.http.errors.log_error_pages is undocumented
 Key: TS-4596
 URL: https://issues.apache.org/jira/browse/TS-4596
 Project: Traffic Server
  Issue Type: Bug
  Components: Documentation
Reporter: Miles Libbey


The records.config setting 
proxy.config.http.errors.log_error_pages
is undocumented.

Think that this puts any 403/404 etc errors into the error.log file (in 
addition to the normal access logs).

proxy/http/HttpTransact.cc:  if (s->http_config_param->errors_log_error_pages 
&& status_code >= HTTP_STATUS_BAD_REQUEST) {

- its in INT
- think the default is 1 (eg, true)
- setting to 0 stops the bad requests from showing in error.log
- Seems to be reloadable




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

[jira] [Updated] (TS-4596) proxy.config.http.errors.log_error_pages is undocumented

[Miles Libbey (JIRA)]

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

Miles Libbey updated TS-4596:
-
Priority: Minor  (was: Major)

> proxy.config.http.errors.log_error_pages is undocumented
> 
>
> Key: TS-4596
> URL: https://issues.apache.org/jira/browse/TS-4596
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Miles Libbey
>Priority: Minor
>
> The records.config setting 
> proxy.config.http.errors.log_error_pages
> is undocumented.
> Think that this puts any 403/404 etc errors into the error.log file (in 
> addition to the normal access logs).
> proxy/http/HttpTransact.cc:  if (s->http_config_param->errors_log_error_pages 
> && status_code >= HTTP_STATUS_BAD_REQUEST) {
> - its in INT
> - think the default is 1 (eg, true)
> - setting to 0 stops the bad requests from showing in error.log
> - Seems to be reloadable



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

[jira] [Updated] (TS-4596) proxy.config.http.errors.log_error_pages is undocumented

[Miles Libbey (JIRA)]

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

Miles Libbey updated TS-4596:
-
Assignee: Jon Sime  (was: Miles Libbey)

> proxy.config.http.errors.log_error_pages is undocumented
> 
>
> Key: TS-4596
> URL: https://issues.apache.org/jira/browse/TS-4596
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Miles Libbey
>Assignee: Jon Sime
>Priority: Minor
>
> The records.config setting 
> proxy.config.http.errors.log_error_pages
> is undocumented.
> Think that this puts any 403/404 etc errors into the error.log file (in 
> addition to the normal access logs).
> proxy/http/HttpTransact.cc:  if (s->http_config_param->errors_log_error_pages 
> && status_code >= HTTP_STATUS_BAD_REQUEST) {
> - its in INT
> - think the default is 1 (eg, true)
> - setting to 0 stops the bad requests from showing in error.log
> - Seems to be reloadable



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

[jira] [Commented] (TS-3371) Should create a global session ticket disable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3371:


Github user persiaAziz commented on the issue:

https://github.com/apache/trafficserver/pull/750
  
oops. I will make the default back to 1


> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the ATS to set the ssl_ticket_enabled=0 
> for every entry in ssl_multicert.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

[jira] [Commented] (TS-4459) Force domain names in cert to lower on insert into lookup tree

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4459:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/647
  
Adding @shinrich for review too please.


> Force domain names in cert to lower on insert into lookup tree
> --
>
> Key: TS-4459
> URL: https://issues.apache.org/jira/browse/TS-4459
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Steven Feltner
> Fix For: 7.0.0
>
>
> We have certs from a legacy system that were issued with mixed case domain 
> names.  We are migrating this older product over to ATS and found that domain 
> names need to be lower cased before being inserted in the lookup table.
> I will be submitting  a pull request to resolve this issue.



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

[jira] [Commented] (TS-4482) Add API for custom log field (note)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4482:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/664
  
@jpeach you had some concerns on this concept ?


> Add API for custom log field (note)
> ---
>
> Key: TS-4482
> URL: https://issues.apache.org/jira/browse/TS-4482
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: CPP API, Logging, TS API
>Reporter: yukihisa ishimura
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>
> Although I would like to output the processing result in my plugin to a 
> custom log, with the exception of the header, the field does not exist in 
> order to output freely.



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

Jenkins build is back to normal : debian_8-master » gcc,debian_8,hardening #902

[jenkins]

See 

[jira] [Commented] (TS-4487) Don't reschedule read depend on needs & did not check the change of lock at the return callback with wbe.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4487:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/673
  
@oknet This needs a rebase please. @shinrich Can you review please?


> Don't reschedule read depend on needs & did not check the change of lock at 
> the return callback with wbe.
> -
>
> Key: TS-4487
> URL: https://issues.apache.org/jira/browse/TS-4487
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>
> the code:
> {code}
> int64_t r = vc->load_buffer_and_write(towrite, wattempted, total_written, 
> buf, needs);
> {code}
> At the end of write_to_net_io, 
> {code}
> if (!buf.reader()->read_avail()) {  // should check needs==0
>   write_disable(nh, vc);
>   return;
> }
> if ((needs & EVENTIO_WRITE) == EVENTIO_WRITE) {
>   write_reschedule(nh, vc);
> }
> if ((needs & EVENTIO_READ) == EVENTIO_READ) {
>   read_reschedule(nh, vc);
> }
> return;
> {code}
> another issue in write_to_net_io(): did not check the change of lock at the 
> return callback with wbe.
> {code}
>   if (s->vio.ntodo() <= 0) {
> write_signal_done(VC_EVENT_WRITE_COMPLETE, nh, vc);
> return;
>   } else if (signalled && (wbe_event != vc->write_buffer_empty_event)) {
> // @a signalled means we won't send an event, and the event values 
> differing means we
> // had a write buffer trap and cleared it, so we need to send it now.
> if (write_signal_and_update(wbe_event, vc) != EVENT_CONT)
>   return;
> // > did not check the change of lock at the return callback 
> with wbe.
>   } else if (!signalled) {
> if (write_signal_and_update(VC_EVENT_WRITE_READY, vc) != EVENT_CONT) {
>   return;
> }
> // change of lock... don't look at shared variables!
> if (lock.get_mutex() != s->vio.mutex.get()) {
>   write_reschedule(nh, vc);
>   return;
> }
>   }
> {code}



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

[jira] [Commented] (TS-4587) Revisit TSRemapOSResponse

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-4587:
--

I am also trying to see if I can make changes to server request url in 
TSRemapOSResponse.

> Revisit TSRemapOSResponse
> -
>
> Key: TS-4587
> URL: https://issues.apache.org/jira/browse/TS-4587
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Core, Plugins, Remap API, TS API
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> I looked at {{TSRemapOSResponse}}. This is a remap callback that is invoked 
> synchronously in {{HttpTransact::handle_response_from_server()}} and gets 
> passed a {{ServerState_t}} value.
> Note that there is no TSAPI analog for {{ServerState_t}}.
> The main difference between {{TSRemapOSResponse}} is that connection retries 
> will  be visible to {{TSRemapOSResponse}}. It's not that clear to me whether 
> we have enough API for that to be interesting.
> This ticket is to investigate the utility of {{TSRemapOSResponse}}. If it is 
> really helpful, then we should support it as a proper hook (global and 
> transaction). If it's not then consider removing it.



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

[jira] [Commented] (TS-4156) remove the traffic_sac, stand alone log collation server

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4156:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/593
  
@mingzym Is this going to land? Needs a rebase before you can merge this 
too.


> remove the traffic_sac, stand alone log collation server
> 
>
> Key: TS-4156
> URL: https://issues.apache.org/jira/browse/TS-4156
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Fix For: 7.0.0
>
>
> the stand alone collation server act as a dedicated log server from ATS, this 
> is a dedicated log product back in the Inktomi age, and we don't need it as 
> this functions are build into the traffic_server binary for free distribution.
> it is time to nuke it down.



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

[jira] [Commented] (TS-4042) Add feature to buffer request body before making downstream requests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4042:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/351
  
@bgaff What do you want to do with this? It's been sitting here for quite a 
while.


> Add feature to buffer request body before making downstream requests
> 
>
> Key: TS-4042
> URL: https://issues.apache.org/jira/browse/TS-4042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, CPP API, TS API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>
> We need a way to examine the request body without making a downstream 
> request, this feature has many use cases including:
>   - Ability to buffer the body and ensure a full post is received before 
> committing downstream resources.
>   - Ability to choose an origin based on request body
>   - Ability to do request content filtering such as a WAF might provide 
> before the origin is involved.
> Today you have two options to inspect a request body:
>   1) Transformations: the problem with transformations is that you only start 
> receiving the request bytes after a sink has been established, which in this 
> case is the downstream origin.
>   2) Create an intercept and use fetch apis to then send the downstream 
> request: while this technically works it turns out to be a ton of code and is 
> in general pretty problematic, we actually tried this approach for a while 
> and had nothing but problems with it.
> We feel it would be ideal if we could intercept the body without breaking the 
> normal ATS state flow. There used to exist code (and it's still in the core 
> just #ifdefed out) to drain the request body. I use that code as the basis 
> for this request buffering code. We added APIs to both the C and C++ APIs so 
> that this request buffering can be enabled from a plugin and the plugin can 
> inspect the body as chunks arrive or when it's complete. We've included an 
> example plugin that will error a transaction if a minimum rate of transfer is 
> not maintained.
> I'm confident that this feature will bring plenty of questions / feedback, so 
> let's get that party started.



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

[jira] [Commented] (TS-3607) ats_pagespeed make error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3607:


Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/210
  
We still need an update to this. @oschaaf and @jpeach , assigning to you 
for final reviews, but we should try to land this assuming it seems reasonable 
(once clang-format etc. has been addressed).


> ats_pagespeed make error
> 
>
> Key: TS-3607
> URL: https://issues.apache.org/jira/browse/TS-3607
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Sebastian Pesman
>Assignee: Otto van der Schaaf
> Fix For: sometime
>
>
> When compiling ats_pagespeed from the current master git 
> /tmp/trafficserver/plugins/experimental/ats_pagespeed the make process 
> results in an error.
> The error:
> ats_pagespeed.cc: In function 'void ats_transform_init(TSCont, 
> TransformCtx*)':
> ats_pagespeed.cc:485:109: error: 'INT64_MAX' was not declared in this scope
>ctx->downstream_vio = TSVConnWrite(downstream_conn, contp, 
> TSIOBufferReaderAlloc(ctx->downstream_buffer), INT64_MAX);
>   
>^
> make: *** [ats_pagespeed.so] Error 1



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

[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4506:
---

I think we should consider back porting this to 6.2.1. It's definitely broken 
the way it works today.

> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is no ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Updated] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4506:
--
Backport to Version: 6.2.1

> Last-Modified and Expires headers are removed on 304 responses when they 
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove 
> the Last-Modified header. Reading the RFC, we should only remove the 
> Last-Modified header if there is no ETag header. This is a simple fix, and we 
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}



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

[jira] [Commented] (TS-4594) convert plugins to use records.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4594:
---

Yep, "newbie" doesn't mean that we leave people stranded, once assigned and/or 
work starts, whomever works on this can definitely ask for help on Jira, 
mailing lists and IRC.

> convert plugins to use records.config
> -
>
> Key: TS-4594
> URL: https://issues.apache.org/jira/browse/TS-4594
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Plugins
>Reporter: James Peach
>  Labels: newbie
> Fix For: sometime
>
>
> Since there is API to use {{records.config}}, consider whether plugins should 
> use configuration from there instead of from the plugins. This makes 
> configuration more consistent though you would not get per-plugin instance 
> variables. There are a few a cases where we might be able to remove a 
> plugin-specific config file.
> Note that this doesn't solve per-remap configuration, which is pretty 
> essential.



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

[jira] [Updated] (TS-4594) convert plugins to use records.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4594:
--
Labels: newbie  (was: )

> convert plugins to use records.config
> -
>
> Key: TS-4594
> URL: https://issues.apache.org/jira/browse/TS-4594
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Plugins
>Reporter: James Peach
>  Labels: newbie
> Fix For: sometime
>
>
> Since there is API to use {{records.config}}, consider whether plugins should 
> use configuration from there instead of from the plugins. This makes 
> configuration more consistent though you would not get per-plugin instance 
> variables. There are a few a cases where we might be able to remove a 
> plugin-specific config file.
> Note that this doesn't solve per-remap configuration, which is pretty 
> essential.



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

[jira] [Commented] (TS-4593) Extend ip_allow.config to filter destination IPs

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4593:
---

Hmmm, I'm not positive that this belongs in ip_allow.config. Anyone care to 
comment on this? [~amc] ?

> Extend ip_allow.config to filter destination IPs
> 
>
> Key: TS-4593
> URL: https://issues.apache.org/jira/browse/TS-4593
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Quinn Lertratanakul
>Priority: Minor
> Fix For: sometime
>
>
> We want to be able to block requests to IP ranges via ip_allow.config . For 
> example, prevent ATS from remapping to origins with rfc1918 ips like 
> 10.0.0.0/8 .



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

[jira] [Updated] (TS-4593) Extend ip_allow.config to filter destination IPs

[Leif Hedstrom (JIRA)]

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

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

> Extend ip_allow.config to filter destination IPs
> 
>
> Key: TS-4593
> URL: https://issues.apache.org/jira/browse/TS-4593
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Quinn Lertratanakul
>Priority: Minor
> Fix For: sometime
>
>
> We want to be able to block requests to IP ranges via ip_allow.config . For 
> example, prevent ATS from remapping to origins with rfc1918 ips like 
> 10.0.0.0/8 .



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

[jira] [Updated] (TS-4586) Traffic_server will not start without storage.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4586:
--
Fix Version/s: 7.0.0

> Traffic_server will not start without storage.config
> 
>
> Key: TS-4586
> URL: https://issues.apache.org/jira/browse/TS-4586
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Jason Kenny
>Assignee: Jason Kenny
>Priority: Minor
> Fix For: 7.0.0
>
>
> This file must exist and contain information about the location and size of 
> the cache file. At least one must exist.
> For testing it would be nice to not require this. 



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

[jira] [Updated] (TS-4586) Traffic_server will not start without storage.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4586:
--
Component/s: Configuration

> Traffic_server will not start without storage.config
> 
>
> Key: TS-4586
> URL: https://issues.apache.org/jira/browse/TS-4586
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Jason Kenny
>Assignee: Jason Kenny
>Priority: Minor
> Fix For: 7.0.0
>
>
> This file must exist and contain information about the location and size of 
> the cache file. At least one must exist.
> For testing it would be nice to not require this. 



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

[jira] [Updated] (TS-4586) Traffic_server will not start without storage.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4586:
--
Assignee: Jason Kenny

> Traffic_server will not start without storage.config
> 
>
> Key: TS-4586
> URL: https://issues.apache.org/jira/browse/TS-4586
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Jason Kenny
>Priority: Minor
>
> This file must exist and contain information about the location and size of 
> the cache file. At least one must exist.
> For testing it would be nice to not require this. 



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

[jira] [Updated] (TS-4585) Traffic_server will not start with out remap.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4585:
--
Fix Version/s: 7.0.0

> Traffic_server will not start with out remap.config
> ---
>
> Key: TS-4585
> URL: https://issues.apache.org/jira/browse/TS-4585
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Jason Kenny
>Assignee: Jason Kenny
>Priority: Minor
> Fix For: 7.0.0
>
>
> When starting traffic_server with no configuration files, it was discovered 
> that remap.config has to exist on disk. This file can be empty or contain 
> nothing. However traffic_server will not start if the file is not found.
> From a testing point of view it would be nice to not require an empty file.



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

[jira] [Commented] (TS-2170) stats.config.xml is undocumented

[James Peach (JIRA)]

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

James Peach commented on TS-2170:
-

Agreed.

> stats.config.xml is undocumented
> 
>
> Key: TS-2170
> URL: https://issues.apache.org/jira/browse/TS-2170
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Igor Galić
>
> Save for its DTD: {proxy/config/stats.config.dtd}, {stats.config.xml} is 
> undocumented.
> We should change that.



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

[jira] [Updated] (TS-4585) Traffic_server will not start with out remap.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4585:
--
Component/s: Configuration

> Traffic_server will not start with out remap.config
> ---
>
> Key: TS-4585
> URL: https://issues.apache.org/jira/browse/TS-4585
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Jason Kenny
>Assignee: Jason Kenny
>Priority: Minor
> Fix For: 7.0.0
>
>
> When starting traffic_server with no configuration files, it was discovered 
> that remap.config has to exist on disk. This file can be empty or contain 
> nothing. However traffic_server will not start if the file is not found.
> From a testing point of view it would be nice to not require an empty file.



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

[jira] [Comment Edited] (TS-4585) Traffic_server will not start with out remap.config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-4585 at 6/27/16 8:11 PM:


[~jkenny] You are going to fix this, right ? :)


was (Author: zwoop):
[~jkenny] You are going to fix this, right ? :)

> Traffic_server will not start with out remap.config
> ---
>
> Key: TS-4585
> URL: https://issues.apache.org/jira/browse/TS-4585
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Jason Kenny
>Assignee: Jason Kenny
>Priority: Minor
> Fix For: 7.0.0
>
>
> When starting traffic_server with no configuration files, it was discovered 
> that remap.config has to exist on disk. This file can be empty or contain 
> nothing. However traffic_server will not start if the file is not found.
> From a testing point of view it would be nice to not require an empty file.



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

[jira] [Resolved] (TS-2638) Move "metrics" docs out of traffic_line.en.rst

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-2638.
---
Resolution: Won't Fix
  Assignee: (was: Jon Sime)

Pretty sure this is no longer relevant either.

> Move "metrics" docs out of traffic_line.en.rst
> --
>
> Key: TS-2638
> URL: https://issues.apache.org/jira/browse/TS-2638
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Leif Hedstrom
> Fix For: Docs
>
>
> Seeing that we now have a section started on Metrics documentation (thanks 
> Ron!) we should move this to its own doc page, just like we do for 
> records.config settings.



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

[jira] [Commented] (TS-4594) convert plugins to use records.config

[James Peach (JIRA)]

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

James Peach commented on TS-4594:
-

Yeh the code is straightforward, though it would need some shepherding to keep 
the configuration consistent.

> convert plugins to use records.config
> -
>
> Key: TS-4594
> URL: https://issues.apache.org/jira/browse/TS-4594
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Plugins
>Reporter: James Peach
> Fix For: sometime
>
>
> Since there is API to use {{records.config}}, consider whether plugins should 
> use configuration from there instead of from the plugins. This makes 
> configuration more consistent though you would not get per-plugin instance 
> variables. There are a few a cases where we might be able to remove a 
> plugin-specific config file.
> Note that this doesn't solve per-remap configuration, which is pretty 
> essential.



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

[jira] [Resolved] (TS-2170) stats.config.xml is undocumented

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-2170.
---
   Resolution: Won't Fix
 Assignee: (was: Jon Sime)
Fix Version/s: (was: Docs)

I believe this is no longer relevant. [~jpe...@apache.org] right?

> stats.config.xml is undocumented
> 
>
> Key: TS-2170
> URL: https://issues.apache.org/jira/browse/TS-2170
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Igor Galić
>
> Save for its DTD: {proxy/config/stats.config.dtd}, {stats.config.xml} is 
> undocumented.
> We should change that.



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