[jira] [Work logged] (TS-4733) Cache writes fail when client requests IMS and server replies 200

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4733?focusedWorklogId=26709=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26709
 ]

ASF GitHub Bot logged work on TS-4733:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 03:03
Start Date: 20/Aug/16 03:03
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/871#discussion_r75571646
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -8059,12 +8059,8 @@ HttpTransact::build_response(State *s, HTTPHdr 
*base_response, HTTPHdr *outgoing
 
   // If the response is prohibited from containing a body,
   //  we know the content length is trustable for keep-alive
-  if (is_response_body_precluded(status_code, s->method)) {
-s->hdr_info.trust_response_cl   = true;
-s->hdr_info.response_content_length = 0;
-s->client_info.transfer_encoding= 
HttpTransact::NO_TRANSFER_ENCODING;
-s->server_info.transfer_encoding= 
HttpTransact::NO_TRANSFER_ENCODING;
-  }
+  if (is_response_body_precluded(status_code, s->method))
--- End diff --

Nit pick, but we shouldn't eliminate {} in conditionals, it's just a bad 
habit. Always use the format

if ( ...) {
// Stuff
}

even for single line conditionals.


Issue Time Tracking
---

Worklog Id: (was: 26709)
Time Spent: 1h 10m  (was: 1h)

> Cache writes fail when client requests IMS and server replies 200
> -
>
> Key: TS-4733
> URL: https://issues.apache.org/jira/browse/TS-4733
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> I think this issue happens because of a fix applied in issue TS-3828.
> Imagine a case where the client requests 'IMS' and the cache doesn't have the 
> URL. In that case, we remove the IMS and send the request to origin server. 
> On receiving the response back, we send 304 to client and THEN write to cache.
> However, when we build 304 response to client, we set 
> s->hdr_info.response_content_length = 0.
> Since this call to build_response happens before we setup a tunnel to write 
> the data from 'http_server' to 'cache' we lose this information.
> While setting up this tunnel, we rely on the above field to get the size to 
> write. However, since we have already zeroed it out we don't write anything 
> to the cache.
> I verified that if I use length from the server_response instead of using the 
> pre-computed one, it solves the problem. Though, I am not sure if that should 
> be the solution. I am still looking into the code to see what is the right 
> thing to do.



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

[GitHub] trafficserver pull request #871: TS-4733: Skip modifying response length for...

[zwoop]

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

https://github.com/apache/trafficserver/pull/871#discussion_r75571646
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -8059,12 +8059,8 @@ HttpTransact::build_response(State *s, HTTPHdr 
*base_response, HTTPHdr *outgoing
 
   // If the response is prohibited from containing a body,
   //  we know the content length is trustable for keep-alive
-  if (is_response_body_precluded(status_code, s->method)) {
-s->hdr_info.trust_response_cl   = true;
-s->hdr_info.response_content_length = 0;
-s->client_info.transfer_encoding= 
HttpTransact::NO_TRANSFER_ENCODING;
-s->server_info.transfer_encoding= 
HttpTransact::NO_TRANSFER_ENCODING;
-  }
+  if (is_response_body_precluded(status_code, s->method))
--- End diff --

Nit pick, but we shouldn't eliminate {} in conditionals, it's just a bad 
habit. Always use the format

if ( ...) {
// Stuff
}

even for single line conditionals.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3245) getopt doesn't work correctly when used in plugin chaining

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3245?focusedWorklogId=26707=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26707
 ]

ASF GitHub Bot logged work on TS-3245:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 02:57
Start Date: 20/Aug/16 02:57
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26707)
Time Spent: 40m  (was: 0.5h)

> getopt doesn't work correctly when used in plugin chaining
> --
>
> Key: TS-3245
> URL: https://issues.apache.org/jira/browse/TS-3245
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.1.1
>Reporter: Sudheer Vinukonda
>Assignee: Peter Chou
>Priority: Minor
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When multiple plugins that use getopt are chained, it doesn't work correctly 
> for the subsequent plugins after the first plugin. [~jpe...@apache.org] and 
> [~zwoop] suggested that the getopt globals need to be reset (example, 
> {{optind = opterr = optopt = 0}}) before using it and would be better to do 
> it in the core during plugin loading to keep it simple/transparent from 
> plugin development. 
> Note that, if a plugin itself uses getopt multiple times on different argv's, 
> it would have to reset the globals between them. 



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

[GitHub] trafficserver issue #845: TS-3245: Allow multiple plugins to safely use geto...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3245) getopt doesn't work correctly when used in plugin chaining

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3245?focusedWorklogId=26708=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26708
 ]

ASF GitHub Bot logged work on TS-3245:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 02:57
Start Date: 20/Aug/16 02:57
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26708)
Time Spent: 50m  (was: 40m)

> getopt doesn't work correctly when used in plugin chaining
> --
>
> Key: TS-3245
> URL: https://issues.apache.org/jira/browse/TS-3245
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.1.1
>Reporter: Sudheer Vinukonda
>Assignee: Peter Chou
>Priority: Minor
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> When multiple plugins that use getopt are chained, it doesn't work correctly 
> for the subsequent plugins after the first plugin. [~jpe...@apache.org] and 
> [~zwoop] suggested that the getopt globals need to be reset (example, 
> {{optind = opterr = optopt = 0}}) before using it and would be better to do 
> it in the core during plugin loading to keep it simple/transparent from 
> plugin development. 
> Note that, if a plugin itself uses getopt multiple times on different argv's, 
> it would have to reset the globals between them. 



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

[GitHub] trafficserver issue #845: TS-3245: Allow multiple plugins to safely use geto...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4755) Create a plugin that would count the frequency of headers

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4755?focusedWorklogId=26706=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26706
 ]

ASF GitHub Bot logged work on TS-4755:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 02:55
Start Date: 20/Aug/16 02:55
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
Have to run clang format, (I highly recommend installing the git hook that 
we have, see

https://github.com/apache/trafficserver/blob/master/tools/pre-commit


Also, I think we suggested/agreed on moving this to a new directory, like 
plugins/test ?


Issue Time Tracking
---

Worklog Id: (was: 26706)
Time Spent: 2h 20m  (was: 2h 10m)

> Create a plugin that would count the frequency of headers
> -
>
> Key: TS-4755
> URL: https://issues.apache.org/jira/browse/TS-4755
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Bryan Call
>Assignee: Petar Penkov
> Fix For: 7.2.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Create a plugin that would count the frequency of headers.  Have separate 
> frequency counters for origin and client.



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

[GitHub] trafficserver issue #877: TS-4755: Header Frequency plugin. Initial version

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
Have to run clang format, (I highly recommend installing the git hook that 
we have, see

https://github.com/apache/trafficserver/blob/master/tools/pre-commit


Also, I think we suggested/agreed on moving this to a new directory, like 
plugins/test ?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4755) Create a plugin that would count the frequency of headers

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4755?focusedWorklogId=26705=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26705
 ]

ASF GitHub Bot logged work on TS-4755:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 02:53
Start Date: 20/Aug/16 02:53
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26705)
Time Spent: 2h 10m  (was: 2h)

> Create a plugin that would count the frequency of headers
> -
>
> Key: TS-4755
> URL: https://issues.apache.org/jira/browse/TS-4755
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Bryan Call
>Assignee: Petar Penkov
> Fix For: 7.2.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Create a plugin that would count the frequency of headers.  Have separate 
> frequency counters for origin and client.



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

