date:20160915

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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 16/Sep/16 05:24
Start Date: 16/Sep/16 05:24
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/716/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29230)
Time Spent: 6h 20m  (was: 6h 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
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 6h 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...

2016-09-15 Thread 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/716/ 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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 16/Sep/16 05:24
Start Date: 16/Sep/16 05:24
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/820/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29229)
Time Spent: 6h 10m  (was: 6h)

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

2016-09-15 Thread 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/820/ 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.
---

Jenkins build is back to normal : ubuntu_14_04-master » gcc,ubuntu_14_04,debug #2229

2016-09-15 Thread jenkins

See

Build failed in Jenkins: ubuntu_14_04-master » gcc,ubuntu_14_04,debug #2228

2016-09-15 Thread jenkins

See 


--
[...truncated 19563 lines...]
*** TEST 56 *** STARTING ***
*** TEST 56 *** PASSED ***
*** TEST 57 *** STARTING ***
*** TEST 57 *** PASSED ***
*** TEST 58 *** STARTING ***
*** TEST 58 *** PASSED ***
*** TEST 59 *** STARTING ***
*** TEST 59 *** PASSED ***
*** TEST 60 *** STARTING ***
*** TEST 60 *** PASSED ***
*** TEST 61 *** STARTING ***
*** TEST 61 *** PASSED ***
*** TEST 62 *** STARTING ***
*** TEST 62 *** PASSED ***
*** TEST 63 *** STARTING ***
*** TEST 63 *** PASSED ***
*** TEST 64 *** STARTING ***
*** TEST 64 *** PASSED ***
*** TEST 65 *** STARTING ***
*** TEST 65 *** PASSED ***
*** TEST 66 *** STARTING ***
*** TEST 66 *** PASSED ***
*** TEST 67 *** STARTING ***
*** TEST 67 *** PASSED ***
*** TEST 68 *** STARTING ***
*** TEST 68 *** PASSED ***
*** TEST 69 *** STARTING ***
*** TEST 69 *** PASSED ***
*** TEST 70 *** STARTING ***
*** TEST 70 *** PASSED ***
*** TEST 71 *** STARTING ***
*** TEST 71 *** PASSED ***
*** TEST 72 *** STARTING ***
*** TEST 72 *** PASSED ***
*** TEST 73 *** STARTING ***
*** TEST 73 *** PASSED ***
*** TEST 74 *** STARTING ***
*** TEST 74 *** PASSED ***
*** TEST 75 *** STARTING ***
*** TEST 75 *** PASSED ***
*** TEST 76 *** STARTING ***
*** TEST 76 *** PASSED ***
*** TEST 77 *** STARTING ***
*** TEST 77 *** PASSED ***
*** TEST 78 *** STARTING ***
*** TEST 78 *** PASSED ***
*** TEST 79 *** STARTING ***
*** TEST 79 *** PASSED ***
*** TEST 80 *** STARTING ***
*** TEST 80 *** PASSED ***
*** TEST 81 *** STARTING ***
*** TEST 81 *** PASSED ***
*** TEST 82 *** STARTING ***
*** TEST 82 *** PASSED ***
*** TEST 83 *** STARTING ***
*** TEST 83 *** PASSED ***
*** TEST 84 *** STARTING ***
*** TEST 84 *** PASSED ***
*** TEST 85 *** STARTING ***
*** TEST 85 *** PASSED ***
*** TEST 86 *** STARTING ***
*** TEST 86 *** PASSED ***
*** TEST 87 *** STARTING ***
*** TEST 87 *** PASSED ***
*** TEST 88 *** STARTING ***
*** TEST 88 *** PASSED ***
*** TEST 89 *** STARTING ***
*** TEST 89 *** PASSED ***
*** TEST 90 *** STARTING ***
*** TEST 90 *** PASSED ***
*** TEST 91 *** STARTING ***
*** TEST 91 *** PASSED ***
*** TEST 92 *** STARTING ***
*** TEST 92 *** PASSED ***
*** TEST 93 *** STARTING ***
*** TEST 93 *** PASSED ***
*** TEST 94 *** STARTING ***
*** TEST 94 *** PASSED ***
*** TEST 95 *** STARTING ***
*** TEST 95 *** PASSED ***
*** TEST 96 *** STARTING ***
*** TEST 96 *** PASSED ***
*** TEST 97 *** STARTING ***
*** TEST 97 *** PASSED ***
*** TEST 98 *** STARTING ***
*** TEST 98 *** PASSED ***
*** TEST 99 *** STARTING ***
*** TEST 99 *** PASSED ***
*** TEST 100 *** STARTING ***
*** TEST 100 *** PASSED ***
*** TEST 101 *** STARTING ***
*** TEST 101 *** PASSED ***
*** TEST 102 *** STARTING ***
*** TEST 102 *** PASSED ***
*** TEST 103 *** STARTING ***
*** TEST 103 *** PASSED ***
*** TEST 104 *** STARTING ***
*** TEST 104 *** PASSED ***
*** TEST 105 *** STARTING ***
*** TEST 105 *** PASSED ***
*** TEST 106 *** STARTING ***
*** TEST 106 *** PASSED ***
*** TEST 107 *** STARTING ***
*** TEST 107 *** PASSED ***
*** TEST 108 *** STARTING ***
*** TEST 108 *** PASSED ***
*** TEST 109 *** STARTING ***
*** TEST 109 *** PASSED ***
*** TEST 110 *** STARTING ***
*** TEST 110 *** PASSED ***
*** TEST 111 *** STARTING ***
*** TEST 111 *** PASSED ***
*** TEST 112 *** STARTING ***
*** TEST 112 *** PASSED ***
*** TEST 113 *** SREGRESSION_RESULT PARENTSELECTION:
  PASSED
REGRESSION_TEST DONE: FAILED
TARTING ***
*** TEST 113 *** PASSED ***
*** TEST 114 *** STARTING ***
*** TEST 114 *** PASSED ***
*** TEST 115 *** STARTING ***
*** TEST 115 *** PASSED ***
*** TEST 116 *** STARTING ***
*** TEST 116 *** PASSED ***
*** TEST 117 *** STARTING ***
*** TEST 117 *** PASSED ***
*** TEST 118 *** STARTING ***
*** TEST 118 *** PASSED ***
*** TEST 119 *** STARTING ***
*** TEST 119 *** PASSED ***
*** TEST 120 *** STARTING ***
*** TEST 120 *** PASSED ***
*** TEST 121 *** STARTING ***
*** TEST 121 *** PASSED ***
*** TEST 122 *** STARTING ***
*** TEST 122 *** PASSED ***
*** TEST 123 *** STARTING ***
*** TEST 123 *** PASSED ***
*** TEST 124 *** STARTING ***
*** TEST 124 *** PASSED ***
*** TEST 125 *** STARTING ***
*** TEST 125 *** PASSED ***
*** TEST 126 *** STARTING ***
*** TEST 126 *** PASSED ***
*** TEST 127 *** STARTING ***
*** TEST 127 *** PASSED ***
*** TEST 128 *** STARTING ***
*** TEST 128 *** PASSED ***
*** TEST 129 *** STARTING ***
*** TEST 129 *** PASSED ***
*** TEST 130 *** STARTING ***
*** TEST 130 *** PASSED ***
*** TEST 131 *** STARTING ***
*** TEST 131 *** PASSED ***
*** TEST 132 *** STARTING ***
*** TEST 132 *** PASSED ***
*** TEST 133 *** STARTING ***
*** TEST 133 *** PASSED ***
*** TEST 134 *** STARTING ***
*** TEST 134 *** PASSED ***
*** TEST 135 *** STARTING ***
*** TEST 135 *** PASSED ***
*** TEST 136 *** STARTING ***
*** TEST 136 *** PASSED ***
*** TEST 137 *** STARTING ***
*** TEST 137 *** PASSED ***
*** TEST 138 *** STARTING ***
*** TEST

[jira] [Work logged] (TS-4868) Latest master requires config value in file

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1022#discussion_r79086248
  
--- Diff: mgmt/RecordsConfig.cc ---
@@ -834,6 +860,61 @@ static const RecordElement RecordsConfig[] =
 
   
//##
   //#
