[jira] [Work logged] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 29375)
Time Spent: 7.5h  (was: 7h 20m)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[GitHub] trafficserver issue #887: TS-2258: Mark whether configs are reloadable (part...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/734/ 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-2258) Verify that all fields are correct in RecordsConfig.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 29374)
Time Spent: 7h 20m  (was: 7h 10m)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h 20m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[GitHub] trafficserver issue #887: TS-2258: Mark whether configs are reloadable (part...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/838/ 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-2258) Verify that all fields are correct in RecordsConfig.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

Worklog Id: (was: 29373)
Time Spent: 7h 10m  (was: 7h)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h 10m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[GitHub] trafficserver issue #887: TS-2258: Mark whether configs are reloadable (part...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
[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-4875) Hoist SSL index creation into library initialization.

[James Peach (JIRA)]

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

James Peach resolved TS-4875.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 7.1.0

> Hoist SSL index creation into library initialization.
> -
>
> Key: TS-4875
> URL: https://issues.apache.org/jira/browse/TS-4875
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The SSL index used for server certificate validation can only be created 
> once, so we need to do it in the library initialization, not the client 
> context initialization. In principle, we can initialize client contexts 
> multiple times.



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

[jira] [Work logged] (TS-4875) Hoist SSL index creation into library initialization.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 04:41
Start Date: 20/Sep/16 04:41
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

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

> Hoist SSL index creation into library initialization.
> -
>
> Key: TS-4875
> URL: https://issues.apache.org/jira/browse/TS-4875
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The SSL index used for server certificate validation can only be created 
> once, so we need to do it in the library initialization, not the client 
> context initialization. In principle, we can initialize client contexts 
> multiple times.



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

[GitHub] trafficserver pull request #1030: TS-4875: Hoist SSL index creation into lib...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-2258) Verify that all fields are correct in RecordsConfig.cc

[Jari Alhonen (JIRA)]

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

Jari Alhonen updated TS-2258:
-
Assignee: (was: Jari Alhonen)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[jira] [Updated] (TS-1992) Examine mgmt/RecordsConfig.cc, add validation where it makes sense

[Jari Alhonen (JIRA)]

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

Jari Alhonen updated TS-1992:
-
Assignee: (was: Jari Alhonen)

> Examine mgmt/RecordsConfig.cc, add validation where it makes sense
> --
>
> Key: TS-1992
> URL: https://issues.apache.org/jira/browse/TS-1992
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Igor Galić
>  Labels: newbie
> Fix For: 7.2.0
>
>
> example:
> {code}
>   {RECT_CONFIG, "proxy.config.http.cache.required_headers", RECD_INT, "2", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> We should change this to
> {code}
>   {RECT_CONFIG, "proxy.config.http.cache.required_headers", RECD_INT, "2", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, "[0-2]", RECA_NULL}
> {code}
> which are the valid values for this config.



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

[jira] [Updated] (TS-2602) Support continuation lines in regex_remap configs

[Jari Alhonen (JIRA)]

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

Jari Alhonen updated TS-2602:
-
Assignee: (was: Jari Alhonen)

> Support continuation lines in regex_remap configs
> -
>
> Key: TS-2602
> URL: https://issues.apache.org/jira/browse/TS-2602
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.2.0
>
>
> With the introduction of overridable configurations (TS-2585), regex_remap 
> rules can now be fairly long. It'd be swell to support continuation lines, 
> e.g.
> {code}
> .  http://www.ogre.com/ \
>  @proxy.config.http.insert_response_via_str=1  \
>  @proxy.config.http.background_fill_completed_threshold=0.75
> {code}



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

[jira] [Assigned] (TS-2798) TLS client configuration is not really reloadable

[Jari Alhonen (JIRA)]

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

Jari Alhonen reassigned TS-2798:


Assignee: (was: Jari Alhonen)

> TLS client configuration is not really reloadable
> -
>
> Key: TS-2798
> URL: https://issues.apache.org/jira/browse/TS-2798
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Greg Henry
> Fix For: 7.1.0
>
>
> Cannot reload SSL client config.  It appears to but does not work.
> Made changes to reflect a Cert file.  It would not work without a complete 
> restart of ATS.  Should have been a traffic_line -x 



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

[jira] [Work logged] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/887#discussion_r79533983
  
--- Diff: mgmt/FileManager.cc ---
@@ -602,9 +600,9 @@ FileManager::WalkSnaps(ExpandingArray *snapList)
 {
   MFresult r;
 
-  // The original code reset this->managedDir from 
proxy.config.snapshot_dir at this point. There doesn't appear to be
-  // any need for that, since managedDir is always set in the constructor 
and should not be changed.
-  ink_release_assert(this->managedDir != NULL);
+  // Make sure managedDir is the latest from proxy.config.snapshot_dir.
+  ats_scoped_str snapshotDir(RecConfigReadSnapshotDir());
+  this->managedDir = snapshotDir;
--- End diff --

Done.


Issue Time Tracking
---

Worklog Id: (was: 29371)
Time Spent: 7h  (was: 6h 50m)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 7h
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[GitHub] trafficserver pull request #887: TS-2258: Mark whether configs are reloadabl...

[alhonen]

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

https://github.com/apache/trafficserver/pull/887#discussion_r79533983
  
--- Diff: mgmt/FileManager.cc ---
@@ -602,9 +600,9 @@ FileManager::WalkSnaps(ExpandingArray *snapList)
 {
   MFresult r;
 
-  // The original code reset this->managedDir from 
proxy.config.snapshot_dir at this point. There doesn't appear to be
-  // any need for that, since managedDir is always set in the constructor 
and should not be changed.
-  ink_release_assert(this->managedDir != NULL);
+  // Make sure managedDir is the latest from proxy.config.snapshot_dir.
+  ats_scoped_str snapshotDir(RecConfigReadSnapshotDir());
+  this->managedDir = snapshotDir;
--- End diff --

Done.


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

Jenkins build is back to normal : centos_7-master » gcc,centos_7,release #2009

[jenkins]

See 

[jira] [Work logged] (TS-4875) Hoist SSL index creation into library initialization.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Hoist SSL index creation into library initialization.
> -
>
> Key: TS-4875
> URL: https://issues.apache.org/jira/browse/TS-4875
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The SSL index used for server certificate validation can only be created 
> once, so we need to do it in the library initialization, not the client 
> context initialization. In principle, we can initialize client contexts 
> multiple times.



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

[jira] [Work logged] (TS-4875) Hoist SSL index creation into library initialization.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Hoist SSL index creation into library initialization.
> -
>
> Key: TS-4875
> URL: https://issues.apache.org/jira/browse/TS-4875
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The SSL index used for server certificate validation can only be created 
> once, so we need to do it in the library initialization, not the client 
> context initialization. In principle, we can initialize client contexts 
> multiple times.



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

[GitHub] trafficserver issue #1030: TS-4875: Hoist SSL index creation into library in...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1030
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/733/ 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 #1030: TS-4875: Hoist SSL index creation into library in...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1030
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/837/ 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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 03:47
Start Date: 20/Sep/16 03:47
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
@oknet I'd prefer 2 commits (better for bisecting).


Issue Time Tracking
---

Worklog Id: (was: 29368)
Time Spent: 2h 40m  (was: 2.5h)

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
@oknet I'd prefer 2 commits (better for bisecting).


---
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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 03:45
Start Date: 20/Sep/16 03:45
Worklog Time Spent: 10m 
  Work Description: Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
@jpeach , There is a similar bug in NetAccept::do_blocking_accept() which 
belongs to ACCEPT side instead of CONNECT side. Should I combine them together 
in one commit or 2 commits respectively ?


Issue Time Tracking
---

Worklog Id: (was: 29367)
Time Spent: 2.5h  (was: 2h 20m)

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
@jpeach , There is a similar bug in NetAccept::do_blocking_accept() which 
belongs to ACCEPT side instead of CONNECT side. Should I combine them together 
in one commit or 2 commits respectively ?


---
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-4705) Proposal: NetVC Context

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/753#discussion_r79531880
  
--- Diff: iocore/net/UnixNetAccept.cc ---
@@ -281,29 +280,30 @@ NetAccept::do_blocking_accept(EThread *t)
   return -1;
 }
 
+if (check_emergency_throttle(con)) {
+  // `con' could be closed if there is hyper emergency
+  if (con.fd == NO_FD) {
+return 0;
+  }
+}
+
--- End diff --

@jpeach , Here is a similar bug as PR #1033 


Issue Time Tracking
---

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

> Proposal: NetVC Context
> ---
>
> Key: TS-4705
> URL: https://issues.apache.org/jira/browse/TS-4705
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Goal 1st:
> In the NetVConnection, we have get_local_addr() and get_remote_addr() methods.
> Also have members local_addr, remote_addr and netvc->con.addr.
> Thus, we should using netvc->con.addr or remote_addr to replace member 
> server_addr in UnixNetVConnection.
> Goal 2nd:
> SSLNetVConnection has member sslClientConnection with 2 methods 
> setSSLClientConnection() and getSSLClientConnection() to indictor ATS is a 
> client or server in a SSL session.
> To abstract above two goals, I'm design the netvc context function.
> As a proxy, there has two side: client side ( Client <-> Proxy ) and server 
> side ( Proxy <-> Server ). With the netvc context funtion to indicate which 
> side the NetVC working on.
> Goal 3rd:
> Fix a minor bug in NetAccept::do_blocking_accept, call to 
> check_emergency_throttle(con) first then allocate vc.
> Goal 4th:
> NetAccept Optimize, remove dup code, etc...



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

[GitHub] trafficserver pull request #753: TS-4705: Proposal: NetVC Context

[oknet]

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

https://github.com/apache/trafficserver/pull/753#discussion_r79531880
  
--- Diff: iocore/net/UnixNetAccept.cc ---
@@ -281,29 +280,30 @@ NetAccept::do_blocking_accept(EThread *t)
   return -1;
 }
 