[GitHub] trafficserver issue #877: TS-4755: Header Frequency plugin. Initial version

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4755) Create a plugin that would count the frequency of headers

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4755?focusedWorklogId=26704=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26704
 ]

ASF GitHub Bot logged work on TS-4755:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 02:48
Start Date: 20/Aug/16 02:48
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26704)
Time Spent: 2h  (was: 1h 50m)

> Create a plugin that would count the frequency of headers
> -
>
> Key: TS-4755
> URL: https://issues.apache.org/jira/browse/TS-4755
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Bryan Call
>Assignee: Petar Penkov
> Fix For: 7.2.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Create a plugin that would count the frequency of headers.  Have separate 
> frequency counters for origin and client.



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

[GitHub] trafficserver issue #877: TS-4755: Header Frequency plugin. Initial version

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-3245) getopt doesn't work correctly when used in plugin chaining

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3245?focusedWorklogId=26703=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26703
 ]

ASF GitHub Bot logged work on TS-3245:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 02:44
Start Date: 20/Aug/16 02:44
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/845
  
[approve ci]


Issue Time Tracking
---

Worklog Id: (was: 26703)
Time Spent: 0.5h  (was: 20m)

> getopt doesn't work correctly when used in plugin chaining
> --
>
> Key: TS-3245
> URL: https://issues.apache.org/jira/browse/TS-3245
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.1.1
>Reporter: Sudheer Vinukonda
>Assignee: Peter Chou
>Priority: Minor
>  Labels: newbie
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When multiple plugins that use getopt are chained, it doesn't work correctly 
> for the subsequent plugins after the first plugin. [~jpe...@apache.org] and 
> [~zwoop] suggested that the getopt globals need to be reset (example, 
> {{optind = opterr = optopt = 0}}) before using it and would be better to do 
> it in the core during plugin loading to keep it simple/transparent from 
> plugin development. 
> Note that, if a plugin itself uses getopt multiple times on different argv's, 
> it would have to reset the globals between them. 



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

[GitHub] trafficserver issue #845: TS-3245: Allow multiple plugins to safely use geto...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/845
  
[approve ci]


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4755) Create a plugin that would count the frequency of headers

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4755?focusedWorklogId=26702=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26702
 ]

ASF GitHub Bot logged work on TS-4755:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 02:42
Start Date: 20/Aug/16 02:42
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
[approve ci]


Issue Time Tracking
---

Worklog Id: (was: 26702)
Time Spent: 1h 50m  (was: 1h 40m)

> Create a plugin that would count the frequency of headers
> -
>
> Key: TS-4755
> URL: https://issues.apache.org/jira/browse/TS-4755
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Bryan Call
>Assignee: Petar Penkov
> Fix For: 7.2.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Create a plugin that would count the frequency of headers.  Have separate 
> frequency counters for origin and client.



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

[GitHub] trafficserver issue #877: TS-4755: Header Frequency plugin. Initial version

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
[approve ci]


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (TS-4717) Http2 stack explosion

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4717.

Resolution: Fixed

> Http2 stack explosion
> -
>
> Key: TS-4717
> URL: https://issues.apache.org/jira/browse/TS-4717
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> We see this periodically with high traffic loads.  ATS crashes with 7000+ 
> frames on the stack.  The bulk of the frames are the following frame 
> sequence.  
> {code}
> #117 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #118 0x0064c05d in Http2ClientSession::state_start_frame_read 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> #119 0x0064b0af in Http2ClientSession::main_event_handler 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at 
> Http2ClientSession.cc:292
> #120 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #121 0x0064c386 in Http2ClientSession::state_complete_frame_read 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:483
> #122 0x0064b0af in Http2ClientSession::main_event_handler 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0) at 
> Http2ClientSession.cc:292
> #123 0x005159c8 in Continuation::handleEvent (this=0x2b0bdd101b90, 
> event=100, data=0x2b0bad0c7cf0)
> at ../iocore/eventsystem/I_Continuation.h:150
> #124 0x0064c05d in Http2ClientSession::state_start_frame_read 
> (this=0x2b0bdd101b90, event=100, edata=0x2b0bad0c7cf0)
> at Http2ClientSession.cc:451
> {code}
> We had cherry picked in the fix for TS-4209 to correctly enforce the 
> concurrent stream limit.  But in the latest crash of this type, it looks like 
> we are pulling small items from cache, so the stream lives and dies on the 
> stack.  The concurrent active connection count never reaches the limit.
> I am going to try to change the 
> state_state_start_frame_read/state_complete_frame_read logic from recursing 
> handlers to a loop.



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

[jira] [Resolved] (TS-4729) clang-analyzer: Dead assignment in Http2Stream

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4729.

Resolution: Fixed

> clang-analyzer: Dead assignment in Http2Stream
> --
>
> Key: TS-4729
> URL: https://issues.apache.org/jira/browse/TS-4729
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> {noformat}
> Bug Summary
> File: Http2Stream.cc
> Location: line 508, column 9
> Description:  Value stored to 'is_done' is never read
> {noformat}



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

[jira] [Resolved] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4749.

Resolution: Fixed

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



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

[jira] [Work logged] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4749?focusedWorklogId=26701=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26701
 ]

ASF GitHub Bot logged work on TS-4749:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:21
Start Date: 20/Aug/16 00:21
Worklog Time Spent: 10m 
  Work Description: Github user shinrich closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 26701)
Time Spent: 2h 10m  (was: 2h)

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



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

[GitHub] trafficserver pull request #856: TS-4749: generate warning message when orig...

[shinrich]

Github user shinrich closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4750.

Resolution: Fixed

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



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

[GitHub] trafficserver issue #856: TS-4749: generate warning message when origin_max_...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4749?focusedWorklogId=26700=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26700
 ]

ASF GitHub Bot logged work on TS-4749:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:19
Start Date: 20/Aug/16 00:19
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26700)
Time Spent: 2h  (was: 1h 50m)

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



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

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

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26699=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26699
 ]

ASF GitHub Bot logged work on TS-4601:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:17
Start Date: 20/Aug/16 00:17
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26699)
Time Spent: 1h  (was: 50m)

> 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
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> 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)

[GitHub] trafficserver issue #762: TS-4601: Connection error from origin_max_connecti...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26698=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26698
 ]

ASF GitHub Bot logged work on TS-4601:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:15
Start Date: 20/Aug/16 00:15
Worklog Time Spent: 10m 
  Work Description: Github user shinrich closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 26698)
Time Spent: 50m  (was: 40m)

> 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
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> 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)

[GitHub] trafficserver pull request #762: TS-4601: Connection error from origin_max_c...

[shinrich]

Github user shinrich closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #762: TS-4601: Connection error from origin_max_connecti...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4749?focusedWorklogId=26696=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26696
 ]

ASF GitHub Bot logged work on TS-4749:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:13
Start Date: 20/Aug/16 00:13
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26696)
Time Spent: 1h 50m  (was: 1h 40m)

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



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

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

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26697=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26697
 ]

ASF GitHub Bot logged work on TS-4601:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:14
Start Date: 20/Aug/16 00:14
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26697)
Time Spent: 40m  (was: 0.5h)