+  //# Cluster Subsystem
+  //#
+  
//##
+  {RECT_CONFIG, "proxy.config.cluster.threads", RECD_INT, "1", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-512]", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_port", RECD_INT, "8086", 
RECU_RESTART_TS, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_configuration", RECD_STRING, 
"cluster.config", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ethernet_interface", RECD_STRING, 
TS_BUILD_DEFAULT_LOOPBACK_IFACE, RECU_RESTART_TS, RR_REQUIRED, RECC_STR, 
"^[^[:space:]]*$", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.enable_monitor", RECD_INT, "0", 
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.monitor_interval_secs", RECD_INT, 
"1", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.send_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.receive_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_option_flag", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_mark", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_tos", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.rpc_cache_cluster", RECD_INT, "0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+
+  //##
+  //# Cluster interconnect load monitoring configuration options.
+  //# Internal use only
+  //##
+  //# load monitor_enabled: -1 = compute only, 0 = disable, 1 = compute 
and act
+  {RECT_CONFIG, "proxy.config.cluster.load_monitor_enabled", RECD_INT, 
"1", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_send_interval_msecs", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_response_buckets", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.msecs_per_ping_response_bucket", 
RECD_INT, "50", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_latency_threshold_msecs", 
RECD_INT, "500", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.load_compute_interval_msecs", 
RECD_INT, "5000", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.periodic_timer_interval_msecs", 
RECD_INT, "100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_history_buf_length", RECD_INT, 
"120", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_clear_duration", 
RECD_INT, "24", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_exceed_duration", 
RECD_INT, "4", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
--- End diff --

There is a bunch of code that asserts on the existence. And the more we dig 
into it the more you have to remove, ala #966. This broke `traffic_cop` and 
`traffic_manager` without these configs.


Issue Time Tracking
---

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

> Latest master requires config value in file
> ---
>
> Key: TS-4868
> URL: https://issues.apache.org/jira/browse/TS-4868
> Project:

[GitHub] trafficserver pull request #1022: TS-4868: Add configs back and cleanup othe...

2016-09-15 Thread PSUdaemon

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

https://github.com/apache/trafficserver/pull/1022#discussion_r79086248
  
--- Diff: mgmt/RecordsConfig.cc ---
@@ -834,6 +860,61 @@ static const RecordElement RecordsConfig[] =
 
   
//##
   //#
+  //# Cluster Subsystem
+  //#
+  
//##
+  {RECT_CONFIG, "proxy.config.cluster.threads", RECD_INT, "1", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-512]", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_port", RECD_INT, "8086", 
RECU_RESTART_TS, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_configuration", RECD_STRING, 
"cluster.config", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ethernet_interface", RECD_STRING, 
TS_BUILD_DEFAULT_LOOPBACK_IFACE, RECU_RESTART_TS, RR_REQUIRED, RECC_STR, 
"^[^[:space:]]*$", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.enable_monitor", RECD_INT, "0", 
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.monitor_interval_secs", RECD_INT, 
"1", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.send_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.receive_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_option_flag", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_mark", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_tos", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.rpc_cache_cluster", RECD_INT, "0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+
+  //##
+  //# Cluster interconnect load monitoring configuration options.
+  //# Internal use only
+  //##
+  //# load monitor_enabled: -1 = compute only, 0 = disable, 1 = compute 
and act
+  {RECT_CONFIG, "proxy.config.cluster.load_monitor_enabled", RECD_INT, 
"1", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_send_interval_msecs", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_response_buckets", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.msecs_per_ping_response_bucket", 
RECD_INT, "50", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_latency_threshold_msecs", 
RECD_INT, "500", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.load_compute_interval_msecs", 
RECD_INT, "5000", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.periodic_timer_interval_msecs", 
RECD_INT, "100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_history_buf_length", RECD_INT, 
"120", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_clear_duration", 
RECD_INT, "24", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_exceed_duration", 
RECD_INT, "4", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
--- End diff --

There is a bunch of code that asserts on the existence. And the more we dig 
into it the more you have to remove, ala #966. This broke `traffic_cop` and 
`traffic_manager` without these configs.


---
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-4864) CID 1362769: Control flow issues (DEADCODE) in ink_thread.h

2016-09-15 Thread James Peach (JIRA)


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

James Peach resolved TS-4864.
-
Resolution: Fixed

> CID 1362769:  Control flow issues  (DEADCODE) in ink_thread.h
> -
>
> Key: TS-4864
> URL: https://issues.apache.org/jira/browse/TS-4864
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Nathan Garabedian
>  Labels: Coverity
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Filing this just in case, but maybe Nathan's fixes around this is where to go 
> ?
> {code}
> *** CID 1362769:  Control flow issues  (DEADCODE)
> /lib/ts/ink_thread.h: 160 in ink_thread_create(void *(*)(void *), void *, 
> int, unsigned long, void *)()
> 154   pthread_attr_destroy();
> 155 
> 156   /**
> 157* Fix for INKqa10118.
> 158* If the thread has not been created successfully return 0.
> 159*/
>CID 1362769:  Control flow issues  (DEADCODE)
>Execution cannot reach the expression "0UL" inside this statement: "return 
> ret ? 0UL : t;".
> 160   return ret ? (ink_thread)0 : t;
> 161 }
> 162 
> 163 static inline void
> 164 ink_thread_cancel(ink_thread who)
> 165 {
> {code}



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

[jira] [Work logged] (TS-4864) CID 1362769: Control flow issues (DEADCODE) in ink_thread.h

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> CID 1362769:  Control flow issues  (DEADCODE) in ink_thread.h
> -
>
> Key: TS-4864
> URL: https://issues.apache.org/jira/browse/TS-4864
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Nathan Garabedian
>  Labels: Coverity
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Filing this just in case, but maybe Nathan's fixes around this is where to go 
> ?
> {code}
> *** CID 1362769:  Control flow issues  (DEADCODE)
> /lib/ts/ink_thread.h: 160 in ink_thread_create(void *(*)(void *), void *, 
> int, unsigned long, void *)()
> 154   pthread_attr_destroy();
> 155 
> 156   /**
> 157* Fix for INKqa10118.
> 158* If the thread has not been created successfully return 0.
> 159*/
>CID 1362769:  Control flow issues  (DEADCODE)
>Execution cannot reach the expression "0UL" inside this statement: "return 
> ret ? 0UL : t;".
> 160   return ret ? (ink_thread)0 : t;
> 161 }
> 162 
> 163 static inline void
> 164 ink_thread_cancel(ink_thread who)
> 165 {
> {code}



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

[GitHub] trafficserver pull request #1021: TS-4864 CID 1362769 - when pthread_create ...

2016-09-15 Thread jpeach

Github user jpeach closed the pull request at:

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


---
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-4864) CID 1362769: Control flow issues (DEADCODE) in ink_thread.h

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1021
  
jpeach: I made the suggested modification.  Tests good, also tested with 
ret=1 to see how the error would print and that works as expected.


Issue Time Tracking
---

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