+if (check_emergency_throttle(con)) {
+  // `con' could be closed if there is hyper emergency
+  if (con.fd == NO_FD) {
+return 0;
+  }
+}
+
--- End diff --

@jpeach , Here is a similar bug as PR #1033 


---
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 #1029: Add a stub CONTRIBUTING file.

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/836/ 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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79531088
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
--- End diff --

set res to -errno.


Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Work logged] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79530993
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
+  goto fail;
+}
+  }
+
   // Must connect after EventIO::Start() to avoid a race condition
   // when edge triggering is used.
   if (ep.start(get_PollDescriptor(t), this, EVENTIO_READ | EVENTIO_WRITE) 
< 0) {
-lerrno = errno;
 Debug("iocore_net", "connectUp : Failed to add to epoll list");
-action_.continuation->handleEvent(NET_EVENT_OPEN_FAILED, (void *)0); 
// 0 == res
-free(t);
-return CONNECT_FAILURE;
+goto fail;
--- End diff --

The res declare with init value 0. I will update the res to return value of 
ep.start().


Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver pull request #1033: TS-4879: Checking con.fd == NO_FD while we...

[oknet]

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79531088
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
--- End diff --

set res to -errno.


---
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 #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
updated per @jpeach 's comments


---
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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 20/Sep/16 03:30
Start Date: 20/Sep/16 03:30
Worklog Time Spent: 10m 
  Work Description: Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
updated per @jpeach 's comments


Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver pull request #1033: TS-4879: Checking con.fd == NO_FD while we...

[oknet]

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79530993
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
+  goto fail;
+}
+  }
+
   // Must connect after EventIO::Start() to avoid a race condition
   // when edge triggering is used.
   if (ep.start(get_PollDescriptor(t), this, EVENTIO_READ | EVENTIO_WRITE) 
< 0) {
-lerrno = errno;
 Debug("iocore_net", "connectUp : Failed to add to epoll list");
-action_.continuation->handleEvent(NET_EVENT_OPEN_FAILED, (void *)0); 
// 0 == res
-free(t);
-return CONNECT_FAILURE;
+goto fail;
--- End diff --

The res declare with init value 0. I will update the res to return value of 
ep.start().


---
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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79530800
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
--- End diff --

changed the return type to bool for emergency_throttle, check_net_throttle 
and check_emergency_throttle


Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver pull request #1033: TS-4879: Checking con.fd == NO_FD while we...

[oknet]

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79530800
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
--- End diff --

changed the return type to bool for emergency_throttle, check_net_throttle 
and check_emergency_throttle


---
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 #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/732/ 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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Commented] (TS-4817) Frequent segfaults in Cache::open_write

[James Peach (JIRA)]

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

James Peach commented on TS-4817:
-

Since the assert message is in {{HttpTunnel.cc}}, I guess the base64 is a red 
herring?

> Frequent segfaults in Cache::open_write
> ---
>
> Key: TS-4817
> URL: https://issues.apache.org/jira/browse/TS-4817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Reporter: Mathias Biilmann Christensen
> Fix For: 7.1.0
>
> Attachments: core-dump.tar.gz
>
>
> I've been running some tests with the master branch sending some production 
> traffic to a test server, and am seeing very frequent segfaults.
> I'm running fb8bcbcac3c1d6c7a15340f0093342fb9f207e78
> The stack traces look like this:
> {noformat}
> traffic_server - STACK TRACE: 
> /opt/ts/bin/traffic_server(crash_logger_invoke(int, siginfo_t*, 
> void*)+0xc3)[0x511280]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x2ae12de39330]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2ae12eaa1c37]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2ae12eaa5028]
> /opt/ts/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2ae12cb11f4e]
> /opt/ts/lib/libtsutil.so.7(ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*)+0x0)[0x2ae12cb0f8e4]
> /opt/ts/bin/traffic_server(HttpTunnel::consumer_handler(int, 
> HttpTunnelConsumer*)+0xcc)[0x63efb2]
> /opt/ts/bin/traffic_server(HttpTunnel::main_handler(int, 
> void*)+0x133)[0x63f9b7]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::calluser(int)+0xaa)[0x74f4c8]
> /opt/ts/bin/traffic_server(CacheVC::openWriteMain(int, 
> Event*)+0x3de)[0x759d48]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::callcont(int)+0xfc)[0x74f608]
> /opt/ts/bin/traffic_server(CacheVC::openWriteStartDone(int, 
> Event*)+0x8a4)[0x75a9ee]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::handleReadDone(int, 
> Event*)+0xd15)[0x72a3e7]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(Cache::open_write(Continuation*, ats::CryptoHash 
> const*, HTTPInfo*, long, ats::CryptoHash const*, CacheFragType, char const*, 
> int)+0x6f$
> )[0x75b9df]
> /opt/ts/bin/traffic_server(CacheProcessor::open_write(Continuation*, int, 
> HttpCacheKey const*, bool, HTTPHdr*, HTTPInfo*, long, 
> CacheFragType)+0x129)[0x72eee5]
> /opt/ts/bin/traffic_server(HttpCacheSM::open_write(HttpCacheKey const*, URL*, 
> HTTPHdr*, HTTPInfo*, long, bool, bool)+0x236)[0x5d25a2]
> /opt/ts/bin/traffic_server(HttpSM::do_cache_prepare_action(HttpCacheSM*, 
> HTTPInfo*, bool, bool)+0x352)[0x5f054e]
> /opt/ts/bin/traffic_server(HttpSM::do_cache_prepare_write_transform()+0x69)[0x6013dd]
> /opt/ts/bin/traffic_server(HttpSM::set_next_state()+0x1a27)[0x5fb613]
> /opt/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
> (*)(HttpTransact::State*))+0x1ae)[0x5f9be4]
> /opt/ts/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
>  void*)+0x19b)[0x5e35cd]
> /opt/ts/bin/traffic_server(HttpSM::main_handler(int, void*)+0x33a)[0x5e88ac]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(TransformTerminus::handle_event(int, 
> void*)+0x2fe)[0x561096]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x136)[0x7b3eac]
> /opt/ts/bin/traffic_server(EThread::execute()+0xdc)[0x7b410c]
> /opt/ts/bin/traffic_server(main+0x139c)[0x546c99]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2ae12ea8cf45]
> /opt/ts/bin/traffic_server[0x4f9840]
> FATAL: HttpTunnel.cc:1372: failed assertion `c->alive == true`
> {noformat}
> I'm attaching a core dump from a debug build of ATS as well



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

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[Gancho Tenev (JIRA)]

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