> 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
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> 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)

[GitHub] trafficserver issue #856: TS-4749: generate warning message when origin_max_...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4475) Crash in Log-Collation client after using inactivity-cop.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4475?focusedWorklogId=26695=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26695
 ]

ASF GitHub Bot logged work on TS-4475:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:09
Start Date: 20/Aug/16 00:09
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/831
  
Looks good to me.  I assume you set the very high timeout because the net 
connections for the log collation client aren't really like normal connections 
so the likely lower timeouts shouldn't apply.  Is that correct?


Issue Time Tracking
---

Worklog Id: (was: 26695)
Time Spent: 1.5h  (was: 1h 20m)

> Crash in Log-Collation client after using inactivity-cop.
> -
>
> Key: TS-4475
> URL: https://issues.apache.org/jira/browse/TS-4475
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 6.1.1
>Reporter: Peter Chou
> Fix For: sometime
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Background: We recently tried making use of inactivity-cop by setting it to 
> 300s instead of the default one-day setting. This was to address an issue 
> where, under heavy load, ATS would become un-responsive to client requests, 
> and the condition would persist after traffic was stopped with the active 
> queue saying 0 connections but 'netstat -na' showing a bunch of established 
> connections (up to the throttle limit approximately).
> Inactivity cop seemed to help ATS handle this situation, but we have since 
> experienced a couple of core dumps over the last four day period. It seems 
> occasionally the Log Collation Client State Machine will have event value 105 
> or VC_EVENT_INACTIVITY_TIMEOUT, but when it reaches read_signal_and_update() 
> it tries to call the continuation handler which down the line does not know 
> about this event thus causing core dump !"unexpcted state" [sic].
> Here is the back-trace --
> (gdb) bt
> #0  0x2b67cd5405f7 in raise () from /lib64/libc.so.6
> #1  0x2b67cd541e28 in abort () from /lib64/libc.so.6
> #2  0x2b67cb032921 in ink_die_die_die () at ink_error.cc:43
> #3  0x2b67cb0329da in ink_fatal_va (fmt=0x2b67cb0442dc "%s:%d: failed 
> assert `%s`", ap=0x7ffc690e7ba8) at ink_error.cc:65
> #4  0x2b67cb032a79 in ink_fatal (message_format=0x2b67cb0442dc "%s:%d: 
> failed assert `%s`") at ink_error.cc:73
> #5  0x2b67cb0305a6 in _ink_assert (expression=0x7fb422 "!\"unexpcted 
> state\"", file=0x7fb35b "LogCollationClientSM.cc",
> line=445) at ink_assert.cc:37
> #6  0x0069c86b in LogCollationClientSM::client_idle 
> (this=0x2b681400bb00, event=105) at LogCollationClientSM.cc:445
> #7  0x0069b427 in LogCollationClientSM::client_handler 
> (this=0x2b681400bb00, event=105, data=0x2b680c017020)
> at LogCollationClientSM.cc:119
> #8  0x00502cc6 in Continuation::handleEvent (this=0x2b681400bb00, 
> event=105, data=0x2b680c017020)
> at ../iocore/eventsystem/I_Continuation.h:153
> #9  0x00783d40 in read_signal_and_update (event=105, 
> vc=0x2b680c016f00) at UnixNetVConnection.cc:150
> #10 0x00787a22 in UnixNetVConnection::mainEvent (this=0x2b680c016f00, 
> event=1, e=0x127ad60) at UnixNetVConnection.cc:1188
> #11 0x00502cc6 in Continuation::handleEvent (this=0x2b680c016f00, 
> event=1, data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x0077d943 in InactivityCop::check_inactivity (this=0x1209a00, 
> event=2, e=0x127ad60) at UnixNet.cc:102
> #13 0x00502cc6 in Continuation::handleEvent (this=0x1209a00, event=2, 
> data=0x127ad60)
> at ../iocore/eventsystem/I_Continuation.h:153
> #14 0x007a5df6 in EThread::process_event (this=0x2b67cf7bb010, 
> e=0x127ad60, calling_code=2) at UnixEThread.cc:128
> #15 0x007a61f5 in EThread::execute (this=0x2b67cf7bb010) at 
> UnixEThread.cc:207
> #16 0x00534430 in main (argv=0x7ffc690e82e8) at Main.cc:1918
> I believe it takes a wrong turn here --
> #9  0x00783d40 in read_signal_and_update (event=105, 
> vc=0x2b680c016f00) at UnixNetVConnection.cc:150
> 150 vc->read.vio._cont->handleEvent(event, >read.vio);
> (gdb) list
> 145 static inline int
> 146 read_signal_and_update(int event, UnixNetVConnection *vc)
> 147 {
> 148   vc->recursion++;
> 149   if (vc->read.vio._cont) {
> 150 vc->read.vio._cont->handleEvent(event, >read.vio);
> 151   } else {
> 152 switch (event) {
> 153 case VC_EVENT_EOS:
> 154 case VC_EVENT_ERROR:
> (gdb) list
> 155 case VC_EVENT_ACTIVE_TIMEOUT:
> 156 case VC_EVENT_INACTIVITY_TIMEOUT:
> 157   

[GitHub] trafficserver issue #831: TS-4475: Log Collation Client SM, added VC_EVENT_I...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/831
  
Looks good to me.  I assume you set the very high timeout because the net 
connections for the log collation client aren't really like normal connections 
so the likely lower timeouts shouldn't apply.  Is that correct?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26693=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26693
 ]

ASF GitHub Bot logged work on TS-4601:
--

Author: ASF GitHub Bot
Created on: 20/Aug/16 00:02
Start Date: 20/Aug/16 00:02
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/762
  
Addressed @bryancall 's comment via squashed commit.


Issue Time Tracking
---

Worklog Id: (was: 26693)
Time Spent: 0.5h  (was: 20m)

> 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
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> 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)

Jenkins build is back to normal : clang-analyzer #2551

[jenkins]

See 

[GitHub] trafficserver issue #762: TS-4601: Connection error from origin_max_connecti...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/762
  
Addressed @bryancall 's comment via squashed commit.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4749?focusedWorklogId=26692=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26692
 ]

ASF GitHub Bot logged work on TS-4749:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:53
Start Date: 19/Aug/16 23:53
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26692)
Time Spent: 1h 40m  (was: 1.5h)

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



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

[GitHub] trafficserver issue #856: TS-4749: generate warning message when origin_max_...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #856: TS-4749: generate warning message when origin_max_...

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4749?focusedWorklogId=26691=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26691
 ]

ASF GitHub Bot logged work on TS-4749:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:48
Start Date: 19/Aug/16 23:48
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26691)
Time Spent: 1.5h  (was: 1h 20m)

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



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

[jira] [Work logged] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4749?focusedWorklogId=26690=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26690
 ]

ASF GitHub Bot logged work on TS-4749:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:47
Start Date: 19/Aug/16 23:47
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/856
  
Addressed @bryancall 's comment via another squashed commit.


Issue Time Tracking
---

Worklog Id: (was: 26690)
Time Spent: 1h 20m  (was: 1h 10m)

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



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

[GitHub] trafficserver issue #856: TS-4749: generate warning message when origin_max_...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/856
  