> CID 1362769:  Control flow issues  (DEADCODE) in ink_thread.h
> -
>
> Key: TS-4864
> URL: https://issues.apache.org/jira/browse/TS-4864
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Nathan Garabedian
>  Labels: Coverity
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Filing this just in case, but maybe Nathan's fixes around this is where to go 
> ?
> {code}
> *** CID 1362769:  Control flow issues  (DEADCODE)
> /lib/ts/ink_thread.h: 160 in ink_thread_create(void *(*)(void *), void *, 
> int, unsigned long, void *)()
> 154   pthread_attr_destroy();
> 155 
> 156   /**
> 157* Fix for INKqa10118.
> 158* If the thread has not been created successfully return 0.
> 159*/
>CID 1362769:  Control flow issues  (DEADCODE)
>Execution cannot reach the expression "0UL" inside this statement: "return 
> ret ? 0UL : t;".
> 160   return ret ? (ink_thread)0 : t;
> 161 }
> 162 
> 163 static inline void
> 164 ink_thread_cancel(ink_thread who)
> 165 {
> {code}



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

[GitHub] trafficserver issue #1021: TS-4864 CID 1362769 - when pthread_create fails, ...

2016-09-15 Thread ngara

Github user ngara commented on the issue:

https://github.com/apache/trafficserver/pull/1021
  
jpeach: I made the suggested modification.  Tests good, also tested with 
ret=1 to see how the error would print and that works as expected.


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

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1029
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/715/ 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 #1029: Add a stub CONTRIBUTING file.

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1029
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/819/ 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.
---

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

2016-09-15 Thread jenkins

See

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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver pull request #749: TS-4506 Don't remove Expires/Last-Modifed o...

2016-09-15 Thread zwoop

Github user zwoop closed the pull request at:

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


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

2016-09-15 Thread jpeach

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1029
  
I'm leaving this PR here so people can experiment with the GitHub review 
features. Feel free to merge or discard when you are 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.
---

[GitHub] trafficserver pull request #1029: Add a stub CONTRIBUTING file.

2016-09-15 Thread jpeach

GitHub user jpeach opened a pull request:

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

Add a stub CONTRIBUTING file.



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

$ git pull https://github.com/jpeach/trafficserver contributing

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

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


commit 2e002a4a5ee89218771133d3166a51dd199cdd9d
Author: James Peach 
Date:   2016-09-15T22:26:51Z

Add a stub CONTRIBUTING file.




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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 22:27
Start Date: 15/Sep/16 22:27
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_r79075679
  
--- Diff: iocore/cache/P_CacheDisk.h ---
@@ -97,6 +97,7 @@ struct CacheDisk : public Continuation {
   int num_errors;
   int cleared;
   bool read_only_p;
+  bool offline; /* flag marking cache disk offline (because of too many 
failures or by the operator). */
--- End diff --

This is another review tests (per jpeach's request). "Start a review"



Issue Time Tracking
---

Worklog Id: (was: 29222)
Time Spent: 50m  (was: 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: 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)

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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 22:26
Start Date: 15/Sep/16 22:26
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_r79075616
  
--- Diff: iocore/cache/P_CacheDisk.h ---
@@ -97,6 +97,7 @@ struct CacheDisk : public Continuation {
   int num_errors;
   int cleared;
   bool read_only_p;
+  bool offline; /* flag marking cache disk offline (because of too many 
failures or by the operator). */
--- End diff --

This is another review tests (per jpeach's request). "Add single comment"


Issue Time Tracking
---

Worklog Id: (was: 29221)
Time Spent: 40m  (was: 0.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: 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...

2016-09-15 Thread gtenev

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

https://github.com/apache/trafficserver/pull/1028#discussion_r79075679
  
--- Diff: iocore/cache/P_CacheDisk.h ---
@@ -97,6 +97,7 @@ struct CacheDisk : public Continuation {
   int num_errors;
   int cleared;
   bool read_only_p;
+  bool offline; /* flag marking cache disk offline (because of too many 
failures or by the operator). */
--- End diff --

This is another review tests (per jpeach's request). "Start a review"



---
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 #1028: TS-4870 Avoid marking storage offline mult...

2016-09-15 Thread gtenev

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

https://github.com/apache/trafficserver/pull/1028#discussion_r79075616
  
--- Diff: iocore/cache/P_CacheDisk.h ---
@@ -97,6 +97,7 @@ struct CacheDisk : public Continuation {
   int num_errors;
   int cleared;
   bool read_only_p;
+  bool offline; /* flag marking cache disk offline (because of too many 
failures or by the operator). */
--- End diff --

This is another review tests (per jpeach's request). "Add single comment"


---
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-4868) Latest master requires config value in file

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> Latest master requires config value in file
> ---
>
> Key: TS-4868
> URL: https://issues.apache.org/jira/browse/TS-4868
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> <1473896704.> [FATAL]: could not find integer variable 
> proxy.local.cluster.type in records.config
> This is a regression. Our configuration system allows for defaults to be 
> defined. records.config needs to stay optional.



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

[GitHub] trafficserver pull request #1022: TS-4868: Add configs back and cleanup othe...

2016-09-15 Thread PSUdaemon

Github user PSUdaemon closed the pull request at:

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


---
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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver pull request #1022: TS-4868: Add configs back and cleanup othe...

2016-09-15 Thread bryancall

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

https://github.com/apache/trafficserver/pull/1022#discussion_r79073490
  
--- Diff: mgmt/RecordsConfig.cc ---
@@ -834,6 +860,61 @@ static const RecordElement RecordsConfig[] =
 
   
//##
   //#
+  //# Cluster Subsystem
+  //#
+  
//##
+  {RECT_CONFIG, "proxy.config.cluster.threads", RECD_INT, "1", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-512]", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_port", RECD_INT, "8086", 
RECU_RESTART_TS, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_configuration", RECD_STRING, 
"cluster.config", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ethernet_interface", RECD_STRING, 
TS_BUILD_DEFAULT_LOOPBACK_IFACE, RECU_RESTART_TS, RR_REQUIRED, RECC_STR, 
"^[^[:space:]]*$", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.enable_monitor", RECD_INT, "0", 
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.monitor_interval_secs", RECD_INT, 
"1", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.send_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.receive_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_option_flag", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_mark", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_tos", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.rpc_cache_cluster", RECD_INT, "0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+
+  //##
+  //# Cluster interconnect load monitoring configuration options.
+  //# Internal use only
+  //##
+  //# load monitor_enabled: -1 = compute only, 0 = disable, 1 = compute 
and act
+  {RECT_CONFIG, "proxy.config.cluster.load_monitor_enabled", RECD_INT, 
"1", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_send_interval_msecs", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_response_buckets", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.msecs_per_ping_response_bucket", 
RECD_INT, "50", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_latency_threshold_msecs", 
RECD_INT, "500", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.load_compute_interval_msecs", 
RECD_INT, "5000", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.periodic_timer_interval_msecs", 
RECD_INT, "100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_history_buf_length", RECD_INT, 
"120", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_clear_duration", 
RECD_INT, "24", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_exceed_duration", 
RECD_INT, "4", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
--- End diff --

Why do the configs need to be added back in?


---
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-4868) Latest master requires config value in file

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1022#discussion_r79073490
  
--- Diff: mgmt/RecordsConfig.cc ---
@@ -834,6 +860,61 @@ static const RecordElement RecordsConfig[] =
 
   
//##
   //#
+  //# Cluster Subsystem
+  //#
+  
//##
+  {RECT_CONFIG, "proxy.config.cluster.threads", RECD_INT, "1", 
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-512]", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_port", RECD_INT, "8086", 
RECU_RESTART_TS, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_configuration", RECD_STRING, 
"cluster.config", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ethernet_interface", RECD_STRING, 
TS_BUILD_DEFAULT_LOOPBACK_IFACE, RECU_RESTART_TS, RR_REQUIRED, RECC_STR, 
"^[^[:space:]]*$", RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.enable_monitor", RECD_INT, "0", 
RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.monitor_interval_secs", RECD_INT, 
"1", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.send_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.receive_buffer_size", RECD_INT, 
"10485760", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_option_flag", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_mark", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.sock_packet_tos", RECD_INT, "0x0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.rpc_cache_cluster", RECD_INT, "0", 
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+
+  //##
+  //# Cluster interconnect load monitoring configuration options.
+  //# Internal use only
+  //##
+  //# load monitor_enabled: -1 = compute only, 0 = disable, 1 = compute 
and act
+  {RECT_CONFIG, "proxy.config.cluster.load_monitor_enabled", RECD_INT, 
"1", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_send_interval_msecs", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_response_buckets", RECD_INT, 
"100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.msecs_per_ping_response_bucket", 
RECD_INT, "50", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_latency_threshold_msecs", 
RECD_INT, "500", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.load_compute_interval_msecs", 
RECD_INT, "5000", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.periodic_timer_interval_msecs", 
RECD_INT, "100", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.ping_history_buf_length", RECD_INT, 
"120", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_clear_duration", 
RECD_INT, "24", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
+  {RECT_CONFIG, "proxy.config.cluster.cluster_load_exceed_duration", 
RECD_INT, "4", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+  ,
--- End diff --

Why do the configs need to be added back in?


Issue Time Tracking
---

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

> Latest master requires config value in file
> ---
>
> Key: TS-4868
> URL: https://issues.apache.org/jira/browse/TS-4868
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Phil Sorber
>Priority: Blocker
>

[GitHub] trafficserver pull request #1025: TS-4872: Fix clang-analyzer leak error on ...

2016-09-15 Thread jpeach

Github user jpeach closed the pull request at:

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


---
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-3915) Regression fails when compilied with ASAN, heap-use-after-free

2016-09-15 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-3915:
---
Affects Version/s: 7.0.0

> Regression fails when compilied with ASAN, heap-use-after-free
> --
>
> Key: TS-3915
> URL: https://issues.apache.org/jira/browse/TS-3915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: ASAN, crash
> Fix For: 7.0.0
>
>
> Running regression with asan enable on Fedora 22:
> {code}
> CXXFLAGS="-Werror -fno-omit-frame-pointer -fsanitize=address" 
> CFLAGS="-Werror" SPDYLAY_CFLAGS="-I /usr/local/include/" 
> SPDYLAY_LIBS="-L/usr/local/lib -lspdylay"  ./configure --enable-ccache 
> --enable-spdy --disable-freelist
> REGRESSION TEST SDK_API_HttpTxnTransform started
> Regression test(SDK_API_HttpTxnTransform) still in progress
> [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnUntransformedResponseCache : [TestCase1] 
> <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformedResponseCache : [TestCase1] 
> <> { ok }
> =
> ==14340==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x60800d59276b at pc 0x005cb466 bp 0x7f4f46b88b40 sp 0x7f4f46b88b30
> READ of size 1 at 0x60800d59276b thread T9 ([ET_NET 8])
> #0 0x5cb465 in transformtest_transform 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6318
> #1 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #2 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #3 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #4 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #5 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> #6 0x7f4f4c9bcb9c in __clone (/lib64/libc.so.6+0x102b9c)
> 0x60800d59276b is located 75 bytes inside of 96-byte region 
> [0x60800d592720,0x60800d592780)
> freed by thread T4 ([ET_NET 3]) here:
> #0 0x7f4f4fb2470a in __interceptor_free (/lib64/libasan.so.2+0x9870a)
> #1 0x5de815 in transform_hook_handler 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6637
> #2 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #3 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #4 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #5 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #6 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> previously allocated by thread T0 ([ET_NET 0]) here:
> #0 0x7f4f4fb24a0a in malloc (/lib64/libasan.so.2+0x98a0a)
> #1 0x7f4f4f859ae5 in ats_malloc 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:54
> #2 0x5d3d2a in RegressionTest_SDK_API_HttpTxnTransform(RegressionTest*, 
> int, int*) /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6663
> #3 0x7f4f4f844f69 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:78
> #4 0x7f4f4f844f69 in RegressionTest::run_some() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:126
> #5 0x7f4f4f845366 in RegressionTest::check_status() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:141
> #6 0x563773 in RegressionCont::mainEvent(int, Event*) 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1210
> #7 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #8 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #9 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #10 0x497d2c in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1812
> #11 0x7f4f4c8da6ff in __libc_start_main (/lib64/libc.so.6+0x206ff)
> Thread T9 ([ET_NET 8]) created by T0 ([ET_NET 0]) here:
> #0 0x7f4f4fac2703

[jira] [Updated] (TS-4541) SEGV in send_a_data_frame with HTTP/2 (possibly ASAN mutex)

2016-09-15 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-4541:
---
Affects Version/s: 7.0.0

> SEGV in send_a_data_frame with HTTP/2 (possibly ASAN  mutex)
> 
>
> Key: TS-4541
> URL: https://issues.apache.org/jira/browse/TS-4541
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Critical
>  Labels: A, ASAN, crash
> Fix For: 7.0.0
>
>
> {code}
> ==26628==ERROR: AddressSanitizer: SEGV on unknown address 0x0038 (pc 
> 0x009ad1b9 sp 0x2b7e55d79740 bp 0x2b7e55d7d8f0 T15)
> #0 0x9ad1b8 in Mutex_lock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 0x9ad1b8 in MutexLock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 0x9ad1b8 in Http2ConnectionState::send_a_data_frame(Http2Stream*, 
> unsigned long&) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1040
> #3 0x9af71d in 
> Http2ConnectionState::send_data_frames_depends_on_priority() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x9b1ff9 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0xe9f5e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xe9f5e3 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0xea18c9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b7e4d575aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #10 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Updated] (TS-4192) Coredump in HPACK encoding

2016-09-15 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-4192:
---
Affects Version/s: (was: 6.1.1)
   7.0.0

> Coredump in HPACK encoding
> --
>
> Key: TS-4192
> URL: https://issues.apache.org/jira/browse/TS-4192
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 7.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Blocker
>  Labels: crash
> Fix For: 7.0.0
>
>
> {code}
> #0  0x00972f44 in mime_hdr_field_detach (mh=0x61d002955508, 
> field=0x629002954de8, detach_all_dups=) at MIME.cc:1582
> name_length = 
> prev = 0x0
> first = 
> next_dup = 
> #1  0x00976daa in mime_hdr_field_delete (heap=0x61d002955480, 
> mh=0x61d002955508, field=field@entry=0x629002954de8, 
> delete_all_dups=delete_all_dups@entry=false) at MIME.cc:1631
> No locals.
> #2  0x00844c6d in field_delete (delete_all_dups=false, 
> field=0x629002954de8, this=) at ../../proxy/hdrs/MIME.h:1169
> No locals.
> #3  Http2DynamicTable::add_header_field (this=0x607000fa8b60, 
> field=) at HPACK.cc:307
> last_field = 0x629002954de8
> new_field = 0x629002954de8
> name = 0x62809e18 "Via"
> value = 0x625009705142 "http/1.0 c1.ycs.ne1.yahoo.com 
> (ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
> (ApacheTrafficServer [cRs f ])\r\nServer: ATS\r\nConnection: 
> keep-alive\r\n\r\n", '\276' ...
> header_size = 
> #4  0x00845112 in add_header_field_to_dynamic_table (field= out>, this=) at HPACK.cc:253
> No locals.
> #5  encode_literal_header_field_with_indexed_name 
> (buf_start=buf_start@entry=0x7fffedda2487 , 
> buf_end=buf_end@entry=0x7fffedda6437 "", header=...,
> index=, indexing_table=..., 
> type=type@entry=HPACK_FIELD_INDEXED_LITERAL) at HPACK.cc:527
> p = 0x7fffedda2487 
> len = 
> prefix = 0 '\000'
> flag = 0 '\000'
> value = 
> __FUNCTION__ = "encode_literal_header_field_with_indexed_name"
> #6  0x0080a8ca in http2_write_header_field 
> (out=out@entry=0x7fffedda2487 , 
> end=end@entry=0x7fffedda6437 "", header=..., indexing_table=...) at 
> HTTP2.cc:509
> field_type = HPACK_FIELD_INDEXED_LITERAL
> name = 
> #7  0x0080c616 in http2_write_header_fragment 
> (in=in@entry=0x61634340, field_iter=..., out=out@entry=0x7fffedda2441 
> "\354l\226\320z\276\224\020T\276R( \005\265",
> out_len=out_len@entry=16374, indexing_table=..., cont=@0x7fffedda2300: 
> false) at HTTP2.cc:592
> name = 0x62809e18 "Via"
> p = 0x7fffedda2487 
> end = 0x7fffedda6437 ""
> len = 
> field = 0x61d0052550a8
> #8  0x008272a0 in Http2ConnectionState::send_headers_frame 
> (this=this@entry=0x61818ee8, fetch_sm=) at 
> Http2ConnectionState.cc:1009
> type = HTTP2_FRAME_TYPE_HEADERS
> __FUNCTION__ = "send_headers_frame"
> buf_len = 16375
> payload_length = 
> flags = 0 '\000'
> stream = 0x60f3e890
> resp_header = 0x61634340
> #9  0x008388db in Http2ConnectionState::main_event_handler 
> (this=0x61818ee8, event=-2, edata=) at 
> Http2ConnectionState.cc:779
> fetch_sm = 
> __FUNCTION__ = "main_event_handler"
> {code}



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

[jira] [Updated] (TS-4541) SEGV in send_a_data_frame with HTTP/2 (possibly ASAN mutex)

2016-09-15 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-4541:
---
Labels: A ASAN crash  (was: A ASAN)

> SEGV in send_a_data_frame with HTTP/2 (possibly ASAN  mutex)
> 
>
> Key: TS-4541
> URL: https://issues.apache.org/jira/browse/TS-4541
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Critical
>  Labels: A, ASAN, crash
> Fix For: 7.0.0
>
>
> {code}
> ==26628==ERROR: AddressSanitizer: SEGV on unknown address 0x0038 (pc 
> 0x009ad1b9 sp 0x2b7e55d79740 bp 0x2b7e55d7d8f0 T15)
> #0 0x9ad1b8 in Mutex_lock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:381
> #1 0x9ad1b8 in MutexLock 
> ../../../trafficserver/iocore/eventsystem/I_Lock.h:449
> #2 0x9ad1b8 in Http2ConnectionState::send_a_data_frame(Http2Stream*, 
> unsigned long&) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1040
> #3 0x9af71d in 
> Http2ConnectionState::send_data_frames_depends_on_priority() 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:1000
> #4 0x9b1ff9 in Http2ConnectionState::main_event_handler(int, void*) 
> ../../../trafficserver/proxy/http2/Http2ConnectionState.cc:803
> #5 0xe9f5e3 in Continuation::handleEvent(int, void*) 
> ../../../trafficserver/iocore/eventsystem/I_Continuation.h:153
> #6 0xe9f5e3 in EThread::process_event(Event*, int) 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:148
> #7 0xea18c9 in EThread::execute() 
> ../../../trafficserver/iocore/eventsystem/UnixEThread.cc:202
> #8 0xe9e128 in spawn_thread_internal 
> ../../../trafficserver/iocore/eventsystem/Thread.cc:86
> #9 0x2b7e4d575aa0 in start_thread (/lib64/libpthread.so.0+0x3818807aa0)
> #10 0x38180e893c in clone (/lib64/libc.so.6+0x38180e893c)
> {code}



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

[jira] [Updated] (TS-3915) Regression fails when compilied with ASAN, heap-use-after-free

2016-09-15 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-3915:
---
Labels: ASAN crash  (was: ASAN)

> Regression fails when compilied with ASAN, heap-use-after-free
> --
>
> Key: TS-3915
> URL: https://issues.apache.org/jira/browse/TS-3915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: ASAN, crash
> Fix For: 7.0.0
>
>
> Running regression with asan enable on Fedora 22:
> {code}
> CXXFLAGS="-Werror -fno-omit-frame-pointer -fsanitize=address" 
> CFLAGS="-Werror" SPDYLAY_CFLAGS="-I /usr/local/include/" 
> SPDYLAY_LIBS="-L/usr/local/lib -lspdylay"  ./configure --enable-ccache 
> --enable-spdy --disable-freelist
> REGRESSION TEST SDK_API_HttpTxnTransform started
> Regression test(SDK_API_HttpTxnTransform) still in progress
> [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformRespGet : [TestCase] <> { 
> ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnUntransformedResponseCache : [TestCase1] 
> <> { ok }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformedResponseCache : [TestCase1] 
> <> { ok }
> =
> ==14340==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x60800d59276b at pc 0x005cb466 bp 0x7f4f46b88b40 sp 0x7f4f46b88b30
> READ of size 1 at 0x60800d59276b thread T9 ([ET_NET 8])
> #0 0x5cb465 in transformtest_transform 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6318
> #1 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #2 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #3 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #4 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #5 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> #6 0x7f4f4c9bcb9c in __clone (/lib64/libc.so.6+0x102b9c)
> 0x60800d59276b is located 75 bytes inside of 96-byte region 
> [0x60800d592720,0x60800d592780)
> freed by thread T4 ([ET_NET 3]) here:
> #0 0x7f4f4fb2470a in __interceptor_free (/lib64/libasan.so.2+0x9870a)
> #1 0x5de815 in transform_hook_handler 
> /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6637
> #2 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #3 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #4 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #5 0xc32438 in spawn_thread_internal 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:86
> #6 0x7f4f4da8c554 in start_thread (/lib64/libpthread.so.0+0x7554)
> previously allocated by thread T0 ([ET_NET 0]) here:
> #0 0x7f4f4fb24a0a in malloc (/lib64/libasan.so.2+0x98a0a)
> #1 0x7f4f4f859ae5 in ats_malloc 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:54
> #2 0x5d3d2a in RegressionTest_SDK_API_HttpTxnTransform(RegressionTest*, 
> int, int*) /home/bcall/dev/apache/trafficserver/proxy/InkAPITest.cc:6663
> #3 0x7f4f4f844f69 in start_test 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:78
> #4 0x7f4f4f844f69 in RegressionTest::run_some() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:126
> #5 0x7f4f4f845366 in RegressionTest::check_status() 
> /home/bcall/dev/apache/trafficserver/lib/ts/Regression.cc:141
> #6 0x563773 in RegressionCont::mainEvent(int, Event*) 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1210
> #7 0xc33609 in Continuation::handleEvent(int, void*) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #8 0xc33609 in EThread::process_event(Event*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #9 0xc35605 in EThread::execute() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:207
> #10 0x497d2c in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1812
> #11 0x7f4f4c8da6ff in __libc_start_main (/lib64/libc.so.6+0x206ff)
> Thread T9 ([ET_NET 8]) created by T0 ([ET_NET 0]) here:
> #0 0x7f4f4fac2703 in pthread_create

[GitHub] trafficserver issue #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread PSUdaemon

Github user PSUdaemon commented on the issue:

https://github.com/apache/trafficserver/pull/1025
  
Ran clang-analyzer locally:
> scan-build: No bugs found.


---
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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1025
  
Ran clang-analyzer locally:
> scan-build: No bugs found.


Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[jira] [Updated] (TS-4868) Latest master requires config value in file

2016-09-15 Thread Bryan Call (JIRA)


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

Bryan Call updated TS-4868:
---
Summary: Latest master requires config value in file  (was: latest master 
requires config value in file)

> Latest master requires config value in file
> ---
>
> Key: TS-4868
> URL: https://issues.apache.org/jira/browse/TS-4868
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> <1473896704.> [FATAL]: could not find integer variable 
> proxy.local.cluster.type in records.config
> This is a regression. Our configuration system allows for defaults to be 
> defined. records.config needs to stay optional.



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

[GitHub] trafficserver issue #1022: TS-4868: Add configs back and cleanup other clust...

2016-09-15 Thread dragon512

Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/1022
  
+1



---
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-4868) latest master requires config value in file

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 21:28
Start Date: 15/Sep/16 21:28
Worklog Time Spent: 10m 
  Work Description: Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/1022
  
+1



Issue Time Tracking
---

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

> latest master requires config value in file
> ---
>
> Key: TS-4868
> URL: https://issues.apache.org/jira/browse/TS-4868
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> <1473896704.> [FATAL]: could not find integer variable 
> proxy.local.cluster.type in records.config
> This is a regression. Our configuration system allows for defaults to be 
> defined. records.config needs to stay optional.



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

[jira] [Work logged] (TS-4868) latest master requires config value in file

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1022
  
Fixes the issue I reported on


Issue Time Tracking
---

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

> latest master requires config value in file
> ---
>
> Key: TS-4868
> URL: https://issues.apache.org/jira/browse/TS-4868
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> <1473896704.> [FATAL]: could not find integer variable 
> proxy.local.cluster.type in records.config
> This is a regression. Our configuration system allows for defaults to be 
> defined. records.config needs to stay optional.



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

[GitHub] trafficserver issue #1022: TS-4868: Add configs back and cleanup other clust...

2016-09-15 Thread dragon512

Github user dragon512 commented on the issue:

https://github.com/apache/trafficserver/pull/1022
  
Fixes the issue I reported on


---
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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver issue #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1025
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/714/ 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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver issue #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1025
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/818/ 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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 21:04
Start Date: 15/Sep/16 21:04
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/713/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29204)
Time Spent: 0.5h  (was: 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.0.0
>
>  Time Spent: 0.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 issue #1028: TS-4870 Avoid marking storage offline multiple ti...

2016-09-15 Thread 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/713/ 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 #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread PSUdaemon

Github user PSUdaemon commented on the issue:

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

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

2016-09-15 Thread 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/817/ 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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 21:03
Start Date: 15/Sep/16 21:03
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/817/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29203)
Time Spent: 20m  (was: 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.0.0
>
>  Time Spent: 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 #1022: TS-4868: Add configs back and cleanup other clust...

2016-09-15 Thread gtenev

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/1022
  
I have not looked enough to say if this change is necessary or not but just 
wanted to mention that it helped me with a crash I got after syncing my fork.

```
Starting program: /opt/apache/trafficserver/bin/traffic_manager
[Thread debugging using libthread_db enabled]
[E. Mgmt] log ==> [TrafficManager] using root directory 
'/opt/apache/trafficserver'
[New Thread 0x7709b700 (LWP 24130)]
[New Thread 0x7fffee69a700 (LWP 24131)]

Program received signal SIGSEGV, Segmentation fault.
inet_network (cp=0x0) at inet_net.c:55
55  if (*cp == '0')
Missing separate debuginfos, use: debuginfo-install 
libunwind-1.1-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
(gdb) where
#0  inet_network (cp=0x0) at inet_net.c:55
#1  0x00430273 in main (argc=, argv=) at traffic_manager.cc:668
```

Applying the patch seemed to fix the problem for me.


---
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-4868) latest master requires config value in file

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1022
  
I have not looked enough to say if this change is necessary or not but just 
wanted to mention that it helped me with a crash I got after syncing my fork.

```
Starting program: /opt/apache/trafficserver/bin/traffic_manager
[Thread debugging using libthread_db enabled]
[E. Mgmt] log ==> [TrafficManager] using root directory 
'/opt/apache/trafficserver'
[New Thread 0x7709b700 (LWP 24130)]
[New Thread 0x7fffee69a700 (LWP 24131)]

Program received signal SIGSEGV, Segmentation fault.
inet_network (cp=0x0) at inet_net.c:55
55  if (*cp == '0')
Missing separate debuginfos, use: debuginfo-install 
libunwind-1.1-3.el6.x86_64 tcl-8.5.7-6.el6.x86_64
(gdb) where
#0  inet_network (cp=0x0) at inet_net.c:55
#1  0x00430273 in main (argc=, argv=) at traffic_manager.cc:668
```

Applying the patch seemed to fix the problem for me.


Issue Time Tracking
---

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

> latest master requires config value in file
> ---
>
> Key: TS-4868
> URL: https://issues.apache.org/jira/browse/TS-4868
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> <1473896704.> [FATAL]: could not find integer variable 
> proxy.local.cluster.type in records.config
> This is a regression. Our configuration system allows for defaults to be 
> defined. records.config needs to stay optional.



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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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

TS-4870 Avoid marking storage offline multiple times

Currently storage can be marked offline multiple times which breaks related 
metrics.

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

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

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

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


commit b1389f36936bbfcee6ee645e9954eeae92d4e7ed
Author: Gancho Tenev 
Date:   2016-09-15T13:44:44Z

TS-4870 Avoid marking storage offline multiple times

Currently storage can be marked offline multiple times which breaks related 
metrics.




Issue Time Tracking
---

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

> 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.0.0
>
>  Time Spent: 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 pull request #1028: TS-4870 Avoid marking storage offline mult...

2016-09-15 Thread gtenev

GitHub user gtenev opened a pull request:

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

TS-4870 Avoid marking storage offline multiple times

Currently storage can be marked offline multiple times which breaks related 
metrics.

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

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

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

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


commit b1389f36936bbfcee6ee645e9954eeae92d4e7ed
Author: Gancho Tenev 
Date:   2016-09-15T13:44:44Z

TS-4870 Avoid marking storage offline multiple times

Currently storage can be marked offline multiple times which breaks related 
metrics.




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

Build failed in Jenkins: clang-analyzer #2644

2016-09-15 Thread jenkins

See 

Changes:

[kshri23] Fix race condition in traffic_server startup

[kshri23] Fixed clang-format

--
[...truncated 5390 lines...]
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 71%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 73%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 75%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 77%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 78%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 79%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 80%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 82%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading sources... [ 83%] developer-guide/documentation/building.en
reading sources... [ 84%] developer-guide/documentation/conventions.en
reading sources... [ 84%] developer-guide/documentation/index.en
reading sources... [ 84%] developer-guide/documentation/plugins.en
reading sources... [ 84%] developer-guide/documentation/rst-and-sphinx.en
reading sources... [ 85%] developer-guide/documentation/structure.en
reading sources... [ 85%] developer-guide/documentation/ts-markup.en
reading sources... [ 85%] developer-guide/host-resolution-proposal.en
reading sources... [ 85%] developer-guide/index.en
reading sources... [ 85%] developer-guide/introduction/index.en
reading sources... [ 86%] developer-guide/plugins/actions/hosts-lookup-api.en
reading sources... [ 86%] developer-guide/plugins/actions/index.en
reading sources... [ 86%]

[GitHub] trafficserver pull request #1027: TS-4498 Remap plugin initialization failur...

2016-09-15 Thread pbchou

GitHub user pbchou opened a pull request:

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

TS-4498 Remap plugin initialization failure error messages (back-port).

@jpeach -- James, we would like to request a back-port of this commit to 
6.2.x. Thanks.

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

$ git pull https://github.com/pbchou/trafficserver TS-4498-backport-6.2.x

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

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


commit 0ba58e1b9b98f9191da510cb37b2a12c19284e96
Author: Peter Chou 
Date:   2016-06-01T22:44:08Z

TS-4498: Log plugin remap error message.

Add error logging of the returned error message if a remap plugin
fails to initialize. Currently it just says "bailing out" which is
not as useful.

(cherry-picked from commit 42becd0857b7cb4e39c6fc15efd4fc1e25fafe20)

commit 47759f31b6107fc579330e61eecbe2506874c9fd
Author: Peter Chou 
Date:   2016-09-14T20:36:16Z

TS-4498: Log plugin remap error message.

Ran clang-format [6.2.x] produced different results than [7.0.x].




---
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-4498) RemapConfig.cc - Print out error message on remap plugin init failure.

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 20:27
Start Date: 15/Sep/16 20:27
Worklog Time Spent: 10m 
  Work Description: GitHub user pbchou opened a pull request:

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

TS-4498 Remap plugin initialization failure error messages (back-port).

@jpeach -- James, we would like to request a back-port of this commit to 
6.2.x. Thanks.

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

$ git pull https://github.com/pbchou/trafficserver TS-4498-backport-6.2.x

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

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


commit 0ba58e1b9b98f9191da510cb37b2a12c19284e96
Author: Peter Chou 
Date:   2016-06-01T22:44:08Z

TS-4498: Log plugin remap error message.

Add error logging of the returned error message if a remap plugin
fails to initialize. Currently it just says "bailing out" which is
not as useful.

(cherry-picked from commit 42becd0857b7cb4e39c6fc15efd4fc1e25fafe20)

commit 47759f31b6107fc579330e61eecbe2506874c9fd
Author: Peter Chou 
Date:   2016-09-14T20:36:16Z

TS-4498: Log plugin remap error message.

Ran clang-format [6.2.x] produced different results than [7.0.x].




Issue Time Tracking
---

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

> RemapConfig.cc - Print out error message on remap plugin init failure.
> --
>
> Key: TS-4498
> URL: https://issues.apache.org/jira/browse/TS-4498
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Peter Chou
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add printing of the returned error message to the Warning() if a remap plugin 
> fails to init. Currently it just says "bailing out" which is not as useful.



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

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

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 20:22
Start Date: 15/Sep/16 20:22
Worklog Time Spent: 10m 
  Work Description: GitHub user pbchou opened a pull request:

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

TS-4475 Fix Log Collation Crash (back-port).

@shinrich @oknet -- Susan, this PR is just a back-port to 6.2.x of the Log 
Collation crash fix. I believe Oknet already +1 the back-port as part of the 
previous PR #831 . I think this should be back-ported as this is a crash bug 
and 6.2.x is a LTS release.

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

$ git pull https://github.com/pbchou/trafficserver TS-4475-backport-6.2.x

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

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


commit 1cc28eb9ca06ae6834a779ee889f8b9c3ab8c2b9
Author: Peter Chou 
Date:   2016-06-24T23:21:05Z

TS-4475: Modified the event handlers in LogCollationClientSM.cc to
handle and ignore the VC_EVENT_INACTIVITY_TIMEOUT event. Previously,
this event was un-handled and would cause a core dump.

(cherry picked from commit 0aefbe5349432e44031401ca6a60535a8516adcb)

commit c430715e72fc87fa5c3ad4b788317f013e80
Author: Peter Chou 
Date:   2016-08-03T19:20:45Z

TS-4475 : Handle VC_EVENT_INACTIVITY_TIMEOUT in LogCollationClientSM.cc
Based on suggestions from Oknet Xu, we now close the client connection
on the timeout event instead of ignoring it. Also, we set the
net_vc associated with the client connection to have a timeout of
one day or 86400 seconds instead of the default value.

(cherry picked from commit efd3582b92d825649216705521dbe92784a7279b)

commit 569407f970489f3d16b835cc7f990d902e946300
Author: Peter Chou 
Date:   2016-08-05T23:35:09Z

TS-4475 : Handle VC_EVENT_INACTIVITY_TIMEOUT in LogCollationClientSM.cc
Based on suggestions from Susan Hinrich, we now also handle the
VC_EVENT_ACTIVE_TIMEOUT event. In addition, we also perform
the same clean-up activities performed for the EOS and ERROR events
in addition to closing the client connection.

(cherry picked from commit 483412986c5875ed2451b72328e8548dfc7ef207)

commit 6f3795631011da4232ebe99c94206168318a9b47
Author: Peter Chou 
Date:   2016-08-09T23:52:47Z

TS-4475: Fix un-handled event crash in LogCollationClientSM.cc

I modified the comment and used the post-assignment pointer
(instead of the pre-assignment pointer) to implement an explicit
inactivity time-out value for Log Collation client net-vcs so
that they do not use the default defined in the config.

(cherry picked from commit cb2fa3c5159f17dc5a8e75bfaa4e3cacd8251071)

commit a23a620c53c50e1f15e10cbdc3057877697a59ad
Author: Peter Chou 
Date:   2016-08-22T19:56:18Z

TS-4475: Fix un-handled time-out event crash in Log Collation

1. For collation hosts and clients, handle VC_EVENT_ACTIVE_TIMEOUT
   and VC_EVENT_INACTIVITY_TIMEOUT events and treat them the same
   as other error conditions (EOS and ERROR) including performing
   any clean-up operations.

2. Added two configuration options for log collation VC time-outs --
  - proxy.config.log.collation_host_timeout INT 86390
  - proxy.config.log.collation_client_timeout INT 86400

  These options control how long before the host and client ends of
  the log collation net-vc will time-out after being inactive. The
  host end defaults to 10 fewer seconds to avoid any race condition.
  If the host disconnects first, the client will re-establish with
  a fresh connection.

(cherry picked from commit b6ed91805d9769394131b577045fb6331a25f5c8)

commit fb4ad2cdc92f6023b7cf61b8836a3535f3e41a0b
Author: Peter Chou 
Date:   2016-09-01T19:06:24Z

TS-4475: Fix un-handled time-out event crash in Log Collation

Updated the documenation to explain the difference in host/client
default time-outs.

(cherry picked from commit 4c03b08851eb55ee92537029fbc99cf760542ed6)




Issue Time Tracking
---

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

> Crash in Log-Collation client after using inactivity-cop.
> -
>
> Key: TS-4475
> URL: https://issues.apache.org/jira/browse/TS-4475
>

[GitHub] trafficserver pull request #1026: TS-4475 Fix Log Collation Crash (back-port...

2016-09-15 Thread pbchou

GitHub user pbchou opened a pull request:

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

TS-4475 Fix Log Collation Crash (back-port).

@shinrich @oknet -- Susan, this PR is just a back-port to 6.2.x of the Log 
Collation crash fix. I believe Oknet already +1 the back-port as part of the 
previous PR #831 . I think this should be back-ported as this is a crash bug 
and 6.2.x is a LTS release.

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

$ git pull https://github.com/pbchou/trafficserver TS-4475-backport-6.2.x

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

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


commit 1cc28eb9ca06ae6834a779ee889f8b9c3ab8c2b9
Author: Peter Chou 
Date:   2016-06-24T23:21:05Z

TS-4475: Modified the event handlers in LogCollationClientSM.cc to
handle and ignore the VC_EVENT_INACTIVITY_TIMEOUT event. Previously,
this event was un-handled and would cause a core dump.

(cherry picked from commit 0aefbe5349432e44031401ca6a60535a8516adcb)

commit c430715e72fc87fa5c3ad4b788317f013e80
Author: Peter Chou 
Date:   2016-08-03T19:20:45Z

TS-4475 : Handle VC_EVENT_INACTIVITY_TIMEOUT in LogCollationClientSM.cc
Based on suggestions from Oknet Xu, we now close the client connection
on the timeout event instead of ignoring it. Also, we set the
net_vc associated with the client connection to have a timeout of
one day or 86400 seconds instead of the default value.

(cherry picked from commit efd3582b92d825649216705521dbe92784a7279b)

commit 569407f970489f3d16b835cc7f990d902e946300
Author: Peter Chou 
Date:   2016-08-05T23:35:09Z

TS-4475 : Handle VC_EVENT_INACTIVITY_TIMEOUT in LogCollationClientSM.cc
Based on suggestions from Susan Hinrich, we now also handle the
VC_EVENT_ACTIVE_TIMEOUT event. In addition, we also perform
the same clean-up activities performed for the EOS and ERROR events
in addition to closing the client connection.

(cherry picked from commit 483412986c5875ed2451b72328e8548dfc7ef207)

commit 6f3795631011da4232ebe99c94206168318a9b47
Author: Peter Chou 
Date:   2016-08-09T23:52:47Z

TS-4475: Fix un-handled event crash in LogCollationClientSM.cc

I modified the comment and used the post-assignment pointer
(instead of the pre-assignment pointer) to implement an explicit
inactivity time-out value for Log Collation client net-vcs so
that they do not use the default defined in the config.

(cherry picked from commit cb2fa3c5159f17dc5a8e75bfaa4e3cacd8251071)

commit a23a620c53c50e1f15e10cbdc3057877697a59ad
Author: Peter Chou 
Date:   2016-08-22T19:56:18Z

TS-4475: Fix un-handled time-out event crash in Log Collation

1. For collation hosts and clients, handle VC_EVENT_ACTIVE_TIMEOUT
   and VC_EVENT_INACTIVITY_TIMEOUT events and treat them the same
   as other error conditions (EOS and ERROR) including performing
   any clean-up operations.

2. Added two configuration options for log collation VC time-outs --
  - proxy.config.log.collation_host_timeout INT 86390
  - proxy.config.log.collation_client_timeout INT 86400

  These options control how long before the host and client ends of
  the log collation net-vc will time-out after being inactive. The
  host end defaults to 10 fewer seconds to avoid any race condition.
  If the host disconnects first, the client will re-establish with
  a fresh connection.

(cherry picked from commit b6ed91805d9769394131b577045fb6331a25f5c8)

commit fb4ad2cdc92f6023b7cf61b8836a3535f3e41a0b
Author: Peter Chou 
Date:   2016-09-01T19:06:24Z

TS-4475: Fix un-handled time-out event crash in Log Collation

Updated the documenation to explain the difference in host/client
default time-outs.

(cherry picked from commit 4c03b08851eb55ee92537029fbc99cf760542ed6)




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

2016-09-15 Thread Gancho Tenev (JIRA)


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

Gancho Tenev commented on TS-4870:
--

Repeat the test with the patch applied:

{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. Now good!
$ 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. Good again.
$ 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}

> 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.0.0
>
>
> 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] [Work logged] (TS-4735) Possible deadlock on traffic_server startup

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[jira] [Resolved] (TS-4735) Possible deadlock on traffic_server startup

2016-09-15 Thread James Peach (JIRA)


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

James Peach resolved TS-4735.
-
   Resolution: Fixed
Fix Version/s: (was: 7.0.0)
   7.1.0

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[GitHub] trafficserver pull request #872: TS-4735: Fix race condition in traffic_serv...

2016-09-15 Thread jpeach

Github user jpeach closed the pull request at:

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


---
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 #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1025
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/816/ 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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[jira] [Work logged] (TS-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver issue #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1025
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/712/ 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-4796) ATS not closing origin connections on first RST from client

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/947
  
@jacksontj @zwoop Can we please run this on docs for a few days?



Issue Time Tracking
---

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

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

2016-09-15 Thread jpeach

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
@jacksontj @zwoop Can we please run this on docs for a few days?



---
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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver issue #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1025
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/711/ 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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver issue #1025: TS-4872: Fix clang-analyzer leak error on LogObje...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

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



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

[GitHub] trafficserver pull request #1025: TS-4872: Fix clang-analyzer leak error on ...

2016-09-15 Thread PSUdaemon

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

https://github.com/apache/trafficserver/pull/1025#discussion_r79040648
  
--- Diff: proxy/logging/LogObject.cc ---
@@ -354,6 +354,38 @@ LogObject::display(FILE *fd)
   fprintf(fd, 
"\n");
 }
 
+static head_p
+increment_pointer_version(volatile head_p *dst)
+{
+  head_p h;
+  head_p new_h;
+
+  do {
+INK_QUEUE_LD(h, *dst);
+SET_FREELIST_POINTER_VERSION(new_h, FREELIST_POINTER(h), 
FREELIST_VERSION(h) + 1);
+  } while (ink_atomic_cas(>data, h.data, new_h.data) == false);
+
+  return h;
+}
+
+static bool
+write_pointer_value(volatile head_p *dst, head_p old_h, void *ptr)
+{
+  head_p tmp_h;
+
+  SET_FREELIST_POINTER_VERSION(tmp_h, ptr, 0);
+  return ink_atomic_cas(>data, old_h.data, tmp_h.data);
+}
+
+static bool
+write_pointer_value_vers(volatile head_p *dst, head_p old_h, void *ptr, 
head_p::version_type vers)
+{
+  head_p tmp_h;
+
+  SET_FREELIST_POINTER_VERSION(tmp_h, ptr, vers);
+  return ink_atomic_cas(>data, old_h.data, tmp_h.data);
+}
--- End diff --

Can these two functions be merged? Seems like `write_pointer_value` can 
just call `write_pointer_value_vers` with `0` for the version?


---
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-4858) Global session ticket key block leaks.

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1024#discussion_r79039044
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -2052,6 +2052,7 @@ SSLParseCertificateConfiguration(const 
SSLConfigParams *params, SSLCertLookup *l
 
   // Load the global ticket key for later use.
   REC_ReadConfigStringAlloc(ticket_key_filename, 
"proxy.config.ssl.server.ticket_key.filename");
+  ticket_block_free(global_default_keyblock);
--- End diff --

Unfortunately this is not going to work correctly. At the same time you 
have frees the ticket block here, other threads are accessing it to perform SSL 
handshaking, so they will read a stale pointer.

One way to fix this is to make the ticket block part of the 
``SSLCertLookup`` object and then point the global pointer that that object. 
That might get a little nasty since updating the certificate lookup can fail 
after you assign the global pointer. You might need to find a different way.

In general, I think what needs to happen here is:

- Only update the ticket block if it has changed. Updating is each time 
will reduce the possibility of SSL session resumption.
- If you update the ticket block, swap the pointers to the old and new 
blocks atomically, then schedule the old block for deletion


Issue Time Tracking
---

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

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[jira] [Work logged] (TS-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1025#discussion_r79040648
  
--- Diff: proxy/logging/LogObject.cc ---
@@ -354,6 +354,38 @@ LogObject::display(FILE *fd)
   fprintf(fd, 
"\n");
 }
 
+static head_p
+increment_pointer_version(volatile head_p *dst)
+{
+  head_p h;
+  head_p new_h;
+
+  do {
+INK_QUEUE_LD(h, *dst);
+SET_FREELIST_POINTER_VERSION(new_h, FREELIST_POINTER(h), 
FREELIST_VERSION(h) + 1);
+  } while (ink_atomic_cas(>data, h.data, new_h.data) == false);
+
+  return h;
+}
+
+static bool
+write_pointer_value(volatile head_p *dst, head_p old_h, void *ptr)
+{
+  head_p tmp_h;
+
+  SET_FREELIST_POINTER_VERSION(tmp_h, ptr, 0);
+  return ink_atomic_cas(>data, old_h.data, tmp_h.data);
+}
+
+static bool
+write_pointer_value_vers(volatile head_p *dst, head_p old_h, void *ptr, 
head_p::version_type vers)
+{
+  head_p tmp_h;
+
+  SET_FREELIST_POINTER_VERSION(tmp_h, ptr, vers);
+  return ink_atomic_cas(>data, old_h.data, tmp_h.data);
+}
--- End diff --

Can these two functions be merged? Seems like `write_pointer_value` can 
just call `write_pointer_value_vers` with `0` for the version?


Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver pull request #1024: TS-4858: fix memory leak of global_default...

2016-09-15 Thread jpeach

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

https://github.com/apache/trafficserver/pull/1024#discussion_r79039044
  
--- Diff: iocore/net/SSLUtils.cc ---
@@ -2052,6 +2052,7 @@ SSLParseCertificateConfiguration(const 
SSLConfigParams *params, SSLCertLookup *l
 
   // Load the global ticket key for later use.
   REC_ReadConfigStringAlloc(ticket_key_filename, 
"proxy.config.ssl.server.ticket_key.filename");
+  ticket_block_free(global_default_keyblock);
--- End diff --

Unfortunately this is not going to work correctly. At the same time you 
have frees the ticket block here, other threads are accessing it to perform SSL 
handshaking, so they will read a stale pointer.

One way to fix this is to make the ticket block part of the 
``SSLCertLookup`` object and then point the global pointer that that object. 
That might get a little nasty since updating the certificate lookup can fail 
after you assign the global pointer. You might need to find a different way.

In general, I think what needs to happen here is:

- Only update the ticket block if it has changed. Updating is each time 
will reduce the possibility of SSL session resumption.
- If you update the ticket block, swap the pointers to the old and new 
blocks atomically, then schedule the old block for deletion


---
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-4858) Global session ticket key block leaks.

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

https://github.com/apache/trafficserver/pull/1024
  
pointer check removed


Issue Time Tracking
---

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

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

2016-09-15 Thread persiaAziz

Github user persiaAziz commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
pointer check removed


---
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-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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

TS-4872: Fix clang-analyzer leak error on LogObject.cc _checkout_write.

We could not quite figure out why it reports this (smells almost like a bug 
in clang-analyzer), but some refactoring that avoids the warning, and cleans up 
the code overall.

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

$ git pull https://github.com/jpeach/trafficserver fix/4872

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

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






Issue Time Tracking
---

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

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[GitHub] trafficserver pull request #1025: TS-4872: Fix clang-analyzer leak error on ...

2016-09-15 Thread jpeach

GitHub user jpeach opened a pull request:

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

TS-4872: Fix clang-analyzer leak error on LogObject.cc _checkout_write.

We could not quite figure out why it reports this (smells almost like a bug 
in clang-analyzer), but some refactoring that avoids the warning, and cleans up 
the code overall.

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

$ git pull https://github.com/jpeach/trafficserver fix/4872

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

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






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

Build failed in Jenkins: clang-analyzer #2643

2016-09-15 Thread jenkins

See 

Changes:

[James Peach] TS-4871: Check for TSStatCreate failure.

--
[...truncated 5390 lines...]
reading sources... [ 71%] developer-guide/api/functions/TSfread.en
reading sources... [ 71%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 72%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 73%] developer-guide/api/types/TSEvent.en
reading sources... [ 73%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 74%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 75%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 75%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 77%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 77%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 78%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 78%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 79%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 79%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 80%] developer-guide/architecture/data-structures.en
reading sources... [ 80%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 81%] developer-guide/config-vars.en
reading sources... [ 81%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 82%] developer-guide/debugging/debug-tags.en
reading sources... [ 82%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en
reading sources... [ 83%] developer-guide/debugging/profiling.en
reading sources... [ 83%] developer-guide/debugging/using-tsassert.en
reading sources... [ 83%] developer-guide/documentation/adding-domains.en
reading sources... [ 83%] developer-guide/documentation/building.en
reading sources... [ 84%] developer-guide/documentation/conventions.en
reading sources... [ 84%] developer-guide/documentation/index.en
reading sources... [ 84%] developer-guide/documentation/plugins.en
reading sources... [ 84%] developer-guide/documentation/rst-and-sphinx.en
reading sources... [ 85%] developer-guide/documentation/structure.en
reading sources... [ 85%] developer-guide/documentation/ts-markup.en
reading sources... [ 85%] developer-guide/host-resolution-proposal.en
reading sources... [ 85%] developer-guide/index.en
reading sources... [ 85%] developer-guide/introduction/index.en
reading sources... [ 86%] developer-guide/plugins/actions/hosts-lookup-api.en
reading sources... [ 86%] developer-guide/plugins/actions/index.en
reading sources... [ 86%]

[jira] [Updated] (TS-4871) CID 1362796: Integer handling issues (NEGATIVE_RETURNS) in statistics plugin

2016-09-15 Thread James Peach (JIRA)


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

James Peach updated TS-4871:

Fix Version/s: (was: 7.0.0)
   7.1.0

> CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS) in statistics plugin
> --
>
> Key: TS-4871
> URL: https://issues.apache.org/jira/browse/TS-4871
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: coverity
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
> /example/statistic/statistic.cc: 50 in TSPluginInit()
> 44 
> 45   int id;
> 46   const char name[] = "example.statistic.now";
> 47 
> 48   if (TSStatFindName(name, ) == TS_ERROR) {
> 49 id = TSStatCreate(name, TS_RECORDDATATYPE_INT, 
> TS_STAT_NON_PERSISTENT, TS_STAT_SYNC_SUM);
>CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
>Variable "id" tests negative.
> 50 if (id == TS_ERROR) {
> 51   TSError("%s: failed to register '%s'", PLUGIN_NAME, name);
> 52 }
> 53   }
> 54 
> 55   TSError("%s: %s registered with id %d", PLUGIN_NAME, name, id);
> {code}



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

[jira] [Updated] (TS-4871) CID 1362796: Integer handling issues (NEGATIVE_RETURNS) in statistics plugin

2016-09-15 Thread James Peach (JIRA)


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

James Peach updated TS-4871:

Backport to Version: 7.0.0

> CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS) in statistics plugin
> --
>
> Key: TS-4871
> URL: https://issues.apache.org/jira/browse/TS-4871
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: coverity
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
> /example/statistic/statistic.cc: 50 in TSPluginInit()
> 44 
> 45   int id;
> 46   const char name[] = "example.statistic.now";
> 47 
> 48   if (TSStatFindName(name, ) == TS_ERROR) {
> 49 id = TSStatCreate(name, TS_RECORDDATATYPE_INT, 
> TS_STAT_NON_PERSISTENT, TS_STAT_SYNC_SUM);
>CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
>Variable "id" tests negative.
> 50 if (id == TS_ERROR) {
> 51   TSError("%s: failed to register '%s'", PLUGIN_NAME, name);
> 52 }
> 53   }
> 54 
> 55   TSError("%s: %s registered with id %d", PLUGIN_NAME, name, id);
> {code}



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