Gancho Tenev commented on TS-4334:
--

Checked with [~latesonarinn] offline and here is an excerpt:

9/16/16, 12:06 PM Gancho Tenev:
{quote}
Proposed alternative solution using more generic means (cachekey and 
header_rewrite) here: [TS-4334|https://issues.apache.org/jira/browse/TS-4334]
Could you please let me know if it works for you?
{quote}

9/19/16, 9:59 AM Nolan Astrein: 
{quote}
Clever solution.  I think that will work.
{quote}


[~latesonarinn], could you please verify and/or close this Jira if all looks 
good? 
(if not please let me know if I can help!)

Cheers!

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



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

[jira] [Work logged] (TS-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/731/ 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-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/835/ 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-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1028
  
@jpeach, renamed "offline" flag to "online", added some reasoning about why 
the flag was necessary in the last commit description.


Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...

[gtenev]

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
@jpeach, renamed "offline" flag to "online", added some reasoning about why 
the flag was necessary in the last commit description.


---
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] [Commented] (TS-4866) Remove traffic_cop health checking.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4866:
---

I have a possible alternative to this, which is to make the actual killing of 
the processes optional. Meaning, it would still do the health checks, notify on 
the events, but not actually kill the process. This would address some of the 
concerns that was brought up, asking the (good) question as "How often does cop 
actually kill something when it should". So, with this, you can turn off the 
killing of traffic_server, and then see if you had to manually intervene or not.

I will make a PR momentarily.

> Remove traffic_cop health checking.
> ---
>
> Key: TS-4866
> URL: https://issues.apache.org/jira/browse/TS-4866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>
> There is a school of thought that {{traffic_cop}} health checking causes more 
> problems that in solves. Consider whether we should eliminate health checking 
> from {{traffic_cop}}.



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

[jira] [Commented] (TS-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[Gancho Tenev (JIRA)]

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

Gancho Tenev commented on TS-4707:
--

[~jrushford], [~pbchou], [~zwoop], 

I am not sure if I studied this enough but here is an idea: it seems that we 
could add a switch to {{cachekey}} plugin to make it use the "modify parent 
selection URI" API call instead of "modify cache key URI" API if something 
like: {{\@plugin=cachekey \@pparam=--parent_selection}} is used.

This way we may be able to use independently different {{cachekey}} plugin 
instances per each remap rule (one for modifying the cache key URI and one for 
modifying the parent selection URI) to be able to cover for more use-cases, 
reuse the {{cachekey}} URI manipulation functionality and have consistent user 
experience. If this makes sense/works we may end up renaming the plugin to 
something more generic.

Currently {{cachekey}} plugin has the ability to do {{fname}} and {{maxdirs}} 
features by using some of its regex related features (please see 
{{--capture-path=/capture/replace/}} @  [cachekey 
docs|https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/cachekey.en.html#path-section],
 I can provide examples if requested)

I think {{fname}} would not make sense for manipulating the cache key URI and 
if we insist on non-regex ways to achieve {{fname}} and {{maxdirs}} we could 
add it as features available only if {{--parent_selection}} is used, or 
something in this sense.

If this sounds sensible/feasible I can work on the {{cachekey}} plugin change.

> Parent Consistent Hash Selection - add fname and maxdirs options.
> -
>
> Key: TS-4707
> URL: https://issues.apache.org/jira/browse/TS-4707
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Peter Chou
>Assignee: Peter Chou
> Fix For: 7.1.0
>
>  Time Spent: 11.5h
>  Remaining Estimate: 0h
>
> This enhancement adds two options, "fname" and "maxdirs", which can be used 
> to exclude the file-name and some of the directories in the path. The 
> remaining portions of the path are then used as part of the hash computation 
> for selecting among multiple parent caches.
> For our usage, it was desirable from an operational perspective to direct all 
> components of particular sub-tree to a single parent cache (to simplify 
> trouble-shooting, pre-loading, etc.). This can be achieved by excluding the 
> query-string, file-name, and right-most portions of the path from the hash 
> computation.



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

[jira] [Work logged] (TS-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1028#discussion_r79487888
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2000,6 +2000,12 @@ CacheProcessor::mark_storage_offline(CacheDisk *d 
///< Target disk
   uint64_t total_dir_delete   = 0;
   uint64_t used_dir_delete= 0;
 
+  /* Don't mark it again, it will invalidate the stats! */
+  if (d->offline) {
+return this->has_online_storage();
+  }
+  d->offline = true;
--- End diff --

@jpeach, great! sure, I can rename the flag to "online" :)


Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[GitHub] trafficserver pull request #1028: TS-4870 Avoid marking storage offline mult...

[gtenev]

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

https://github.com/apache/trafficserver/pull/1028#discussion_r79487888
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2000,6 +2000,12 @@ CacheProcessor::mark_storage_offline(CacheDisk *d 
///< Target disk
   uint64_t total_dir_delete   = 0;
   uint64_t used_dir_delete= 0;
 
+  /* Don't mark it again, it will invalidate the stats! */
+  if (d->offline) {
+return this->has_online_storage();
+  }
+  d->offline = true;
--- End diff --

@jpeach, great! sure, I can rename the flag to "online" :)


---
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-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1028#discussion_r79486346
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2000,6 +2000,12 @@ CacheProcessor::mark_storage_offline(CacheDisk *d 
///< Target disk
   uint64_t total_dir_delete   = 0;
   uint64_t used_dir_delete= 0;
 
+  /* Don't mark it again, it will invalidate the stats! */
+  if (d->offline) {
+return this->has_online_storage();
+  }
+  d->offline = true;
--- End diff --

@gtenev and I discussed this. The problem is that in the common case, the 
disk is already bad when ``mark_storage_offline`` is called, so we can't depend 
on the good->bad state transition to know when to update the accounting.

@gtenev This looks fine to me, but I'd suggest calling the flag ``online`` 
so that we avoid the double negatives.


Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[GitHub] trafficserver pull request #1028: TS-4870 Avoid marking storage offline mult...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1028#discussion_r79486346
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2000,6 +2000,12 @@ CacheProcessor::mark_storage_offline(CacheDisk *d 
///< Target disk
   uint64_t total_dir_delete   = 0;
   uint64_t used_dir_delete= 0;
 
+  /* Don't mark it again, it will invalidate the stats! */
+  if (d->offline) {
+return this->has_online_storage();
+  }
+  d->offline = true;
--- End diff --

@gtenev and I discussed this. The problem is that in the common case, the 
disk is already bad when ``mark_storage_offline`` is called, so we can't depend 
on the good->bad state transition to know when to update the accounting.

@gtenev This looks fine to me, but I'd suggest calling the flag ``online`` 
so that we avoid the double negatives.


---
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-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1028
  
@gtenev If i'm reading your patch correctly, it adds the ``offline`` flag 
such that disks are marked bad *and* offline. That doesn't sound like what you 
intended from the description above.


Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
@gtenev If i'm reading your patch correctly, it adds the ``offline`` flag 
such that disks are marked bad *and* offline. That doesn't sound like what you 
intended from the description above.


---
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-4881) Fix "Warning: Connection leak" log messages.

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4881.

Resolution: Duplicate

While creating the PR, I see that I already fixed it in open source via TS-4750.

> Fix "Warning: Connection leak" log messages.
> 
>
> Key: TS-4881
> URL: https://issues.apache.org/jira/browse/TS-4881
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> A follow along fix for TS-3901.
> It looks like there is another drift between the cached server IP value used 
> to insert into the session pool (HttpServerSession::server_ip) and the cached 
> server IP value used to look up from the session pool 
> (NetVConnection::remote_addr).
> I'm guessing that the HttpServerSession value was added to avoid calling 
> vc->get_remote_addr() multiple times. But the vc also caches the remote addr, 
> so calls to vc->get_remote_addr should be pretty cheap. 
> Added a debug print to better understand the difference between 
> vc->get_remote_addr() and server_session->server_ip. In this case, the 
> differences are in the ports.
> DEBUG: (http_ss) remote_ip=xx.xx.xx.xx:3128, server_ip=xx.xx.xx.xx:80
> Specifically, vc->get_remote_addr() is the first value and reflects the 
> "real" port used to connection to the server. The server_ip port is the 
> pre-remap port.
> We ended up using remote_ip for both server session insert and lookup and 
> things have been running solidly for us.



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

[jira] [Assigned] (TS-4881) Fix "Warning: Connection leak" log messages.

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-4881:
--

Assignee: Susan Hinrichs

> Fix "Warning: Connection leak" log messages.
> 
>
> Key: TS-4881
> URL: https://issues.apache.org/jira/browse/TS-4881
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> A follow along fix for TS-3901.
> It looks like there is another drift between the cached server IP value used 
> to insert into the session pool (HttpServerSession::server_ip) and the cached 
> server IP value used to look up from the session pool 
> (NetVConnection::remote_addr).
> I'm guessing that the HttpServerSession value was added to avoid calling 
> vc->get_remote_addr() multiple times. But the vc also caches the remote addr, 
> so calls to vc->get_remote_addr should be pretty cheap. 
> Added a debug print to better understand the difference between 
> vc->get_remote_addr() and server_session->server_ip. In this case, the 
> differences are in the ports.
> DEBUG: (http_ss) remote_ip=xx.xx.xx.xx:3128, server_ip=xx.xx.xx.xx:80
> Specifically, vc->get_remote_addr() is the first value and reflects the 
> "real" port used to connection to the server. The server_ip port is the 
> pre-remap port.
> We ended up using remote_ip for both server session insert and lookup and 
> things have been running solidly for us.



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

[jira] [Created] (TS-4881) Fix "Warning: Connection leak" log messages.

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-4881:
--

 Summary: Fix "Warning: Connection leak" log messages.
 Key: TS-4881
 URL: https://issues.apache.org/jira/browse/TS-4881
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Susan Hinrichs


A follow along fix for TS-3901.

It looks like there is another drift between the cached server IP value used to 
insert into the session pool (HttpServerSession::server_ip) and the cached 
server IP value used to look up from the session pool 
(NetVConnection::remote_addr).

I'm guessing that the HttpServerSession value was added to avoid calling 
vc->get_remote_addr() multiple times. But the vc also caches the remote addr, 
so calls to vc->get_remote_addr should be pretty cheap. 

Added a debug print to better understand the difference between 
vc->get_remote_addr() and server_session->server_ip. In this case, the 
differences are in the ports.

DEBUG: (http_ss) remote_ip=xx.xx.xx.xx:3128, server_ip=xx.xx.xx.xx:80

Specifically, vc->get_remote_addr() is the first value and reflects the "real" 
port used to connection to the server. The server_ip port is the pre-remap port.

We ended up using remote_ip for both server session insert and lookup and 
things have been running solidly for us.





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

[GitHub] trafficserver issue #1028: TS-4870 Avoid marking storage offline multiple ti...

[gtenev]

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/1028
  
@jpeach, appreciate your feedback!

It felt that "disk being offline" (might be an operator's decision) and 
"disk being bad" (number of IO errors reached a threshold) are better kept 
separate in general.
 
IMHO using `CacheDisk::num_errors` to mark the disk offline could be error 
prone and here is an example.

Let us say ``proxy.config.cache.max_disk_errors=5`` and a disk keeps 
failing causing ``handle_disk_failure()`` to be called and at some point 
``CacheDisk::num_errors`` becomes ``5``  which causes 
``mark_storage_offline()`` to be called. 

At this point since ``CacheDisk::num_errors=5`` then ``true==DISK_BAD(d)``.

It seems that if I did ``if(!DISK_BAD(d)) {...}`` (as suggested above) it 
would not execute the code in ``mark_storage_offline()`` at all, for instance 
``proxy.process.cache.bytes_total_stat`` would not get updated as it should.

This is one of my first adventures in the "cache"component so I hope I am 
not missing something, please let me know what you think and will gladly 
look/test/change as necessary. 







---
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-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1028
  
@jpeach, appreciate your feedback!

It felt that "disk being offline" (might be an operator's decision) and 
"disk being bad" (number of IO errors reached a threshold) are better kept 
separate in general.
 
IMHO using `CacheDisk::num_errors` to mark the disk offline could be error 
prone and here is an example.

Let us say ``proxy.config.cache.max_disk_errors=5`` and a disk keeps 
failing causing ``handle_disk_failure()`` to be called and at some point 
``CacheDisk::num_errors`` becomes ``5``  which causes 
``mark_storage_offline()`` to be called. 

At this point since ``CacheDisk::num_errors=5`` then ``true==DISK_BAD(d)``.

It seems that if I did ``if(!DISK_BAD(d)) {...}`` (as suggested above) it 
would not execute the code in ``mark_storage_offline()`` at all, for instance 
``proxy.process.cache.bytes_total_stat`` would not get updated as it should.

This is one of my first adventures in the "cache"component so I hope I am 
not missing something, please let me know what you think and will gladly 
look/test/change as necessary. 







Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

Build failed in Jenkins: centos_7-master » gcc,centos_7,release #2008

[jenkins]

See 


--
[...truncated 20780 lines...]
{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

 real request (length=56)

GET http://www.news.com/ HTTP/1.1
Connection: close



[GET http://www.news.com/ HTTP/1.1
Connection: close

]


 real response (length=163)

HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT



[HTTP/1.0 200 OK
MIME-Version: 1.0
Server: WebSTAR/2.1 ID/30013
Content-Type: text/html
Content-Length: 939
Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT

]

{HTTP/1.0 200 OK\15\12MIME-Version: 1.0\15\12Server: WebSTAR/2.1 
ID/30013\15\12Content-Type: text/html\15\12Content-Length: 
939\15\12Last-Modified: Thursday, 01-Jan-04 05:00:00 GMT\15\12\15\12}   <<< 
MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

   <<< MUST BE HAND-VERIFIED FOR FULL BENEFIT >>>

 parsing

Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(cache) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(cache) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSTextLog) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Release) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Release) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Set) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Set) still in progress
Regression test(HostDBTests) still in progress
Regression test(SDK_API_TSThread) still in progress
Regression test(ProxyConfig_Set) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_CongestionDB) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_CongestionDB) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_CongestionDB) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_CongestionDB) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_CongestionDB) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_CongestionDB) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_FailHistory) still in progress
Regression test(HostDBTests) still in progress
Regression test(Congestion_FailHistory) still in progress
Regressio[SDK_API_TSHttpConnectServerIntercept] TSHttpConnect : [TestCase2] 
<> { ok }
[SDK_API_TSHttpConnectServerIntercept] TSHttpTxnServerIntercept : [TestCase2] 
<> { ok }
REGRESSION_RESULT SDK_API_TSHttpConnectServerIntercept: PASSED
REGRESSION TEST SDK_API_TSHttpConnectIntercept started
[SDK_API_TSHttpConnectIntercept] TSHttpConnect : [TestCase1] <> { ok }
[SDK_API_TSHttpConnectIntercept] TSHttpTxnIntercept : [TestCase1] <> { ok 
}
REGRESSION_RESULT SDK_API_TSHttpConnectIntercept:   PASSED
REGRESSION TEST SDK_API_HttpAltInfo started
[SDK_API_HttpAltInfo] TSHttpAltInfoClientReqGet : [TestCase] <> { ok }
[SDK_API_HttpAltInfo] TSHttpAltInfoCachedReqGet : [TestCase] <> { ok }
[SDK_API_HttpAltInfo] TSHttpAltInfoCachedRespGet : [TestCase] <> { ok }
[SDK_API_HttpAltInfo] TSHttpAltInfoQualitySet : [TestCase] <> { ok }
RPRINT HostDBTests: HostDBTestReverse: reversed 24.87.176.95.rev.sfr.net
RPRINT HostDBTests: HostDBTestReverse: reversed 24.87.176.95.rev.sfr.net
RPRINT HostDBTests: HostDBTestReverse: reversed 24.87.176.95.rev.sfr.net
RPRINT HostDBTests: HostDBTestReverse: reversed 24.87.176.95.rev.sfr.net
RPRINT HostDBTests: HostDBTestReverse: reversed 24.87.176.95.rev.sfr.net
RPRINT HostDBTests: HostDBTestReverse: reversed 24.87.176.95.rev.sfr.net
RPRINT HostDBTests: HostDBTestReverse: reversed 24.87.176.95.rev.sfr.net
RPRINT HostDBTests: 