Addressed @bryancall 's comment via another squashed commit.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Failed: trafficserver (latest)

[Read the Docs]

Build Failed for trafficserver (latest)



You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4317632/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[GitHub] trafficserver pull request #849: TS-4729: Fix dead assignment.

[shinrich]

Github user shinrich closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4362) Remove cacheurl plugin

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4362?focusedWorklogId=26688=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26688
 ]

ASF GitHub Bot logged work on TS-4362:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:37
Start Date: 19/Aug/16 23:37
Worklog Time Spent: 10m 
  Work Description: Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/882
  
@zwoop, announcement sent to users@


Issue Time Tracking
---

Worklog Id: (was: 26688)
Time Spent: 50m  (was: 40m)

> Remove cacheurl plugin
> --
>
> Key: TS-4362
> URL: https://issues.apache.org/jira/browse/TS-4362
> Project: Traffic Server
>  Issue Type: Task
>  Components: Plugins
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Deprecate cacheurl plugin in favor of cachekey plugin



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

[GitHub] trafficserver issue #882: TS-4362 Removed cacheurl plugin

[gtenev]

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/882
  
@zwoop, announcement sent to users@


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #761: TS-4332: proxy.config.net.connections_throttle sho...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/761
  
@bcall so the idea is that we will remove the existing 
proxy.config.net.connections_throttle setting in the 7.0 time frame?  This PR 
is changing the existing throttle setting to allow for connections to be closed 
immediately when over limit.  As it is implemented currently, the connection 
attempts are just retried later making this setting pretty useless when under 
load.  

Independent of the proxy.config.net.connections_throttle setting, having a 
no-throttle port setting would still be useful in the LRU scenario. There may 
be intra-pod communication channels you don't want to shutdown.  What are your 
thoughts there?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4332) proxy.config.net.connections_throttle should allow for immediate error return when accepts reach throttle limit

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4332?focusedWorklogId=26687=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26687
 ]

ASF GitHub Bot logged work on TS-4332:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:34
Start Date: 19/Aug/16 23:34
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/761
  
@bcall so the idea is that we will remove the existing 
proxy.config.net.connections_throttle setting in the 7.0 time frame?  This PR 
is changing the existing throttle setting to allow for connections to be closed 
immediately when over limit.  As it is implemented currently, the connection 
attempts are just retried later making this setting pretty useless when under 
load.  

Independent of the proxy.config.net.connections_throttle setting, having a 
no-throttle port setting would still be useful in the LRU scenario. There may 
be intra-pod communication channels you don't want to shutdown.  What are your 
thoughts there?


Issue Time Tracking
---

Worklog Id: (was: 26687)
Time Spent: 40m  (was: 0.5h)

> proxy.config.net.connections_throttle should allow for immediate error return 
> when accepts reach throttle limit
> ---
>
> Key: TS-4332
> URL: https://issues.apache.org/jira/browse/TS-4332
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: sometime
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When the throttling kicks in future connections to origins will cause a 502 
> to be returned to the user agent.
> But when an accept happens during the throttling period, a message is only 
> sent if the unix_netProcessor.throttle_error_message member variable is set.  
> In the current code, this member variable is never set.  If the variable is 
> not set, the logic blocks for 100ms and tries again.
> This spinning causes the ATS process to waste resources.  It would be better 
> to immediately turn around and send an error response (probably 503 instead 
> of 502).
> I tested a build that hard coded an error message and it seemed to recover 
> much better.
> I propose adding some config variables to control the throttling behavior.
> proxy.config.connections_throttle.error_code  - HTTP response code to return 
> (or just hard code this to 503)
> proxy.config.connections_throttle.error_page - Reference to an error page to 
> return.
> If both are unset, the existing delaying logic is used.  If either is set, 
> either a error header or a header and body are returned immediately.



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

[jira] [Work logged] (TS-4729) clang-analyzer: Dead assignment in Http2Stream

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4729?focusedWorklogId=26686=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26686
 ]

ASF GitHub Bot logged work on TS-4729:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:34
Start Date: 19/Aug/16 23:34
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26686)
Time Spent: 3h 10m  (was: 3h)

> clang-analyzer: Dead assignment in Http2Stream
> --
>
> Key: TS-4729
> URL: https://issues.apache.org/jira/browse/TS-4729
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Bug Summary
> File: Http2Stream.cc
> Location: line 508, column 9
> Description:  Value stored to 'is_done' is never read
> {noformat}



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

[GitHub] trafficserver issue #849: TS-4729: Fix dead assignment.

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4601?focusedWorklogId=26684=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26684
 ]

ASF GitHub Bot logged work on TS-4601:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:28
Start Date: 19/Aug/16 23:28
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/762#discussion_r75564926
  
--- Diff: proxy/http/HttpConfig.cc ---
@@ -809,6 +809,8 @@ register_stat_callbacks()
  (int)https_incoming_requests_stat, 
RecRawStatSyncCount);
   RecRegisterRawStat(http_rsb, RECT_PROCESS, 
"proxy.process.https.total_client_connections", RECD_COUNTER, RECP_PERSISTENT,
  (int)https_total_client_connections_stat, 
RecRawStatSyncCount);
+  RecRegisterRawStat(http_rsb, RECT_PROCESS, 
"proxy.process.http.origin_connections_throttled", RECD_COUNTER, 
RECP_PERSISTENT,
--- End diff --

Actually the throttling limit affects both incoming and outgoing 
connections.  I could create origin_connections_throttled_in and 
origin_connections_throttled out.


Issue Time Tracking
---

Worklog Id: (was: 26684)
Time Spent: 20m  (was: 10m)

> 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
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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] [Created] (TS-4768) Remove log collation feature

[Bryan Call (JIRA)]

Bryan Call created TS-4768:
--

 Summary: Remove log collation feature
 Key: TS-4768
 URL: https://issues.apache.org/jira/browse/TS-4768
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: Bryan Call


An alternative solution to log collation is to log to a pipe and have an 
external process take care of log collation.  Here is the documentation for log 
collation:
https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring/logging/log-collation.en.html
 

The proposal is to remove the configurations options, statistics, and code for 
log collation.



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

[jira] [Updated] (TS-4768) Remove log collation feature

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4768:
---
Fix Version/s: 7.0.0

> Remove log collation feature
> 
>
> Key: TS-4768
> URL: https://issues.apache.org/jira/browse/TS-4768
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> An alternative solution to log collation is to log to a pipe and have an 
> external process take care of log collation.  Here is the documentation for 
> log collation:
> https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring/logging/log-collation.en.html
>  
> The proposal is to remove the configurations options, statistics, and code 
> for log collation.



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

[jira] [Assigned] (TS-4768) Remove log collation feature

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-4768:
--

Assignee: Bryan Call

> Remove log collation feature
> 
>
> Key: TS-4768
> URL: https://issues.apache.org/jira/browse/TS-4768
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> An alternative solution to log collation is to log to a pipe and have an 
> external process take care of log collation.  Here is the documentation for 
> log collation:
> https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring/logging/log-collation.en.html
>  
> The proposal is to remove the configurations options, statistics, and code 
> for log collation.



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

[jira] [Work logged] (TS-4729) clang-analyzer: Dead assignment in Http2Stream

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4729?focusedWorklogId=26685=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26685
 ]