[jira] [Resolved] (TS-4871) CID 1362796: Integer handling issues (NEGATIVE_RETURNS) in statistics plugin

2016-09-15 Thread James Peach (JIRA)


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

James Peach resolved TS-4871.
-
Resolution: Fixed

> CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS) in statistics plugin
> --
>
> Key: TS-4871
> URL: https://issues.apache.org/jira/browse/TS-4871
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: coverity
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
> /example/statistic/statistic.cc: 50 in TSPluginInit()
> 44 
> 45   int id;
> 46   const char name[] = "example.statistic.now";
> 47 
> 48   if (TSStatFindName(name, ) == TS_ERROR) {
> 49 id = TSStatCreate(name, TS_RECORDDATATYPE_INT, 
> TS_STAT_NON_PERSISTENT, TS_STAT_SYNC_SUM);
>CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
>Variable "id" tests negative.
> 50 if (id == TS_ERROR) {
> 51   TSError("%s: failed to register '%s'", PLUGIN_NAME, name);
> 52 }
> 53   }
> 54 
> 55   TSError("%s: %s registered with id %d", PLUGIN_NAME, name, id);
> {code}



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

[jira] [Work logged] (TS-4871) CID 1362796: Integer handling issues (NEGATIVE_RETURNS) in statistics plugin

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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