[GitHub] trafficserver pull request #1028: TS-4870 Avoid marking storage offline mult...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1028#discussion_r79424573
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2000,6 +2000,12 @@ CacheProcessor::mark_storage_offline(CacheDisk *d 
///< Target disk
   uint64_t total_dir_delete   = 0;
   uint64_t used_dir_delete= 0;
 
+  /* Don't mark it again, it will invalidate the stats! */
+  if (d->offline) {
+return this->has_online_storage();
+  }
+  d->offline = true;
--- End diff --

Why do yo introduce a new flag rather than making the code conditional on 
the ``DISK_BAD`` check? e.g.
```C
if (!DISK_BAD(d)) {
  SET_DISK_BAD(d);

  // Do all the other stuff ...
}
```


---
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-4870) Storage can be marked offline multiple times which breaks related metrics

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 15:59
Start Date: 19/Sep/16 15:59
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1028#discussion_r79424573
  
--- Diff: iocore/cache/Cache.cc ---
@@ -2000,6 +2000,12 @@ CacheProcessor::mark_storage_offline(CacheDisk *d 
///< Target disk
   uint64_t total_dir_delete   = 0;
   uint64_t used_dir_delete= 0;
 
+  /* Don't mark it again, it will invalidate the stats! */
+  if (d->offline) {
+return this->has_online_storage();
+  }
+  d->offline = true;
--- End diff --

Why do yo introduce a new flag rather than making the code conditional on 
the ``DISK_BAD`` check? e.g.
```C
if (!DISK_BAD(d)) {
  SET_DISK_BAD(d);

  // Do all the other stuff ...
}
```


Issue Time Tracking
---

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

> Storage can be marked offline multiple times which breaks related metrics
> -
>
> Key: TS-4870
> URL: https://issues.apache.org/jira/browse/TS-4870
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Let us say traffic server is running with 2 disks
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ sudo fdisk -l|grep 'Disk /dev/sd[b|c]'
> Disk /dev/sdb: 134 MB, 134217728 bytes
> Disk /dev/sdc: 134 MB, 134217728 bytes
> {code}
> Let us see what happens when we mark the same disk 3 times in a raw 
> ({{/dev/sdb}}) and check the {{proxy.node.cache.bytes_total}}.
> {code}
> # Initial cache size (when using both disks).
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 268025856
> # Take 1st disk offline. Cache size changes as expected.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 134012928
> # Take same disk offline again. Not good!
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total 0
> # Take same disk offline again. Negative value.
> $ sudo ./bin/traffic_ctl storage offline /dev/sdb
> $ ./bin/traffic_ctl metric get proxy.node.cache.bytes_total
> proxy.node.cache.bytes_total -134012928
> {code}



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

[jira] [Resolved] (TS-4878) Reduce outbound SNI hostname debugging.

[James Peach (JIRA)]

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

James Peach resolved TS-4878.
-
Resolution: Fixed

> Reduce outbound SNI hostname debugging.
> ---
>
> Key: TS-4878
> URL: https://issues.apache.org/jira/browse/TS-4878
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The logging around the call to {{SSL_set_tlsext_host_name}} is emitted on 
> each event that calls {{sslStartHandShake}}, usually 3 or 4 times. We only 
> need this to be done and logged once.



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

[jira] [Work logged] (TS-4878) Reduce outbound SNI hostname debugging.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 15:50
Start Date: 19/Sep/16 15:50
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

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

> Reduce outbound SNI hostname debugging.
> ---
>
> Key: TS-4878
> URL: https://issues.apache.org/jira/browse/TS-4878
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The logging around the call to {{SSL_set_tlsext_host_name}} is emitted on 
> each event that calls {{sslStartHandShake}}, usually 3 or 4 times. We only 
> need this to be done and logged once.



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

[jira] [Work logged] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 15:49
Start Date: 19/Sep/16 15:49
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1033#discussion_r79422378
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
--- End diff --

Since you are touching this code, could you please change the return type 
of ``check_emergency_throttle`` to ``bool``?


Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Work logged] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 15:49
Start Date: 19/Sep/16 15:49
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1033#discussion_r79422585
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
+  goto fail;
+}
+  }
+
   // Must connect after EventIO::Start() to avoid a race condition
   // when edge triggering is used.
   if (ep.start(get_PollDescriptor(t), this, EVENTIO_READ | EVENTIO_WRITE) 
< 0) {
-lerrno = errno;
 Debug("iocore_net", "connectUp : Failed to add to epoll list");
-action_.continuation->handleEvent(NET_EVENT_OPEN_FAILED, (void *)0); 
// 0 == res
-free(t);
-return CONNECT_FAILURE;
+goto fail;
--- End diff --

Set ``res``?


Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver pull request #1032: TS-4878: Call SSL_set_tlsext_host_name jus...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 15:49
Start Date: 19/Sep/16 15:49
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1033#discussion_r79421321
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
--- End diff --

``connectUP`` returns ``CONNECT_SUCCESS``,  ``CONNECT_FAILURE``, or 
``-errno``.


Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[jira] [Work logged] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 15:49
Start Date: 19/Sep/16 15:49
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1033#discussion_r79422164
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
--- End diff --

Please comment here that we need to decrement the stat because 
``close_UnixNetVConnection`` only decrements with a valid connection descriptor.


Issue Time Tracking
---

Worklog Id: (was: 29316)

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver pull request #1033: TS-4879: Checking con.fd == NO_FD while we...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79422164
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
--- End diff --

Please comment here that we need to decrement the stat because 
``close_UnixNetVConnection`` only decrements with a valid connection descriptor.


---
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 #1033: TS-4879: Checking con.fd == NO_FD while we...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79421321
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
--- End diff --

``connectUP`` returns ``CONNECT_SUCCESS``,  ``CONNECT_FAILURE``, or 
``-errno``.


---
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 #1033: TS-4879: Checking con.fd == NO_FD while we...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79422378
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
--- End diff --

Since you are touching this code, could you please change the return type 
of ``check_emergency_throttle`` to ``bool``?


---
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 #1033: TS-4879: Checking con.fd == NO_FD while we...

[jpeach]

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

https://github.com/apache/trafficserver/pull/1033#discussion_r79422585
  
--- Diff: iocore/net/UnixNetVConnection.cc ---
@@ -1273,14 +1273,21 @@ UnixNetVConnection::connectUp(EThread *t, int fd)
 con.is_bound = true;
   }
 