ASF GitHub Bot logged work on TS-4729:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:28
Start Date: 19/Aug/16 23:28
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26685)
Time Spent: 3h  (was: 2h 50m)

> clang-analyzer: Dead assignment in Http2Stream
> --
>
> Key: TS-4729
> URL: https://issues.apache.org/jira/browse/TS-4729
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> {noformat}
> Bug Summary
> File: Http2Stream.cc
> Location: line 508, column 9
> Description:  Value stored to 'is_done' is never read
> {noformat}



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

[GitHub] trafficserver issue #849: TS-4729: Fix dead assignment.

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #762: TS-4601: Connection error from origin_max_c...

[shinrich]

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

https://github.com/apache/trafficserver/pull/762#discussion_r75564926
  
--- Diff: proxy/http/HttpConfig.cc ---
@@ -809,6 +809,8 @@ register_stat_callbacks()
  (int)https_incoming_requests_stat, 
RecRawStatSyncCount);
   RecRegisterRawStat(http_rsb, RECT_PROCESS, 
"proxy.process.https.total_client_connections", RECD_COUNTER, RECP_PERSISTENT,
  (int)https_total_client_connections_stat, 
RecRawStatSyncCount);
+  RecRegisterRawStat(http_rsb, RECT_PROCESS, 
"proxy.process.http.origin_connections_throttled", RECD_COUNTER, 
RECP_PERSISTENT,
--- End diff --

Actually the throttling limit affects both incoming and outgoing 
connections.  I could create origin_connections_throttled_in and 
origin_connections_throttled out.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (TS-4767) Remove build option for Linux AIO

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-4767:
--

Assignee: Bryan Call

> Remove build option for Linux AIO
> -
>
> Key: TS-4767
> URL: https://issues.apache.org/jira/browse/TS-4767
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> There are performance and size limits when building with Linux AIO.  The 
> proposal is to remove build options for LInux AIO until is becomes more 
> stable.



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

[jira] [Work logged] (TS-2237) URL encoding wrong in squid.blog

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2237?focusedWorklogId=26683=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26683
 ]

ASF GitHub Bot logged work on TS-2237:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:26
Start Date: 19/Aug/16 23:26
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
Ok just to be clear.  The current PR will change the behavior of 
TSStringPercentEncode.  Strings that included "%20" would have been double 
encoded and with this change they will not.

@maskit are you ok with the change if we make a new version of 
LogUtils::escapify_url that does not include this change that is used by 
TSStringPercentEncode?  So the change only affects core logic?


Issue Time Tracking
---

Worklog Id: (was: 26683)
Time Spent: 3h  (was: 2h 50m)

> URL encoding wrong in squid.blog
> 
>
> Key: TS-2237
> URL: https://issues.apache.org/jira/browse/TS-2237
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: David Carlin
>Assignee: Sudheer Vinukonda
>Priority: Minor
>  Labels: yahoo
> Fix For: 7.0.0
>
> Attachments: TS-2237.diff
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> I was replaying URLs captured from squid.blog and I noticed I was getting 
> 404's for some of them when squid.blog showed a 200 for that request.  Turns 
> out there is an issue with URL encoding.  For example:
> Requesting file 'duck%20sports%20authority.gif' via curl will put this in the 
> logs:
> duck%2520sports%2520authority.gif
> The % from %20 (space) in the request is being converted to %25 resulting in 
> %2520
> I tested both the % and % log fields - same thing happens.  I 
> tested on ATS 3.2.0 and 3.3.5



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

[jira] [Updated] (TS-4767) Remove build option for Linux AIO

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4767:
---
Fix Version/s: 7.0.0

> Remove build option for Linux AIO
> -
>
> Key: TS-4767
> URL: https://issues.apache.org/jira/browse/TS-4767
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 7.0.0
>
>
> There are performance and size limits when building with Linux AIO.  The 
> proposal is to remove build options for LInux AIO until is becomes more 
> stable.



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

[jira] [Created] (TS-4767) Remove build option for Linux AIO

[Bryan Call (JIRA)]

Bryan Call created TS-4767:
--

 Summary: Remove build option for Linux AIO
 Key: TS-4767
 URL: https://issues.apache.org/jira/browse/TS-4767
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: Bryan Call


There are performance and size limits when building with Linux AIO.  The 
proposal is to remove build options for LInux AIO until is becomes more stable.



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

[GitHub] trafficserver issue #866: TS-2237: Fix double encoding of URLs in squid logs...

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
Ok just to be clear.  The current PR will change the behavior of 
TSStringPercentEncode.  Strings that included "%20" would have been double 
encoded and with this change they will not.

@maskit are you ok with the change if we make a new version of 
LogUtils::escapify_url that does not include this change that is used by 
TSStringPercentEncode?  So the change only affects core logic?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4729) clang-analyzer: Dead assignment in Http2Stream

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4729?focusedWorklogId=26682=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26682
 ]

ASF GitHub Bot logged work on TS-4729:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 23:21
Start Date: 19/Aug/16 23:21
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/849
  
Addressed @bryancall 's concerns with a new commit (squashed).


Issue Time Tracking
---

Worklog Id: (was: 26682)
Time Spent: 2h 50m  (was: 2h 40m)

> clang-analyzer: Dead assignment in Http2Stream
> --
>
> Key: TS-4729
> URL: https://issues.apache.org/jira/browse/TS-4729
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> {noformat}
> Bug Summary
> File: Http2Stream.cc
> Location: line 508, column 9
> Description:  Value stored to 'is_done' is never read
> {noformat}



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

[GitHub] trafficserver issue #849: TS-4729: Fix dead assignment.

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/849
  
Addressed @bryancall 's concerns with a new commit (squashed).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?focusedWorklogId=26681=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26681
 ]

ASF GitHub Bot logged work on TS-4750:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:59
Start Date: 19/Aug/16 22:59
Worklog Time Spent: 10m 
  Work Description: Github user shinrich closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 26681)
Time Spent: 2h  (was: 1h 50m)

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



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

[GitHub] trafficserver pull request #863: TS-4750: Fix Connection Leak warnings.

[shinrich]

Github user shinrich closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?focusedWorklogId=26680=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26680
 ]

ASF GitHub Bot logged work on TS-4750:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:58
Start Date: 19/Aug/16 22:58
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/863
  
@oknet  True there are many variants of the get_remote_*   get_remote_ip 
should be going away since it is IPv4 (looks like only two references remain).  
 For get_remote_endpoint and get_remote_addr really they are two versions 
returning different data types.  Some places it is more convenient to have an 
Endpoint class other places we need a struct sockaddr.  Since one calls the 
other at least we don't have parallel implementations.


Issue Time Tracking
---

Worklog Id: (was: 26680)
Time Spent: 1h 50m  (was: 1h 40m)

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



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

[GitHub] trafficserver issue #863: TS-4750: Fix Connection Leak warnings.

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/863
  
@oknet  True there are many variants of the get_remote_*   get_remote_ip 
should be going away since it is IPv4 (looks like only two references remain).  
 For get_remote_endpoint and get_remote_addr really they are two versions 
returning different data types.  Some places it is more convenient to have an 
Endpoint class other places we need a struct sockaddr.  Since one calls the 
other at least we don't have parallel implementations.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4362) Remove cacheurl plugin

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4362?focusedWorklogId=26679=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26679
 ]