Issue Time Tracking
---

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

> CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS) in statistics plugin
> --
>
> Key: TS-4871
> URL: https://issues.apache.org/jira/browse/TS-4871
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: coverity
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
> /example/statistic/statistic.cc: 50 in TSPluginInit()
> 44 
> 45   int id;
> 46   const char name[] = "example.statistic.now";
> 47 
> 48   if (TSStatFindName(name, ) == TS_ERROR) {
> 49 id = TSStatCreate(name, TS_RECORDDATATYPE_INT, 
> TS_STAT_NON_PERSISTENT, TS_STAT_SYNC_SUM);
>CID 1362796:  Integer handling issues  (NEGATIVE_RETURNS)
>Variable "id" tests negative.
> 50 if (id == TS_ERROR) {
> 51   TSError("%s: failed to register '%s'", PLUGIN_NAME, name);
> 52 }
> 53   }
> 54 
> 55   TSError("%s: %s registered with id %d", PLUGIN_NAME, name, id);
> {code}



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

[GitHub] trafficserver pull request #1023: TS-4871: Check for TSStatCreate failure.

2016-09-15 Thread jpeach

Github user jpeach closed the pull request at:

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


---
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-4796) ATS not closing origin connections on first RST from client

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 7h 20m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/814/ 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-4858) Global session ticket key block leaks.

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[jira] [Work logged] (TS-4796) ATS not closing origin connections on first RST from client

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 7h 10m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/709/ 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 #947: TS-4796 Change UnixNetHandler to always bubble up ...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/710/ 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-4858) Global session ticket key block leaks.

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

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

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