+  if (check_emergency_throttle(con)) {
+// `con' could be closed if there is hyper emergency
+if (con.fd == NO_FD) {
+  NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, -1);
+  // set errno force to EMFILE (reached limit for open file 
descriptors)
+  res = errno = EMFILE;
+  goto fail;
+}
+  }
+
   // Must connect after EventIO::Start() to avoid a race condition
   // when edge triggering is used.
   if (ep.start(get_PollDescriptor(t), this, EVENTIO_READ | EVENTIO_WRITE) 
< 0) {
-lerrno = errno;
 Debug("iocore_net", "connectUp : Failed to add to epoll list");
-action_.continuation->handleEvent(NET_EVENT_OPEN_FAILED, (void *)0); 
// 0 == res
-free(t);
-return CONNECT_FAILURE;
+goto fail;
--- End diff --

Set ``res``?


---
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 #1009: TS-4853 : Parent Consistent Hash Selection...

[jrushford]

Github user jrushford closed the pull request at:

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


---
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] [Closed] (TS-4853) Parent Consistent Hash Selection - add parent selection URL and API.

[John Rushford (JIRA)]

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

John Rushford closed TS-4853.
-

> Parent Consistent Hash Selection - add parent selection URL and API.
> 
>
> Key: TS-4853
> URL: https://issues.apache.org/jira/browse/TS-4853
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Peter Chou
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add the ability (via TS and Lua APIs) to set an explicit parent selection URL 
> that will be used for parent consistent hash selection hashing.



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