ASF GitHub Bot logged work on TS-4362:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:39
Start Date: 19/Aug/16 22:39
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26679)
Time Spent: 40m  (was: 0.5h)

> Remove cacheurl plugin
> --
>
> Key: TS-4362
> URL: https://issues.apache.org/jira/browse/TS-4362
> Project: Traffic Server
>  Issue Type: Task
>  Components: Plugins
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Deprecate cacheurl plugin in favor of cachekey plugin



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

[GitHub] trafficserver issue #882: TS-4362 Removed cacheurl plugin

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?focusedWorklogId=26678=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26678
 ]

ASF GitHub Bot logged work on TS-4750:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:35
Start Date: 19/Aug/16 22:35
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/863#discussion_r75561036
  
--- Diff: iocore/net/I_NetVConnection.h ---
@@ -482,6 +482,7 @@ class NetVConnection : public VConnection
 
   /** Returns remote sockaddr storage. */
   sockaddr const *get_remote_addr();
+  IpEndpoint const _remote_endpoint();
--- End diff --

Cannot make it const because internally these functions cache the remote 
address and set a bit indicating whether the value is already cache or not.


Issue Time Tracking
---

Worklog Id: (was: 26678)
Time Spent: 1h 40m  (was: 1.5h)

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



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

[GitHub] trafficserver pull request #863: TS-4750: Fix Connection Leak warnings.

[shinrich]

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

https://github.com/apache/trafficserver/pull/863#discussion_r75561036
  
--- Diff: iocore/net/I_NetVConnection.h ---
@@ -482,6 +482,7 @@ class NetVConnection : public VConnection
 
   /** Returns remote sockaddr storage. */
   sockaddr const *get_remote_addr();
+  IpEndpoint const _remote_endpoint();
--- End diff --

Cannot make it const because internally these functions cache the remote 
address and set a bit indicating whether the value is already cache or not.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #882: TS-4362 Removed cacheurl plugin

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4362) Remove cacheurl plugin

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4362?focusedWorklogId=26677=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26677
 ]

ASF GitHub Bot logged work on TS-4362:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:33
Start Date: 19/Aug/16 22:33
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26677)
Time Spent: 0.5h  (was: 20m)

> Remove cacheurl plugin
> --
>
> Key: TS-4362
> URL: https://issues.apache.org/jira/browse/TS-4362
> Project: Traffic Server
>  Issue Type: Task
>  Components: Plugins
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Deprecate cacheurl plugin in favor of cachekey plugin



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

[jira] [Resolved] (TS-4766) HTTP/2 packet corruption introduced by TS-4717 fix

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4766.

Resolution: Fixed

> HTTP/2 packet corruption introduced by TS-4717 fix
> --
>
> Key: TS-4766
> URL: https://issues.apache.org/jira/browse/TS-4766
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We observed problems with large uploads over HTTP/2 via Firefox.  Tracked it 
> down to ATS sending a GOAWAY frame early because the frame appeared to be 
> corrupted.  The problem was introduced in the restructuring in TS-4717 to get 
> rid of the unbounded recursion.  The logic will return with one of two 
> handlers set.  One to deal with the case of starting to read a fresh frame 
> and another to deal with the case of finishing reading a partially read 
> frame.  There is a path where we finish reading a frame but don't reset the 
> handler to the new frame case.  When the next data arrives the wrong handler 
> starts reading it resulting in ATS thinking it has received a malformed frame.



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

Build failed in Jenkins: clang-analyzer #2550

[jenkins]

See 

Changes:

[shinrich] TS-4766:  HTTP/2 frame corruption fix.

[solidwallofcode] TS-4452: Change active copy of cache_open_write_fail to be 
MgmtByte

--
[...truncated 5018 lines...]
reading sources... [ 68%] developer-guide/api/functions/TSVConnWrite.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWriteVIOGet.en
reading sources... [ 68%] developer-guide/api/functions/TSVIOBufferGet.en
reading sources... [ 68%] developer-guide/api/functions/TSVIOContGet.en
reading sources... [ 68%] developer-guide/api/functions/TSVIOMutexGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 70%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSSslVConnOp.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 79%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 80%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] 

[jira] [Work logged] (TS-2987) TS API to identify if the client connection is via HTTP/2

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2987?focusedWorklogId=26676=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26676
 ]

ASF GitHub Bot logged work on TS-2987:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:30
Start Date: 19/Aug/16 22:30
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/865
  
I didn't send one out.  I'm resurrecting this one.  So if a review was sent 
around it was quite some time back.  I'll send out a new one.


Issue Time Tracking
---

Worklog Id: (was: 26676)
Time Spent: 50m  (was: 40m)

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



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

[GitHub] trafficserver issue #865: TS-2987: Add new TS API TSHttpTxnPluginTagGet

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/865
  
I didn't send one out.  I'm resurrecting this one.  So if a review was sent 
around it was quite some time back.  I'll send out a new one.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4362) Remove cacheurl plugin

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4362?focusedWorklogId=26675=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26675
 ]

ASF GitHub Bot logged work on TS-4362:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:22
Start Date: 19/Aug/16 22:22
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/882
  
Did we send an email to users@ making this announcement already? If not, 
please do so, and specify that we've moved this functionality to the cachekey 
plugin. [approve ci]


Issue Time Tracking
---

Worklog Id: (was: 26675)
Time Spent: 20m  (was: 10m)

> Remove cacheurl plugin
> --
>
> Key: TS-4362
> URL: https://issues.apache.org/jira/browse/TS-4362
> Project: Traffic Server
>  Issue Type: Task
>  Components: Plugins
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Deprecate cacheurl plugin in favor of cachekey plugin



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

[GitHub] trafficserver issue #882: TS-4362 Removed cacheurl plugin

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/882
  
Did we send an email to users@ making this announcement already? If not, 
please do so, and specify that we've moved this functionality to the cachekey 
plugin. [approve ci]


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4766) HTTP/2 packet corruption introduced by TS-4717 fix

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4766?focusedWorklogId=26674=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26674
 ]

ASF GitHub Bot logged work on TS-4766:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 22:01
Start Date: 19/Aug/16 22:01
Worklog Time Spent: 10m 
  Work Description: Github user shinrich closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 26674)
Time Spent: 50m  (was: 40m)

> HTTP/2 packet corruption introduced by TS-4717 fix
> --
>
> Key: TS-4766
> URL: https://issues.apache.org/jira/browse/TS-4766
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We observed problems with large uploads over HTTP/2 via Firefox.  Tracked it 
> down to ATS sending a GOAWAY frame early because the frame appeared to be 
> corrupted.  The problem was introduced in the restructuring in TS-4717 to get 
> rid of the unbounded recursion.  The logic will return with one of two 
> handlers set.  One to deal with the case of starting to read a fresh frame 
> and another to deal with the case of finishing reading a partially read 
> frame.  There is a path where we finish reading a frame but don't reset the 
> handler to the new frame case.  When the next data arrives the wrong handler 
> starts reading it resulting in ATS thinking it has received a malformed frame.



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

[GitHub] trafficserver pull request #881: TS-4766: HTTP/2 frame corruption fix.

[shinrich]

Github user shinrich closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4391) Duplicated parent origin retry types

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4391?focusedWorklogId=26673=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26673
 ]