Issue Time Tracking
---

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

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

2016-09-15 Thread atsci

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1024
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/813/ 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-4858) Global session ticket key block leaks.

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 17:58
Start Date: 15/Sep/16 17:58
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

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


Issue Time Tracking
---

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

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...

2016-09-15 Thread zwoop

Github user zwoop commented on the issue:

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


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

[jira] [Work logged] (TS-4858) Global session ticket key block leaks.

2016-09-15 Thread ASF GitHub Bot (JIRA)


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

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

Author: ASF GitHub Bot
Created on: 15/Sep/16 17:56
Start Date: 15/Sep/16 17:56
Worklog Time Spent: 10m 
  Work Description: GitHub user persiaAziz opened a pull request:

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

TS-4858: fix memory leak of global_default_keyblock

fix memory leak of global_default_keyblock. 
global_defualt_keyblock will be freed and reassigned on each reload

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

$ git pull https://github.com/persiaAziz/trafficserver TS-4858

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

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


commit 58b325b0ab8861dbb3e388b044010eb6bcab4756
Author: Persia Aziz 
Date:   2016-09-15T17:46:15Z

TS-4858: fix memory leak of global_default_keyblock




Issue Time Tracking
---

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

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

1 2 >

1 - 100 of 172 matches

Mail list logo