[jira] [Resolved] (TS-4853) Parent Consistent Hash Selection - add parent selection URL and API.

[John Rushford (JIRA)]

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

John Rushford resolved TS-4853.
---
Resolution: Fixed

PR was merged.

> Parent Consistent Hash Selection - add parent selection URL and API.
> 
>
> Key: TS-4853
> URL: https://issues.apache.org/jira/browse/TS-4853
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Peter Chou
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add the ability (via TS and Lua APIs) to set an explicit parent selection URL 
> that will be used for parent consistent hash selection hashing.



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

[jira] [Work logged] (TS-4853) Parent Consistent Hash Selection - add parent selection URL and API.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 15:21
Start Date: 19/Sep/16 15:21
Worklog Time Spent: 10m 
  Work Description: Github user jrushford closed the pull request at:

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


Issue Time Tracking
---

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

> Parent Consistent Hash Selection - add parent selection URL and API.
> 
>
> Key: TS-4853
> URL: https://issues.apache.org/jira/browse/TS-4853
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Peter Chou
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add the ability (via TS and Lua APIs) to set an explicit parent selection URL 
> that will be used for parent consistent hash selection hashing.



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

[jira] [Work logged] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/730/ 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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/834/ 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] [Commented] (TS-803) Fix SOCKS breakage and allow for setting next-hop SOCKS

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-803:
-

Form my understand:

  - compare to parent http proxy server, socks proxy server as a parent proxy 
is an bottom setting
  - the socks proxy is designed to proxy all outgoing connections including 
parent http proxy server.

So we can set a socks proxy with the new API in a remap or plugin manually.

About the API name:

  - proxy/api/ts/ts.h:tsapi void TSHttpTxnParentProxySet(TSHttpTxn txnp, const 
char *hostname, int port);
  - we already have ParentProxySet API that is named without "Addr"
  - the socks proxy is not only set for HTTP protocol and it is set for a 
VConnection. Can we named it with TSVConnSocksParentSet ?

And we need more parameters for socks server: 

  - socks version
  - username (optional)
  - password (optional)