ASF GitHub Bot logged work on TS-4391:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 21:29
Start Date: 19/Aug/16 21:29
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26673)
Time Spent: 0.5h  (was: 20m)

> Duplicated parent origin retry types
> 
>
> Key: TS-4391
> URL: https://issues.apache.org/jira/browse/TS-4391
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We have:
> {code}
> enum ParentRetry_t {
>   PARENT_RETRY_NONE = 0,
>   PARENT_RETRY_SIMPLE = 1,
>   PARENT_RETRY_UNAVAILABLE_SERVER = 2,
>   // both simple and unavailable server retry
>   PARENT_RETRY_BOTH = 3
> };
> {code}
> and
> {code}
>   enum ParentOriginRetry_t {
> PARENT_ORIGIN_UNDEFINED_RETRY = 0x0,
> PARENT_ORIGIN_SIMPLE_RETRY = 0x1,
> PARENT_ORIGIN_UNAVAILABLE_SERVER_RETRY = 0x2
>   };
> {code}
> The parent selection configuration sets values in terms of {{ParentRetry_t}} 
> but the transaction state machine checks {{ParentOriginRetry_t}}. We need to 
> define these once and use them consistently.



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

[GitHub] trafficserver issue #883: TS-4391: Duplicated parent origin retry types

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4391) Duplicated parent origin retry types

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4391?focusedWorklogId=26672=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26672
 ]

ASF GitHub Bot logged work on TS-4391:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 21:23
Start Date: 19/Aug/16 21:23
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

Worklog Id: (was: 26672)
Time Spent: 20m  (was: 10m)

> Duplicated parent origin retry types
> 
>
> Key: TS-4391
> URL: https://issues.apache.org/jira/browse/TS-4391
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have:
> {code}
> enum ParentRetry_t {
>   PARENT_RETRY_NONE = 0,
>   PARENT_RETRY_SIMPLE = 1,
>   PARENT_RETRY_UNAVAILABLE_SERVER = 2,
>   // both simple and unavailable server retry
>   PARENT_RETRY_BOTH = 3
> };
> {code}
> and
> {code}
>   enum ParentOriginRetry_t {
> PARENT_ORIGIN_UNDEFINED_RETRY = 0x0,
> PARENT_ORIGIN_SIMPLE_RETRY = 0x1,
> PARENT_ORIGIN_UNAVAILABLE_SERVER_RETRY = 0x2
>   };
> {code}
> The parent selection configuration sets values in terms of {{ParentRetry_t}} 
> but the transaction state machine checks {{ParentOriginRetry_t}}. We need to 
> define these once and use them consistently.



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

[GitHub] trafficserver issue #883: TS-4391: Duplicated parent origin retry types

[atsci]

Github user atsci commented on the issue:

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



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #883: TS-4391: Duplicated parent origin retry typ...

[jrushford]

GitHub user jrushford opened a pull request:

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

TS-4391: Duplicated parent origin retry types

Removed duplicated parent origin retry types.

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

$ git pull https://github.com/jrushford/trafficserver ts-4391

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

https://github.com/apache/trafficserver/pull/883.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 #883






---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4391) Duplicated parent origin retry types

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4391?focusedWorklogId=26671=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26671
 ]

ASF GitHub Bot logged work on TS-4391:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 21:13
Start Date: 19/Aug/16 21:13
Worklog Time Spent: 10m 
  Work Description: GitHub user jrushford opened a pull request:

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

TS-4391: Duplicated parent origin retry types

Removed duplicated parent origin retry types.

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

$ git pull https://github.com/jrushford/trafficserver ts-4391

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

https://github.com/apache/trafficserver/pull/883.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 #883






Issue Time Tracking
---

Worklog Id: (was: 26671)
Time Spent: 10m
Remaining Estimate: 0h

> Duplicated parent origin retry types
> 
>
> Key: TS-4391
> URL: https://issues.apache.org/jira/browse/TS-4391
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have:
> {code}
> enum ParentRetry_t {
>   PARENT_RETRY_NONE = 0,
>   PARENT_RETRY_SIMPLE = 1,
>   PARENT_RETRY_UNAVAILABLE_SERVER = 2,
>   // both simple and unavailable server retry
>   PARENT_RETRY_BOTH = 3
> };
> {code}
> and
> {code}
>   enum ParentOriginRetry_t {
> PARENT_ORIGIN_UNDEFINED_RETRY = 0x0,
> PARENT_ORIGIN_SIMPLE_RETRY = 0x1,
> PARENT_ORIGIN_UNAVAILABLE_SERVER_RETRY = 0x2
>   };
> {code}
> The parent selection configuration sets values in terms of {{ParentRetry_t}} 
> but the transaction state machine checks {{ParentOriginRetry_t}}. We need to 
> define these once and use them consistently.



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

[jira] [Work logged] (TS-4103) Introduce unit testing for CPP API

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4103?focusedWorklogId=26670=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26670
 ]

ASF GitHub Bot logged work on TS-4103:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 20:59
Start Date: 19/Aug/16 20:59
Worklog Time Spent: 10m 
  Work Description: Github user myraid commented on the issue:

https://github.com/apache/trafficserver/pull/408
  
@bgaff @zwoop can you take a look.


Issue Time Tracking
---

Worklog Id: (was: 26670)
Time Spent: 10m
Remaining Estimate: 0h

> Introduce unit testing for CPP API
> --
>
> Key: TS-4103
> URL: https://issues.apache.org/jira/browse/TS-4103
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: CPP API
>Reporter: Sandeep Davu
>Assignee: Brian Geffon
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> create mock classes for CPP API. 
> These mocks can be used for unit testing plugins written using CPP API.
> Using gtest as testing framework. gmock as mocking framework.



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

[GitHub] trafficserver issue #408: [TS-4103] mocks

[myraid]

Github user myraid commented on the issue:

https://github.com/apache/trafficserver/pull/408
  
@bgaff @zwoop can you take a look.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4362) Remove cacheurl plugin

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4362?focusedWorklogId=26669=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26669
 ]

ASF GitHub Bot logged work on TS-4362:
--

Author: ASF GitHub Bot
Created on: 19/Aug/16 20:55
Start Date: 19/Aug/16 20:55
Worklog Time Spent: 10m 
  Work Description: GitHub user gtenev opened a pull request:

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

TS-4362 Removed cacheurl plugin

Removed the cacheurl plugin and its documentation (including the Japanese 
version)

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

$ git pull https://github.com/gtenev/trafficserver TS-4362

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

https://github.com/apache/trafficserver/pull/882.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 #882


commit bce1ab5da7f9d73b529fb16d8786dd12b9205336
Author: Gancho Tenev 
Date:   2016-08-17T23:33:15Z

TS-4362 Removed cacheurl plugin




Issue Time Tracking
---

Worklog Id: (was: 26669)
Time Spent: 10m
Remaining Estimate: 0h

> Remove cacheurl plugin
> --
>
> Key: TS-4362
> URL: https://issues.apache.org/jira/browse/TS-4362
> Project: Traffic Server
>  Issue Type: Task
>  Components: Plugins
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Deprecate cacheurl plugin in favor of cachekey plugin



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

[GitHub] trafficserver pull request #882: TS-4362 Removed cacheurl plugin

[gtenev]

GitHub user gtenev opened a pull request:

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

TS-4362 Removed cacheurl plugin

Removed the cacheurl plugin and its documentation (including the Japanese 
version)

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

$ git pull https://github.com/gtenev/trafficserver TS-4362

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

https://github.com/apache/trafficserver/pull/882.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 #882


commit bce1ab5da7f9d73b529fb16d8786dd12b9205336
Author: Gancho Tenev 
Date:   2016-08-17T23:33:15Z

TS-4362 Removed cacheurl plugin




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1

[Tommy Lee (JIRA)]

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

Tommy Lee updated TS-2193:
--
Fix Version/s: (was: sometime)
   6.1.1

> Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
> --
>
> Key: TS-2193
> URL: https://issues.apache.org/jira/browse/TS-2193
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 4.1.2
>Reporter: Tommy Lee
>  Labels: Crash
> Fix For: sometime
>
> Attachments: bt-01.txt
>
>
> Hi all,
>   I've tried to enable DNS Thread without luck.
>   When i set proxy.config.dns.dedicated_thread to 1, it crashes with the 
> information below.
>   The ATS is working in Forward Proxy mode.
>   Thanks in advance.
> --
> traffic.out
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/cache-4.1/bin/traffic_server - STACK TRACE: 
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2af714875cb0]
> /usr/local/cache-4.1/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK_MD5P6HttpSM+0x52)[0x51dac2]
> /usr/local/cache-4.1/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12ContinuationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x51e0f1]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x53644c]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6a0)[0x537560]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM27state_hostdb_reverse_lookupEiPv+0xb9)[0x526b99]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x531be8]
> /usr/local/cache-4.1/bin/traffic_server[0x5d7c8a]
> /usr/local/cache-4.1/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x821)[0x5decd1]
> /usr/local/cache-4.1/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f7a94]
> /usr/local/cache-4.1/bin/traffic_server[0x5fd382]
> /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x852)[0x5fee72]
> /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x14)[0x5ffd94]
> /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x91)[0x6b2a41]
> /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread7executeEv+0x514)[0x6b3534]
> /usr/local/cache-4.1/bin/traffic_server[0x6b17ea]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x2af71486de9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2af71558dccd]



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

[jira] [Updated] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1

[Tommy Lee (JIRA)]

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

Tommy Lee updated TS-2193:
--
Fix Version/s: (was: 6.1.1)
   sometime

> Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
> --
>
> Key: TS-2193
> URL: https://issues.apache.org/jira/browse/TS-2193
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 4.1.2
>Reporter: Tommy Lee
>  Labels: Crash
> Fix For: sometime
>
> Attachments: bt-01.txt
>
>
> Hi all,
>   I've tried to enable DNS Thread without luck.
>   When i set proxy.config.dns.dedicated_thread to 1, it crashes with the 
> information below.
>   The ATS is working in Forward Proxy mode.
>   Thanks in advance.
> --
> traffic.out
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/cache-4.1/bin/traffic_server - STACK TRACE: 
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2af714875cb0]
> /usr/local/cache-4.1/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK_MD5P6HttpSM+0x52)[0x51dac2]
> /usr/local/cache-4.1/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12ContinuationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x51e0f1]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x53644c]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6a0)[0x537560]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM27state_hostdb_reverse_lookupEiPv+0xb9)[0x526b99]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x531be8]
> /usr/local/cache-4.1/bin/traffic_server[0x5d7c8a]
> /usr/local/cache-4.1/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x821)[0x5decd1]
> /usr/local/cache-4.1/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f7a94]
> /usr/local/cache-4.1/bin/traffic_server[0x5fd382]
> /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x852)[0x5fee72]
> /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x14)[0x5ffd94]
> /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x91)[0x6b2a41]
> /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread7executeEv+0x514)[0x6b3534]
> /usr/local/cache-4.1/bin/traffic_server[0x6b17ea]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x2af71486de9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2af71558dccd]



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

[jira] [Commented] (TS-4574) Let TSHttpTxnServerAddrSet clear the address

[James Peach (JIRA)]

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

James Peach commented on TS-4574:
-

No, this is not fixed. The referenced pull request just mentions this ticket.

> Let TSHttpTxnServerAddrSet clear the address
> 
>
> Key: TS-4574
> URL: https://issues.apache.org/jira/browse/TS-4574
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> After using {{TSHttpTxnServerAddrSet}} to route requests to a specific 
> destination, you might change your mind and decide to allow an internal DNS 
> lookup. 
> I propose that we allow {{TSHttpTxnServerAddrSet}} to take a {{NULL}} 
> argument to clear and API DNS result that was previously set.
> {code}
> diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc
> index 5772c12..362bf32 100644
> --- a/proxy/InkAPI.cc
> +++ b/proxy/InkAPI.cc
> @@ -5336,6 +5336,13 @@ TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr 
> const *addr)
>sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
>HttpSM *sm = reinterpret_cast(txnp);
> +
> +  if (addr == NULL) {
> +sm->t_state.api_server_addr_set = false;
> +sm->t_state.server_info.dst_addr.setToAnyAddr(AF_INET);
> +return TS_SUCCESS;
> +  }
> +
>if (ats_ip_copy(>t_state.server_info.dst_addr.sa, addr)) {
>  sm->t_state.api_server_addr_set = true;
>  return TS_SUCCESS;
> {code}



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

[jira] [Updated] (TS-4626) LogFile::close_file should not delete m_log handle

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-4626:

Assignee: Daniel Xu

> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.0.0
>
>
> When log file was deleted on the disk, LogFile::check_fd will close file 
> handle and reopen again.delete m_log at this point will cause 
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" .  otherwise, will 
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0  0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0, 
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1  0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970, 
> sink=0x1132eb0) at LogObject.cc:77
> #2  0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0) 
> at LogObject.h:146
> #3  0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228, 
> idx=0) at LogObject.cc:1126
> #4  0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at 
> Log.cc:1168
> #5  0x0066ce9d in LoggingPreprocContinuation::mainEvent 
> (this=0x1131ea0) at Log.cc:279
> #6  0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1, 
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7  0x007a1e9f in EThread::execute (this=0x707a1010) at 
> UnixEThread.cc:298
> #8  0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9  0x764740a4 in start_thread (arg=0x707a0700) at 
> pthread_create.c:309
> #10 0x7541c04d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0



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

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

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll reassigned TS-4599:
---

Assignee: Alan M. Carroll

> 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
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>




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

[jira] [Comment Edited] (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=15428735#comment-15428735
 ] 

Alan M. Carroll edited comment on TS-4593 at 8/19/16 7:59 PM:
--

Discussed this with the gang in Denver this week. My understanding is this will 
become part of a more general IpAllow upgrade to handle outgoing and integrate 
better with remap. The primary change would be to remove the connect level 
optimization and defer ACL checking until after remap.


was (Author: amc):
Discussed this with the gang in Denver this week. My understanding is this will 
become part of a more general IpAllow upgrade to handle outgoing and integrate 
better with remap.

> 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] [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=15428735#comment-15428735
 ] 

Alan M. Carroll commented on TS-4593:
-

Discussed this with the gang in Denver this week. My understanding is this will 
become part of a more general IpAllow upgrade to handle outgoing and integrate 
better with remap.

> 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)