> Fix SOCKS breakage and allow for setting next-hop SOCKS
> ---
>
> Key: TS-803
> URL: https://issues.apache.org/jira/browse/TS-803
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network, SOCKS
>Affects Versions: 3.0.0
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
>
> Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7 
> unstable/git. There are some quirks here, and I'm not that sure any more what 
> this patch does exactly. However it:
> 1) Does fix SOCKS connections in general
> 2) Allows setting next-hop SOCKS proxy via the API
> Problems:
> See https://issues.apache.org/jira/browse/TS-802
> This has no effect on connections which are drawn from the connection pool, 
> as it seems ATS currently doesn't maintain unique identities for peripheral 
> connection params (source IP, SOCKS etc); i.e. this only affects new TCP 
> connections to an OS.
> diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h 
> tsgit217/iocore/net/I_NetVConnection.h
> --- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0 
> +
> +++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0 
> +
> @@ -120,6 +120,13 @@
>/// Version of SOCKS to use.
>unsigned char socks_version;
> +  struct {
> +  unsigned int ip;
> +  int port;
> +  char *username;
> +  char *password;
> +  } socks_override;
> +
>int socket_recv_bufsize;
>int socket_send_bufsize;
> Only in tsgit217/iocore/net: Makefile
> Only in tsgit217/iocore/net: Makefile.in
> diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
> --- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
> @@ -126,7 +126,7 @@
>unsigned char version;
>bool write_done;
> -
> +  bool manual_parent_selection;
>SocksAuthHandler auth_handler;
>unsigned char socks_cmd;
> @@ -145,7 +145,8 @@
>  SocksEntry():Continuation(NULL), netVConnection(0),
>  ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
> -lerrno(0), timeout(0), version(5), write_done(false), 
> auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
> +lerrno(0), timeout(0), version(5), write_done(false), 
> manual_parent_selection(false),
> +auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
>{
>}
>  };
> diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
> --- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
> @@ -73,7 +73,8 @@
>nattempts = 0;
>findServer();
> -  timeout = this_ethread()->schedule_in(this, 
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +//  timeout = this_ethread()->schedule_in(this, 
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +  timeout = this_ethread()->schedule_in(this, HRTIME_SECONDS(5));
>write_done = false;
>  }
> @@ -81,6 +82,15 @@
>  SocksEntry::findServer()
>  {
>nattempts++;
> +  if(manual_parent_selection) {
> +  if(nattempts > 1) {
> +  //Nullify IP and PORT
> +  server_ip = -1;
> +  server_port = 0;
> +  }
> +  Debug("mndebug(Socks)", "findServer() is a noop with manual socks 
> selection");
> +  return;
> +  }
>  #ifdef SOCKS_WITH_TS
>if (nattempts == 1) {
> @@ -187,7 +197,6 @@
>  }
>  Debug("Socks", "Failed to connect to %u.%u.%u.%u:%d", 
> PRINT_IP(server_ip), server_port);
> -
>  findServer();
>  if (server_ip == (uint32_t) - 1) {
> diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc 
> tsgit217/iocore/net/UnixNetProcessor.cc
> --- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0 
> +
> +++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0 
> +
> @@ 

[jira] [Work logged] (TS-4880) RemapPlugin class doesn't work correctly

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 19/Sep/16 07:49
Start Date: 19/Sep/16 07:49
Worklog Time Spent: 10m 
  Work Description: GitHub user syucream opened a pull request:

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

TS-4880: Fix missing missing utils::internal::initTransactionManagement() 
call

https://issues.apache.org/jira/browse/TS-4880

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

$ git pull https://github.com/syucream/trafficserver TS-4880

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

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


commit cced5de168e28e59013c6455c54fa2f7e65a3d78
Author: Ryo Okubo 
Date:   2016-09-19T07:47:12Z

TS-4880: Fix missing missing utils::internal::initTransactionManagement() 
call




Issue Time Tracking
---

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

> RemapPlugin class doesn't work correctly
> 
>
> Key: TS-4880
> URL: https://issues.apache.org/jira/browse/TS-4880
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API
>Reporter: Ryo Okubo
>Assignee: Brian Geffon
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current atscppapi::RemapPlugin has two issues. These seem to be caused by 
> missing utils::internal::initTransactionManagement() call.
> First, after TS-4555, plugins uses RemapPlugin class doesn't work because it 
> can't pass an assertion.
> {noformat}
> # my remap.config. It uses RemapPlugin, one of atscppapi examples.
> map / http://127.0.0.1:80/ @plugin=RemapPlugin.so
> {noformat}
> {noformat}
> $ lldb /path/to/traffic_server
> ...
> (lldb) r
> ...
> (lldb) bt
> ...
> * thread #7: tid = 0x3ce4eef, 0x7fff886d0f06 
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 4]', stop reason 
> = signal SIGABRT
>   * frame #0: 0x7fff886d0f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff91d6b4ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff902b56df libsystem_c.dylib`abort + 129
> frame #3: 0x00039799 
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") + 
> 361 at ink_error.cc:79
> frame #4: 0x0003703f 
> libtsutil.7.dylib`::_ink_assert(expression="arg_idx >= 0 && arg_idx < 
> HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 47 at 
> ink_assert.cc:37
> frame #5: 0x0001000446c3 
> traffic_server`::_TSReleaseAssert(text="arg_idx >= 0 && arg_idx < 
> HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 35 at InkAPI.cc:396
> frame #6: 0x000100054e0f 
> traffic_server`::TSHttpTxnArgGet(txnp=0x05d6b200, arg_idx=-1) + 111 
> at InkAPI.cc:5881
> frame #7: 0x0579bb9b 
> libatscppapi.7.dylib`atscppapi::utils::internal::getTransaction(ats_txn_handle=0x05d6b200)
>  + 27 at utils_internal.cc:159
> frame #8: 0x057bba8c 
> libatscppapi.7.dylib`::TSRemapDoRemap(ih=0x00759fe0, 
> rh=0x05d6b200, rri=0x7058df08) + 108 at RemapPlugin.cc:35
> frame #9: 0x0001001cb79e 
> traffic_server`RemapPlugins::run_plugin(this=0x7058e0e8, 
> plugin=0x00759f90) + 350 at RemapPlugins.cc:75
> frame #10: 0x0001001cb9c3 
> traffic_server`RemapPlugins::run_single_remap(this=0x7058e0e8) + 435 
> at RemapPlugins.cc:111
> ...
> {noformat}
> Second, Remap Plugin remains an another issue if we simply revert 
> https://github.com/apache/trafficserver/commit/17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85.
>  Objects of atscppapi::Transaction is created correctly at utils_internal.cc, 
> but its destructor is never called.
> {noformat}
> # Revert and rebuild ATS
> $ git revert 17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85 --no-commit
> ...
> $ make && make install
> {noformat}
> {noformat}
> $ lldb /path/to/traffic_server
> ...
> (lldb) r
> ...
> # It can pass the assertion! but ...
> (lldb) b -M ~Transaction
> (lldb) r
> # atscppapi::Transaction::~Transaction() is called.
> {noformat}



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

[GitHub] trafficserver pull request #1034: TS-4880: Fix missing missing utils::intern...

[syucream]

GitHub user syucream opened a pull request:

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

TS-4880: Fix missing missing utils::internal::initTransactionManagement() 
call

https://issues.apache.org/jira/browse/TS-4880

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

$ git pull https://github.com/syucream/trafficserver TS-4880

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

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


commit cced5de168e28e59013c6455c54fa2f7e65a3d78
Author: Ryo Okubo 
Date:   2016-09-19T07:47:12Z

TS-4880: Fix missing missing utils::internal::initTransactionManagement() 
call




---
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] [Created] (TS-4880) RemapPlugin class doesn't work correctly

[Ryo Okubo (JIRA)]

Ryo Okubo created TS-4880:
-

 Summary: RemapPlugin class doesn't work correctly
 Key: TS-4880
 URL: https://issues.apache.org/jira/browse/TS-4880
 Project: Traffic Server
  Issue Type: Bug
  Components: CPP API
Reporter: Ryo Okubo
Assignee: Brian Geffon


Current atscppapi::RemapPlugin has two issues. These seem to be caused by 
missing utils::internal::initTransactionManagement() call.

First, after TS-4555, plugins uses RemapPlugin class doesn't work because it 
can't pass an assertion.

{noformat}
# my remap.config. It uses RemapPlugin, one of atscppapi examples.
map / http://127.0.0.1:80/ @plugin=RemapPlugin.so
{noformat}

{noformat}
$ lldb /path/to/traffic_server
...
(lldb) r
...
(lldb) bt
...
* thread #7: tid = 0x3ce4eef, 0x7fff886d0f06 
libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 4]', stop reason = 
signal SIGABRT
  * frame #0: 0x7fff886d0f06 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff91d6b4ec libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff902b56df libsystem_c.dylib`abort + 129
frame #3: 0x00039799 
libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") + 
361 at ink_error.cc:79
frame #4: 0x0003703f 
libtsutil.7.dylib`::_ink_assert(expression="arg_idx >= 0 && arg_idx < 
HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 47 at 
ink_assert.cc:37
frame #5: 0x0001000446c3 
traffic_server`::_TSReleaseAssert(text="arg_idx >= 0 && arg_idx < 
HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 35 at InkAPI.cc:396
frame #6: 0x000100054e0f 
traffic_server`::TSHttpTxnArgGet(txnp=0x05d6b200, arg_idx=-1) + 111 at 
InkAPI.cc:5881
frame #7: 0x0579bb9b 
libatscppapi.7.dylib`atscppapi::utils::internal::getTransaction(ats_txn_handle=0x05d6b200)
 + 27 at utils_internal.cc:159
frame #8: 0x057bba8c 
libatscppapi.7.dylib`::TSRemapDoRemap(ih=0x00759fe0, 
rh=0x05d6b200, rri=0x7058df08) + 108 at RemapPlugin.cc:35
frame #9: 0x0001001cb79e 
traffic_server`RemapPlugins::run_plugin(this=0x7058e0e8, 
plugin=0x00759f90) + 350 at RemapPlugins.cc:75
frame #10: 0x0001001cb9c3 
traffic_server`RemapPlugins::run_single_remap(this=0x7058e0e8) + 435 at 
RemapPlugins.cc:111
...
{noformat}

Second, Remap Plugin remains an another issue if we simply revert 
https://github.com/apache/trafficserver/commit/17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85.
 Objects of atscppapi::Transaction is created correctly at utils_internal.cc, 
but its destructor is never called.

{noformat}
# Revert and rebuild ATS
$ git revert 17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85 --no-commit
...
$ make && make install
{noformat}

{noformat}
$ lldb /path/to/traffic_server
...
(lldb) r
...
# It can pass the assertion! but ...

(lldb) b -M ~Transaction
(lldb) r
# atscppapi::Transaction::~Transaction() is called.
{noformat}



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

[jira] [Work logged] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1033
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/833/ for details.
 



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/833/ 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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/729/ 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-2258) Verify that all fields are correct in RecordsConfig.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 29291)
Time Spent: 6h 50m  (was: 6h 40m)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[jira] [Work logged] (TS-2258) Verify that all fields are correct in RecordsConfig.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 29290)
Time Spent: 6h 40m  (was: 6.5h)

> Verify that all fields are correct in RecordsConfig.cc
> --
>
> Key: TS-2258
> URL: https://issues.apache.org/jira/browse/TS-2258
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 6h 40m
>  Remaining Estimate: 0h
>
> We should go through every configuration in RecordsConfig.cc, and assure that 
> fields such as if it's dynamically reloadable or not, validation regexes etc. 
> are all set 100% correct.
> Once this file is accurate, and will be the one true authoritative source for 
> everything "configuration"; it can be used for command line help (e.g. 
> traffic_line can say if a config is reloadable), and we can even use it as a 
> source for the Sphinx documentation.
> A bonus would be to add a one-line helper line for each configuration in 
> RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new 
> type of tools to help managing configurations.



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

[GitHub] trafficserver issue #887: TS-2258: Mark whether configs are reloadable (part...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/832/ 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 #887: TS-2258: Mark whether configs are reloadable (part...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/887
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/728/ 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-4705) Proposal: NetVC Context

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/753
  
bugfix: In do_blocking_accept(), we should check the con.fd == NO_FD while 
we get return from check_emergency_throttle().


Issue Time Tracking
---

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

> Proposal: NetVC Context
> ---
>
> Key: TS-4705
> URL: https://issues.apache.org/jira/browse/TS-4705
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Goal 1st:
> In the NetVConnection, we have get_local_addr() and get_remote_addr() methods.
> Also have members local_addr, remote_addr and netvc->con.addr.
> Thus, we should using netvc->con.addr or remote_addr to replace member 
> server_addr in UnixNetVConnection.
> Goal 2nd:
> SSLNetVConnection has member sslClientConnection with 2 methods 
> setSSLClientConnection() and getSSLClientConnection() to indictor ATS is a 
> client or server in a SSL session.
> To abstract above two goals, I'm design the netvc context function.
> As a proxy, there has two side: client side ( Client <-> Proxy ) and server 
> side ( Proxy <-> Server ). With the netvc context funtion to indicate which 
> side the NetVC working on.
> Goal 3rd:
> Fix a minor bug in NetAccept::do_blocking_accept, call to 
> check_emergency_throttle(con) first then allocate vc.
> Goal 4th:
> NetAccept Optimize, remove dup code, etc...



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

[GitHub] trafficserver issue #753: TS-4705: Proposal: NetVC Context

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/753
  
bugfix: In do_blocking_accept(), we should check the con.fd == NO_FD while 
we get return from check_emergency_throttle().


---
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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/831/ 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-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> NetVC leaks while hyper emergency occur on check_emergency_throttle()
> -
>
> Key: TS-4879
> URL: https://issues.apache.org/jira/browse/TS-4879
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The con could be closed if hyper emergency occur on 
> check_emergency_throttle().
> But we did not check the con.fd while we get return from 
> check_emergency_throttle().
> For hyper emergency:
> - The socket fd is removed from epoll while it is closed.
> - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to 
> SM.
> Thus:
> - The NetVC will never triggered by NetHandler.
> - Only InactivityCop could handle the NetVC and the default timeout value is 
> 86400 secs.
> For the counter: net_connections_currently_open_stat
> - It is increased in “connect_re_internal()”
> - It isn't decreased while the con.fd set to NO_FD due to hyper emergency 
> - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. 
> (TS-4178)



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

[GitHub] trafficserver issue #1033: TS-4879: Checking con.fd == NO_FD while we get re...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1033
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/727/ 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.
---