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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286906
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -63,21 +66,104 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
 {
   const char *tmp = NULL;
   int len;
-  URL *url = hrdata->hdr->url_get();
+  URL *url = hrdata->hdr->url_get();
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "hrdata->cache_info_parent_selection_url = %p", 
hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ps_url = %p", ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref();
+  if (tmp && len > 0) {
+// Print the over-ride URL
+Debug("parent_select", "Using Over-Ride String='%.*s'.", len, tmp);
+h->update(tmp, len);
+h->final();
+return h->get();
+  }
+}
+  }
 
   // Always hash on '/' because paths returned by ATS are always stripped 
of it
   h->update("/", 1);
 
   tmp = url->path_get();
-  if (tmp) {
+
+  if (tmp && len > 0) {
+// Print the Original path.
+Debug("parent_select", "Original Path='%.*s'.", len, tmp);
+
+// Process the 'maxdirs' directive.
+if (max_dirs != 0) {
+  // Determine number of directory components in the path.
+  // NOTE: Leading '/' is gone already.
+  for (int x = 0; x < len; x++) {
+if (tmp[x] == '/')
+  num_dirs++;
+  }
+  // If max_dirs positive , include directory components from the left 
up to max_dirs.
+  // If max_dirs negative , include directory components from the left 
up to num_dirs - ( abs(max_dirs) - 1 ).
+  int limit = 0;
+  if (max_dirs > 0)
+limit = max_dirs;
+  else if (max_dirs < 0) {
+int md = abs(max_dirs) - 1;
+if (md < num_dirs)
+  limit = num_dirs - md;
+else
+  limit = 0;
+  }
+  if (limit > 0) {
+int x = 0;
+int count = 0;
+for (; x < len; x++) {
+  if (tmp[x] == '/')
+count++;
+  if (count == limit) {
+len = x + 1;
+break;
+  }
+}
+  } else {
+len = 0;
+  }
+}
+
+// Print the post 'maxdirs' path.
+Debug("parent_select", "Post-maxdirs Path='%.*s'.", len, tmp);
+
+// Process the 'fname' directive.
+// The file name (if any) is filtered out if set to ignore the file 
name or max_dirs was non-zero.
+// The file name (if any) consists of the characters at the end of the 
path beyond the final '/'.
+// The length of the path string (to be passed to the hash generator) 
is shortened to accomplish the filtering.
+if (ignore_fname || max_dirs != 0) {
--- End diff --

How is ``ignore_fname`` different from maxdirs==-1?


Issue Time Tracking
---

Worklog Id: (was: 28744)
Time Spent: 9h 20m  (was: 9h 10m)

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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286906
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -63,21 +66,104 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
 {
   const char *tmp = NULL;
   int len;
-  URL *url = hrdata->hdr->url_get();
+  URL *url = hrdata->hdr->url_get();
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "hrdata->cache_info_parent_selection_url = %p", 
hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ps_url = %p", ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref();
+  if (tmp && len > 0) {
+// Print the over-ride URL
+Debug("parent_select", "Using Over-Ride String='%.*s'.", len, tmp);
+h->update(tmp, len);
+h->final();
+return h->get();
+  }
+}
+  }
 
   // Always hash on '/' because paths returned by ATS are always stripped 
of it
   h->update("/", 1);
 
   tmp = url->path_get();
-  if (tmp) {
+
+  if (tmp && len > 0) {
+// Print the Original path.
+Debug("parent_select", "Original Path='%.*s'.", len, tmp);
+
+// Process the 'maxdirs' directive.
+if (max_dirs != 0) {
+  // Determine number of directory components in the path.
+  // NOTE: Leading '/' is gone already.
+  for (int x = 0; x < len; x++) {
+if (tmp[x] == '/')
+  num_dirs++;
+  }
+  // If max_dirs positive , include directory components from the left 
up to max_dirs.
+  // If max_dirs negative , include directory components from the left 
up to num_dirs - ( abs(max_dirs) - 1 ).
+  int limit = 0;
+  if (max_dirs > 0)
+limit = max_dirs;
+  else if (max_dirs < 0) {
+int md = abs(max_dirs) - 1;
+if (md < num_dirs)
+  limit = num_dirs - md;
+else
+  limit = 0;
+  }
+  if (limit > 0) {
+int x = 0;
+int count = 0;
+for (; x < len; x++) {
+  if (tmp[x] == '/')
+count++;
+  if (count == limit) {
+len = x + 1;
+break;
+  }
+}
+  } else {
+len = 0;
+  }
+}
+
+// Print the post 'maxdirs' path.
+Debug("parent_select", "Post-maxdirs Path='%.*s'.", len, tmp);
+
+// Process the 'fname' directive.
+// The file name (if any) is filtered out if set to ignore the file 
name or max_dirs was non-zero.
+// The file name (if any) consists of the characters at the end of the 
path beyond the final '/'.
+// The length of the path string (to be passed to the hash generator) 
is shortened to accomplish the filtering.
+if (ignore_fname || max_dirs != 0) {
--- End diff --

How is ``ignore_fname`` different from maxdirs==-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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286892
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -63,21 +66,104 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
 {
   const char *tmp = NULL;
   int len;
-  URL *url = hrdata->hdr->url_get();
+  URL *url = hrdata->hdr->url_get();
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "hrdata->cache_info_parent_selection_url = %p", 
hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ps_url = %p", ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref();
+  if (tmp && len > 0) {
+// Print the over-ride URL
+Debug("parent_select", "Using Over-Ride String='%.*s'.", len, tmp);
+h->update(tmp, len);
+h->final();
+return h->get();
+  }
+}
+  }
 
   // Always hash on '/' because paths returned by ATS are always stripped 
of it
   h->update("/", 1);
 
   tmp = url->path_get();
-  if (tmp) {
+
+  if (tmp && len > 0) {
+// Print the Original path.
+Debug("parent_select", "Original Path='%.*s'.", len, tmp);
+
+// Process the 'maxdirs' directive.
+if (max_dirs != 0) {
+  // Determine number of directory components in the path.
+  // NOTE: Leading '/' is gone already.
+  for (int x = 0; x < len; x++) {
+if (tmp[x] == '/')
+  num_dirs++;
+  }
+  // If max_dirs positive , include directory components from the left 
up to max_dirs.
+  // If max_dirs negative , include directory components from the left 
up to num_dirs - ( abs(max_dirs) - 1 ).
+  int limit = 0;
+  if (max_dirs > 0)
+limit = max_dirs;
+  else if (max_dirs < 0) {
+int md = abs(max_dirs) - 1;
+if (md < num_dirs)
+  limit = num_dirs - md;
+else
+  limit = 0;
+  }
+  if (limit > 0) {
+int x = 0;
+int count = 0;
+for (; x < len; x++) {
--- End diff --

```C
for (int x = 0; x < len; ++x) { ... }
```


Issue Time Tracking
---

Worklog Id: (was: 28743)
Time Spent: 9h 10m  (was: 9h)

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



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286892
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -63,21 +66,104 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
 {
   const char *tmp = NULL;
   int len;
-  URL *url = hrdata->hdr->url_get();
+  URL *url = hrdata->hdr->url_get();
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "hrdata->cache_info_parent_selection_url = %p", 
hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ps_url = %p", ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref();
+  if (tmp && len > 0) {
+// Print the over-ride URL
+Debug("parent_select", "Using Over-Ride String='%.*s'.", len, tmp);
+h->update(tmp, len);
+h->final();
+return h->get();
+  }
+}
+  }
 
   // Always hash on '/' because paths returned by ATS are always stripped 
of it
   h->update("/", 1);
 
   tmp = url->path_get();
-  if (tmp) {
+
+  if (tmp && len > 0) {
+// Print the Original path.
+Debug("parent_select", "Original Path='%.*s'.", len, tmp);
+
+// Process the 'maxdirs' directive.
+if (max_dirs != 0) {
+  // Determine number of directory components in the path.
+  // NOTE: Leading '/' is gone already.
+  for (int x = 0; x < len; x++) {
+if (tmp[x] == '/')
+  num_dirs++;
+  }
+  // If max_dirs positive , include directory components from the left 
up to max_dirs.
+  // If max_dirs negative , include directory components from the left 
up to num_dirs - ( abs(max_dirs) - 1 ).
+  int limit = 0;
+  if (max_dirs > 0)
+limit = max_dirs;
+  else if (max_dirs < 0) {
+int md = abs(max_dirs) - 1;
+if (md < num_dirs)
+  limit = num_dirs - md;
+else
+  limit = 0;
+  }
+  if (limit > 0) {
+int x = 0;
+int count = 0;
+for (; x < len; x++) {
--- End diff --

```C
for (int x = 0; x < len; ++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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286827
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -63,21 +66,104 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
 {
   const char *tmp = NULL;
   int len;
-  URL *url = hrdata->hdr->url_get();
+  URL *url = hrdata->hdr->url_get();
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "hrdata->cache_info_parent_selection_url = %p", 
hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ps_url = %p", ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref();
+  if (tmp && len > 0) {
+// Print the over-ride URL
+Debug("parent_select", "Using Over-Ride String='%.*s'.", len, tmp);
+h->update(tmp, len);
+h->final();
+return h->get();
+  }
+}
+  }
 
   // Always hash on '/' because paths returned by ATS are always stripped 
of it
   h->update("/", 1);
 
   tmp = url->path_get();
-  if (tmp) {
+
+  if (tmp && len > 0) {
+// Print the Original path.
+Debug("parent_select", "Original Path='%.*s'.", len, tmp);
+
+// Process the 'maxdirs' directive.
+if (max_dirs != 0) {
+  // Determine number of directory components in the path.
+  // NOTE: Leading '/' is gone already.
+  for (int x = 0; x < len; x++) {
+if (tmp[x] == '/')
+  num_dirs++;
--- End diff --

This, and all subsequent conditions should be enclosed in ``{`` ``}``.


Issue Time Tracking
---

Worklog Id: (was: 28742)
Time Spent: 9h  (was: 8h 50m)

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



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286827
  
--- Diff: proxy/ParentConsistentHash.cc ---
@@ -63,21 +66,104 @@ ParentConsistentHash::getPathHash(HttpRequestData 
*hrdata, ATSHash64 *h)
 {
   const char *tmp = NULL;
   int len;
-  URL *url = hrdata->hdr->url_get();
+  URL *url = hrdata->hdr->url_get();
+  int num_dirs = 0;
+
+  // Use over-ride URL from HttpTransact::State's 
cache_info.parent_selection_url, if present.
+  URL *ps_url = NULL;
+  Debug("parent_select", "hrdata->cache_info_parent_selection_url = %p", 
hrdata->cache_info_parent_selection_url);
+  if (hrdata->cache_info_parent_selection_url) {
+ps_url = *(hrdata->cache_info_parent_selection_url);
+Debug("parent_select", "ps_url = %p", ps_url);
+if (ps_url) {
+  tmp = ps_url->string_get_ref();
+  if (tmp && len > 0) {
+// Print the over-ride URL
+Debug("parent_select", "Using Over-Ride String='%.*s'.", len, tmp);
+h->update(tmp, len);
+h->final();
+return h->get();
+  }
+}
+  }
 
   // Always hash on '/' because paths returned by ATS are always stripped 
of it
   h->update("/", 1);
 
   tmp = url->path_get();
-  if (tmp) {
+
+  if (tmp && len > 0) {
+// Print the Original path.
+Debug("parent_select", "Original Path='%.*s'.", len, tmp);
+
+// Process the 'maxdirs' directive.
+if (max_dirs != 0) {
+  // Determine number of directory components in the path.
+  // NOTE: Leading '/' is gone already.
+  for (int x = 0; x < len; x++) {
+if (tmp[x] == '/')
+  num_dirs++;
--- End diff --

This, and all subsequent conditions should be enclosed 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.
---

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286751
  
--- Diff: proxy/ParentSelection.cc ---
@@ -570,6 +572,18 @@ ParentRecord::Init(matcher_line *line_info)
 this->ignore_query = false;
   }
   used = true;
+} else if (strcasecmp(label, "fname") == 0) {
+  // fname=ignore | consider
+  if (strcasecmp(val, "ignore") == 0) {
--- End diff --

Ok.


---
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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286751
  
--- Diff: proxy/ParentSelection.cc ---
@@ -570,6 +572,18 @@ ParentRecord::Init(matcher_line *line_info)
 this->ignore_query = false;
   }
   used = true;
+} else if (strcasecmp(label, "fname") == 0) {
+  // fname=ignore | consider
+  if (strcasecmp(val, "ignore") == 0) {
--- End diff --

Ok.


Issue Time Tracking
---

Worklog Id: (was: 28741)
Time Spent: 8h 50m  (was: 8h 40m)

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834
  
IMO, the proposal of fname and maxdirs is a bit of a hack, solving a subset 
of all possible use cases. Allowing for a "parent selection URL" that can be 
the same, or different, than the pristine / cachekey URL would be generic.


Issue Time Tracking
---

Worklog Id: (was: 28740)
Time Spent: 8h 40m  (was: 8.5h)

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



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

[GitHub] trafficserver issue #834: TS-4707 : Parent Consistent Hash Selection - add f...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
IMO, the proposal of fname and maxdirs is a bit of a hack, solving a subset 
of all possible use cases. Allowing for a "parent selection URL" that can be 
the same, or different, than the pristine / cachekey URL would be generic.


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

[PSUdaemon]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286643
  
--- Diff: proxy/ParentSelection.cc ---
@@ -570,6 +572,18 @@ ParentRecord::Init(matcher_line *line_info)
 this->ignore_query = false;
   }
   used = true;
+} else if (strcasecmp(label, "fname") == 0) {
+  // fname=ignore | consider
+  if (strcasecmp(val, "ignore") == 0) {
--- End diff --

I thought the same thing when I read that, but if you look at the 
surrounding code it's all in the style @pbchou did. I think we should leave 
this as is. Perhaps a different clean up effort.


---
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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286643
  
--- Diff: proxy/ParentSelection.cc ---
@@ -570,6 +572,18 @@ ParentRecord::Init(matcher_line *line_info)
 this->ignore_query = false;
   }
   used = true;
+} else if (strcasecmp(label, "fname") == 0) {
+  // fname=ignore | consider
+  if (strcasecmp(val, "ignore") == 0) {
--- End diff --

I thought the same thing when I read that, but if you look at the 
surrounding code it's all in the style @pbchou did. I think we should leave 
this as is. Perhaps a different clean up effort.


Issue Time Tracking
---

Worklog Id: (was: 28739)
Time Spent: 8.5h  (was: 8h 20m)

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



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

[jira] [Commented] (TS-4846) Make jemalloc a required dependency.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4846:
---

I'm not opposed to this, but also not sure I see the real value of requiring 
this until we have some hard dependencies on the library itself. This also 
brings us into the pain of dealing with jemalloc versions if we want to code to 
some of their APIs, lowest common denominator seems to be jemalloc v3.6.1, with 
v4.1.x being available on modern distros.

Two more thoughts:

1) If we do this, we ought to remove the support for tcmalloc.

2) Should we consider importing jemalloc into our lib/ tree?


I'm -0 on this for now, at least until we have a real need for this dependency. 
However, in preparation, we could remove the (explicit) support for tcmalloc 
for v7.0.0, that'll at least make it easier to add new features with jemalloc 
specific requirements.

> Make jemalloc a required dependency.
> 
>
> Key: TS-4846
> URL: https://issues.apache.org/jira/browse/TS-4846
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Performance
>Reporter: James Peach
>
> If we make {{jemalloc}} a required dependency, then all operators would 
> better better performance without any special configuration. We can also then 
> build tooling that used the jemalloc [heap 
> profiling|https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling]
>  and 
> [statistics|https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Basic-Allocator-Statistics]
>  support to get more information about memory and allocation patterns.



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[zwoop]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286562
  
--- Diff: proxy/api/ts/ts.h ---
@@ -1481,6 +1481,9 @@ tsapi TSReturnCode TSHttpTxnParentProxyGet(TSHttpTxn 
txnp, const char **hostname
  */
 tsapi void TSHttpTxnParentProxySet(TSHttpTxn txnp, const char *hostname, 
int port);
 
+tsapi TSReturnCode TSHttpTxnParentSelectionUrlGet(TSHttpTxn txnp, 
TSMBuffer bufp, TSMLoc obj);
+tsapi TSReturnCode TSHttpTxnParentSelectionUrlSet(TSHttpTxn txnp, 
TSMBuffer bufp, TSMLoc obj);
--- End diff --

There's definitely a real use case where you want to do parent selection on 
a different (normalized) URL that e.g. the pristine URL or cache key URL. Doing 
parent selection on the cache key URL would be a benefit (think of e.g. URLs 
with signatures, where you don't want the parent selection to include that 
signature).


---
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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286520
  
--- Diff: 
doc/developer-guide/api/functions/TSHttpTxnCacheParentSelectionUrlGet.en.rst ---
@@ -0,0 +1,63 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+   or more contributor license agreements.  See the NOTICE file
+   distributed with this work for additional information
+   regarding copyright ownership.  The ASF licenses this file
+   to you under the Apache License, Version 2.0 (the
+   "License"); you may not use this file except in compliance
+   with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing,
+   software distributed under the License is distributed on an
+   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+   KIND, either express or implied.  See the License for the
+   specific language governing permissions and limitations
+   under the License.
+
+.. include:: ../../../common.defs
+
+.. default-domain:: c
+
+TSHttpTxnCacheParentSelectionUrlSet
+***
+
+Traffic Server Parent Selection consistent hash URL manipulation API.
+
+Synopsis
+
+
+`#include `
+
+.. function:: TSReturnCode TSHttpTxnCacheParentSelectionUrlSet(TSHttpTxn 
txnp, TSMBuffer bufp, TSMLoc offset)
+.. function:: TSReturnCode TSHttpTxnCacheParentSelectionUrlGet(TSHttpTxn 
txnp, TSMBuffer bufp, TSMLoc offset)
--- End diff --

This seems like a totally separate feature. Can we split this from this PR?


Issue Time Tracking
---

Worklog Id: (was: 28737)
Time Spent: 8h 10m  (was: 8h)

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286510
  
--- Diff: doc/admin-guide/files/parent.config.en.rst ---
@@ -225,6 +225,60 @@ The following list shows the possible actions and 
their allowed values.
 -  ``consider`` - Use the query string when finding a parent.
 -  ``ignore`` - Do not consider the query string when finding a parent.
 
+.. _parent-config-format-fname:
+
+``fname``
+One of the following values:
+
+- ``consider`` - Use the file name string when finding a parent.
+- ``ignore`` - Do not consider the file name string when finding a 
parent.
--- End diff --

What is the default?


Issue Time Tracking
---

Worklog Id: (was: 28736)
Time Spent: 8h  (was: 7h 50m)

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



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286520
  
--- Diff: 
doc/developer-guide/api/functions/TSHttpTxnCacheParentSelectionUrlGet.en.rst ---
@@ -0,0 +1,63 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+   or more contributor license agreements.  See the NOTICE file
+   distributed with this work for additional information
+   regarding copyright ownership.  The ASF licenses this file
+   to you under the Apache License, Version 2.0 (the
+   "License"); you may not use this file except in compliance
+   with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing,
+   software distributed under the License is distributed on an
+   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+   KIND, either express or implied.  See the License for the
+   specific language governing permissions and limitations
+   under the License.
+
+.. include:: ../../../common.defs
+
+.. default-domain:: c
+
+TSHttpTxnCacheParentSelectionUrlSet
+***
+
+Traffic Server Parent Selection consistent hash URL manipulation API.
+
+Synopsis
+
+
+`#include `
+
+.. function:: TSReturnCode TSHttpTxnCacheParentSelectionUrlSet(TSHttpTxn 
txnp, TSMBuffer bufp, TSMLoc offset)
+.. function:: TSReturnCode TSHttpTxnCacheParentSelectionUrlGet(TSHttpTxn 
txnp, TSMBuffer bufp, TSMLoc offset)
--- End diff --

This seems like a totally separate feature. Can we split this from this PR?


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

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286510
  
--- Diff: doc/admin-guide/files/parent.config.en.rst ---
@@ -225,6 +225,60 @@ The following list shows the possible actions and 
their allowed values.
 -  ``consider`` - Use the query string when finding a parent.
 -  ``ignore`` - Do not consider the query string when finding a parent.
 
+.. _parent-config-format-fname:
+
+``fname``
+One of the following values:
+
+- ``consider`` - Use the file name string when finding a parent.
+- ``ignore`` - Do not consider the file name string when finding a 
parent.
--- End diff --

What is the default?


---
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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286469
  
--- Diff: proxy/ControlMatcher.h ---
@@ -136,7 +137,16 @@ class HttpRequestData : public RequestData
   inkcoreapi sockaddr const *get_ip();
   inkcoreapi sockaddr const *get_client_ip();
 
-  HttpRequestData() : hdr(NULL), hostname_str(NULL), api_info(NULL), 
xact_start(0), incoming_port(0), tag(NULL), internal_txn(false)
+  HttpRequestData()
+: hdr(NULL),
+  hostname_str(NULL),
+  api_info(NULL),
+  xact_start(0),
+  incoming_port(0),
+  tag(NULL),
+  internal_txn(false),
+  cache_info_lookup_url(NULL),
--- End diff --

This is not used, can we remove it?


Issue Time Tracking
---

Worklog Id: (was: 28735)
Time Spent: 7h 50m  (was: 7h 40m)

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



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286469
  
--- Diff: proxy/ControlMatcher.h ---
@@ -136,7 +137,16 @@ class HttpRequestData : public RequestData
   inkcoreapi sockaddr const *get_ip();
   inkcoreapi sockaddr const *get_client_ip();
 
-  HttpRequestData() : hdr(NULL), hostname_str(NULL), api_info(NULL), 
xact_start(0), incoming_port(0), tag(NULL), internal_txn(false)
+  HttpRequestData()
+: hdr(NULL),
+  hostname_str(NULL),
+  api_info(NULL),
+  xact_start(0),
+  incoming_port(0),
+  tag(NULL),
+  internal_txn(false),
+  cache_info_lookup_url(NULL),
--- End diff --

This is not used, can we remove it?


---
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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286437
  
--- Diff: proxy/api/ts/ts.h ---
@@ -1481,6 +1481,9 @@ tsapi TSReturnCode TSHttpTxnParentProxyGet(TSHttpTxn 
txnp, const char **hostname
  */
 tsapi void TSHttpTxnParentProxySet(TSHttpTxn txnp, const char *hostname, 
int port);
 
+tsapi TSReturnCode TSHttpTxnParentSelectionUrlGet(TSHttpTxn txnp, 
TSMBuffer bufp, TSMLoc obj);
+tsapi TSReturnCode TSHttpTxnParentSelectionUrlSet(TSHttpTxn txnp, 
TSMBuffer bufp, TSMLoc obj);
--- End diff --

Why do we need yet another URL? We have the pristine URL, the cache key 
URL, and the rewritten URL. I think we need to examine this in API review.


Issue Time Tracking
---

Worklog Id: (was: 28734)
Time Spent: 7h 40m  (was: 7.5h)

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



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286437
  
--- Diff: proxy/api/ts/ts.h ---
@@ -1481,6 +1481,9 @@ tsapi TSReturnCode TSHttpTxnParentProxyGet(TSHttpTxn 
txnp, const char **hostname
  */
 tsapi void TSHttpTxnParentProxySet(TSHttpTxn txnp, const char *hostname, 
int port);
 
+tsapi TSReturnCode TSHttpTxnParentSelectionUrlGet(TSHttpTxn txnp, 
TSMBuffer bufp, TSMLoc obj);
+tsapi TSReturnCode TSHttpTxnParentSelectionUrlSet(TSHttpTxn txnp, 
TSMBuffer bufp, TSMLoc obj);
--- End diff --

Why do we need yet another URL? We have the pristine URL, the cache key 
URL, and the rewritten URL. I think we need to examine this in API 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.
---

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286417
  
--- Diff: proxy/ParentSelection.cc ---
@@ -570,6 +572,18 @@ ParentRecord::Init(matcher_line *line_info)
 this->ignore_query = false;
   }
   used = true;
+} else if (strcasecmp(label, "fname") == 0) {
+  // fname=ignore | consider
+  if (strcasecmp(val, "ignore") == 0) {
--- End diff --

```C
this->ignore_fname = (strcasecmp(val, "ignore") == 0);
```


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver pull request #834: TS-4707 : Parent Consistent Hash Selection ...

[jpeach]

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

https://github.com/apache/trafficserver/pull/834#discussion_r78286417
  
--- Diff: proxy/ParentSelection.cc ---
@@ -570,6 +572,18 @@ ParentRecord::Init(matcher_line *line_info)
 this->ignore_query = false;
   }
   used = true;
+} else if (strcasecmp(label, "fname") == 0) {
+  // fname=ignore | consider
+  if (strcasecmp(val, "ignore") == 0) {
--- End diff --

```C
this->ignore_fname = (strcasecmp(val, "ignore") == 0);
```


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

[jenkins]

See 

Changes:

[pbchou] TS-4475: Modified the event handlers in LogCollationClientSM.cc to

[pbchou] TS-4475 : Handle VC_EVENT_INACTIVITY_TIMEOUT in LogCollationClientSM.cc

[pbchou] TS-4475 : Handle VC_EVENT_INACTIVITY_TIMEOUT in LogCollationClientSM.cc

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

[pbchou] [ this commit message summarizes all changes and is intended to   be

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

[persia] TS-4503: Replace MachineFatal by ink_abort

[James Peach] TS-4847: Local manager needs to register proxy.node.proxy_running.

--
[...truncated 5334 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 71%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 72%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 73%] 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... [ 74%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 75%] 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... [ 76%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 78%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 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 

Failed: trafficserver (2c9481d0)

[Read the Docs]

Build Failed for trafficserver (latest)



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

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



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

[jira] [Resolved] (TS-4847) traffic_cop / _manager busted on current master?

[James Peach (JIRA)]

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

James Peach resolved TS-4847.
-
Resolution: Fixed

> traffic_cop / _manager busted on current master?
> 
>
> Key: TS-4847
> URL: https://issues.apache.org/jira/browse/TS-4847
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop, Manager
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I'm getting the following on current master (docs.trafficserver):
> {code}
> Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
> mgmt cli
> Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
> server is down
> {code}



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

[GitHub] trafficserver pull request #1005: TS-4847: Local manager needs to register p...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4847) traffic_cop / _manager busted on current master?

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> traffic_cop / _manager busted on current master?
> 
>
> Key: TS-4847
> URL: https://issues.apache.org/jira/browse/TS-4847
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop, Manager
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I'm getting the following on current master (docs.trafficserver):
> {code}
> Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
> mgmt cli
> Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
> server is down
> {code}



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

[jira] [Commented] (TS-4846) Make jemalloc a required dependency.

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-4846:
--

+1 

I think it benefits lots of the plugins, too.

> Make jemalloc a required dependency.
> 
>
> Key: TS-4846
> URL: https://issues.apache.org/jira/browse/TS-4846
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Performance
>Reporter: James Peach
>
> If we make {{jemalloc}} a required dependency, then all operators would 
> better better performance without any special configuration. We can also then 
> build tooling that used the jemalloc [heap 
> profiling|https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling]
>  and 
> [statistics|https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Basic-Allocator-Statistics]
>  support to get more information about memory and allocation patterns.



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

[jira] [Updated] (TS-4848) Disabling HostDB sync disables GC ?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4848:
--
Description: 
We ran into an issue, where when we disabled HostDB sync, we seem to be getting:

{code}
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2af60fe0} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2aaab4a11700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: {0x2aaab430a700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: {0x2aaab4209700} 
WARNING:  Out of room in hostdb for hostname 
(data area full!)
{code}

at which point, it then crashed or aborted. Setting changed was

{code}
CONFIG proxy.config.cache.hostdb.sync_frequency INT 0
{code}


  was:
We ran into an issue, where when we disabled HostDB sync, we seem to be getting:

{code}
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2af60fe0} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2aaab4a11700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: {0x2aaab430a700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: {0x2aaab4209700} 
WARNING:  Out of room in hostdb for hostname 
(data area full!)
{code}

at which point, it then crashed or aborted.



> Disabling HostDB sync disables GC ?
> ---
>
> Key: TS-4848
> URL: https://issues.apache.org/jira/browse/TS-4848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> We ran into an issue, where when we disabled HostDB sync, we seem to be 
> getting:
> {code}
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2af60fe0} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4a11700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab430a700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4209700} WARNING:  Out of room in 
> hostdb for hostname (data area full!)
> {code}
> at which point, it then crashed or aborted. Setting changed was
> {code}
> CONFIG proxy.config.cache.hostdb.sync_frequency INT 0
> {code}



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

[jira] [Updated] (TS-4848) Disabling HostDB sync disables GC ?

[Leif Hedstrom (JIRA)]

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

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

> Disabling HostDB sync disables GC ?
> ---
>
> Key: TS-4848
> URL: https://issues.apache.org/jira/browse/TS-4848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> We ran into an issue, where when we disabled HostDB sync, we seem to be 
> getting:
> {code}
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2af60fe0} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4a11700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab430a700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4209700} WARNING:  Out of room in 
> hostdb for hostname (data area full!)
> {code}
> at which point, it then crashed or aborted.



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

[jira] [Updated] (TS-4848) Disabling HostDB sync disables GC ?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4848:
--
Affects Version/s: 6.2.0

> Disabling HostDB sync disables GC ?
> ---
>
> Key: TS-4848
> URL: https://issues.apache.org/jira/browse/TS-4848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Affects Versions: 6.2.0
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> We ran into an issue, where when we disabled HostDB sync, we seem to be 
> getting:
> {code}
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2af60fe0} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4a11700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab430a700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4209700} WARNING:  Out of room in 
> hostdb for hostname (data area full!)
> {code}
> at which point, it then crashed or aborted.



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

[jira] [Created] (TS-4848) Disabling HostDB sync disables GC ?

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4848:
-

 Summary: Disabling HostDB sync disables GC ?
 Key: TS-4848
 URL: https://issues.apache.org/jira/browse/TS-4848
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Leif Hedstrom


We ran into an issue, where when we disabled HostDB sync, we seem to be getting:

{code}
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2af60fe0} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:08 s_sys@ host.example.com traffic_server[31916]: {0x2aaab4a11700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_sys@ host.example.com traffic_server[31916]: {0x2aaab430a700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_sys@ host.example.com traffic_server[31916]: {0x2aaab4209700} 
WARNING:  Out of room in hostdb for hostname 
(data area full!)
{code}

at which point, it then crashed or aborted.




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

[jira] [Updated] (TS-4848) Disabling HostDB sync disables GC ?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4848:
--
Description: 
We ran into an issue, where when we disabled HostDB sync, we seem to be getting:

{code}
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2af60fe0} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2aaab4a11700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: {0x2aaab430a700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: {0x2aaab4209700} 
WARNING:  Out of room in hostdb for hostname 
(data area full!)
{code}

at which point, it then crashed or aborted.


  was:
We ran into an issue, where when we disabled HostDB sync, we seem to be getting:

{code}
Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: {0x2af60fe0} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:08 s_sys@ host.example.com traffic_server[31916]: {0x2aaab4a11700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_sys@ host.example.com traffic_server[31916]: {0x2aaab430a700} 
WARNING:  out of room in hostdb for round-robin DNS 
data
Sep 10 16:33:09 s_sys@ host.example.com traffic_server[31916]: {0x2aaab4209700} 
WARNING:  Out of room in hostdb for hostname 
(data area full!)
{code}

at which point, it then crashed or aborted.



> Disabling HostDB sync disables GC ?
> ---
>
> Key: TS-4848
> URL: https://issues.apache.org/jira/browse/TS-4848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Leif Hedstrom
>
> We ran into an issue, where when we disabled HostDB sync, we seem to be 
> getting:
> {code}
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2af60fe0} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:08 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4a11700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab430a700} WARNING:  out of room in hostdb 
> for round-robin DNS data
> Sep 10 16:33:09 s_...@host.example.com traffic_server[31916]: 
> {0x2aaab4209700} WARNING:  Out of room in 
> hostdb for hostname (data area full!)
> {code}
> at which point, it then crashed or aborted.



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

[jira] [Work logged] (TS-4847) traffic_cop / _manager busted on current master?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_cop / _manager busted on current master?
> 
>
> Key: TS-4847
> URL: https://issues.apache.org/jira/browse/TS-4847
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop, Manager
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I'm getting the following on current master (docs.trafficserver):
> {code}
> Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
> mgmt cli
> Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
> server is down
> {code}



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

[GitHub] trafficserver issue #1005: TS-4847: Local manager needs to register proxy.no...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1005
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/672/ 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-4847) traffic_cop / _manager busted on current master?

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_cop / _manager busted on current master?
> 
>
> Key: TS-4847
> URL: https://issues.apache.org/jira/browse/TS-4847
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop, Manager
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I'm getting the following on current master (docs.trafficserver):
> {code}
> Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
> mgmt cli
> Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
> server is down
> {code}



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

[GitHub] trafficserver issue #1005: TS-4847: Local manager needs to register proxy.no...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1005
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/776/ 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-4847) traffic_cop / _manager busted on current master?

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4847: Local manager needs to register proxy.node.proxy_running.

traffic_cop checks proxy.node.proxy_running to verify the manager
is running. Since this metric is not in RecordsConfig.cc any more,
we need to register it before setting the value.

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

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

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

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


commit 6ec411cff0a65aa55e6704b9ee2ba74e592ed5c4
Author: James Peach 
Date:   2016-09-10T22:36:33Z

TS-4847: Local manager needs to register proxy.node.proxy_running.

traffic_cop checks proxy.node.proxy_running to verify the manager
is running. Since this metric is not in RecordsConfig.cc any more,
we need to register it before setting the value.




Issue Time Tracking
---

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

> traffic_cop / _manager busted on current master?
> 
>
> Key: TS-4847
> URL: https://issues.apache.org/jira/browse/TS-4847
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop, Manager
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I'm getting the following on current master (docs.trafficserver):
> {code}
> Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
> mgmt cli
> Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
> server is down
> {code}



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

[GitHub] trafficserver pull request #1005: TS-4847: Local manager needs to register p...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4847: Local manager needs to register proxy.node.proxy_running.

traffic_cop checks proxy.node.proxy_running to verify the manager
is running. Since this metric is not in RecordsConfig.cc any more,
we need to register it before setting the value.

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

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

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

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


commit 6ec411cff0a65aa55e6704b9ee2ba74e592ed5c4
Author: James Peach 
Date:   2016-09-10T22:36:33Z

TS-4847: Local manager needs to register proxy.node.proxy_running.

traffic_cop checks proxy.node.proxy_running to verify the manager
is running. Since this metric is not in RecordsConfig.cc any more,
we need to register it before setting the value.




---
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-4847) traffic_cop / _manager busted on current master?

[Leif Hedstrom (JIRA)]

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

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

> traffic_cop / _manager busted on current master?
> 
>
> Key: TS-4847
> URL: https://issues.apache.org/jira/browse/TS-4847
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop, Manager
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> I'm getting the following on current master (docs.trafficserver):
> {code}
> Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
> mgmt cli
> Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
> server is down
> {code}



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

[jira] [Updated] (TS-4847) traffic_cop / _manager busted on current master?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4847:
--
Assignee: James Peach

> traffic_cop / _manager busted on current master?
> 
>
> Key: TS-4847
> URL: https://issues.apache.org/jira/browse/TS-4847
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop, Manager
>Reporter: Leif Hedstrom
>Assignee: James Peach
>
> I'm getting the following on current master (docs.trafficserver):
> {code}
> Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
> mgmt cli
> Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
> server is down
> {code}



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

[jira] [Created] (TS-4847) traffic_cop / _manager busted on current master?

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4847:
-

 Summary: traffic_cop / _manager busted on current master?
 Key: TS-4847
 URL: https://issues.apache.org/jira/browse/TS-4847
 Project: Traffic Server
  Issue Type: Bug
  Components: Cop, Manager
Reporter: Leif Hedstrom


I'm getting the following on current master (docs.trafficserver):

{code}
Sep 10 19:29:37 qa1 traffic_cop[5217]: (cli test) could not communicate with 
mgmt cli
Sep 10 19:29:37 qa1 traffic_cop[5217]: could not contact manager, assuming 
server is down
{code}




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

[jira] [Updated] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

[James Peach (JIRA)]

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

James Peach updated TS-4838:

   Assignee: James Peach
Backport to Version: 6.2.1
  Fix Version/s: 7.0.0

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



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

[jira] [Created] (TS-4846) Make jemalloc a required dependency.

[James Peach (JIRA)]

James Peach created TS-4846:
---

 Summary: Make jemalloc a required dependency.
 Key: TS-4846
 URL: https://issues.apache.org/jira/browse/TS-4846
 Project: Traffic Server
  Issue Type: New Feature
  Components: Core, Performance
Reporter: James Peach


If we make {{jemalloc}} a required dependency, then all operators would better 
better performance without any special configuration. We can also then build 
tooling that used the jemalloc [heap 
profiling|https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling] 
and 
[statistics|https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Basic-Allocator-Statistics]
 support to get more information about memory and allocation patterns.



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

[jira] [Commented] (TS-4838) After TS-3612 restructuring, very slow SSL sessions and HttpSM::state_raw_http_server_open errors

[Dimitry Andric (JIRA)]

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

Dimitry Andric commented on TS-4838:


[~jamespeach], yes, that seems to work, with some light testing: haven't seen 
any stalls, and no more {{state_raw_http_server_open}} messages either.  I'll 
exercise it a bit more when I get to work on Monday.

> After TS-3612 restructuring, very slow SSL sessions and 
> HttpSM::state_raw_http_server_open errors
> -
>
> Key: TS-4838
> URL: https://issues.apache.org/jira/browse/TS-4838
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Affects Versions: 6.2.0, 7.0.0
> Environment: CentOS/RHEL 7.2, x86_64
>Reporter: Dimitry Andric
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have been using TrafficServer 5.3.2 for quite some time now, for forward 
> proxying of a number of different HTML5 applications, one of the most 
> important ones being YouTube's TV interface, e.g. https://youtube.com/tv.  
> This is all hosted on CentOS 7.2 x86_64 machines.
> We recently upgraded to 6.2.0, and then started having problems with the 
> CONNECT requests for port 443 which are generated by the YouTube app.  It 
> seems like these connections are "stalled" somehow, sometimes for >10 
> seconds.  Meanwhile, {{diags.log}} is getting spammed lots of the following:
> {noformat}
> [Sep  9 16:45:47.683] Server {0x2b3e50c0b700} ERROR: 
> [HttpSM::state_raw_http_server_open] event: EVENT_INTERVAL state: 0 
> server_entry: (nil)
> {noformat}
> Requests that seem to stall are most likely all of the CONNECT kind, e.g.:
> {noformat}
> 1473432382.474 30405 127.0.0.1 TCP_MISS/200 4916 CONNECT 
> ad.doubleclick.net:443/ - DIRECT/ad.doubleclick.net -
> 1473432382.481 30411 127.0.0.1 TCP_MISS/200 54024 CONNECT i9.ytimg.com:443/ - 
> DIRECT/i9.ytimg.com -
> 1473432382.486 30417 127.0.0.1 TCP_MISS/200 5389 CONNECT 
> pagead2.googlesyndication.com:443/ - DIRECT/pagead2.googlesyndication.com -
> 1473432390.451 42772 127.0.0.1 TCP_MISS/200 5198 CONNECT csi.gstatic.com:443/ 
> - DIRECT/csi.gstatic.com -
> 1473432390.459 43833 127.0.0.1 TCP_MISS/200 11610 CONNECT 
> www.youtube.com:443/ - DIRECT/www.youtube.com -
> 1473432390.483 38414 127.0.0.1 TCP_MISS/200 2870983 CONNECT 
> r17---sn-5hnednl7.googlevideo.com:443/ - 
> DIRECT/r17---sn-5hnednl7.googlevideo.com -
> {noformat}
> As part of figuring out how to diagnose this, I tried a downgrade to 
> TrafficServer 6.1.1, and this made all the stalling and problems disappear.  
> Afterwards, I did a {{git bisect}} on master, from the branch point of 6.1 to 
> the branch point of 6.2, and I ended up at [commit 
> af76977|https://git-dual.apache.org/repos/asf?p=trafficserver.git;a=commit;h=af76977adb9f3c0296a232688bbcb5a1421a6768]:
> {quote}
> Author: Susan Hinrichs 
> Date:   Wed Apr 13 19:57:39 2016 +
> TS-3612: Restructure client session and transaction processing. This 
> closes #570.
> {quote}
> Unfortunately, this is a quite big refactoring commit, so it is not possible 
> to revert it individually to see whether it improves things.
> I read TS-3612 and #570, and I saw there were also a number of follow-up 
> commits to fix various problems with it, but this particular problem of 
> stalled SSL connections is still occurring with master as of today, 
> 2016-09-09.
> I realize that this report is still missing reproduction details, since it is 
> tricky to analyze what the YouTube app is doing, and simple {{curl https://}} 
> tests appear to go fast, and don't seem to trigger any stalling.  But YouTube 
> itself is pretty easy to try out, I think.



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

[jira] [Work logged] (TS-4480) Wildcards in certificates should only match one level

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Wildcards in certificates should only match one level
> -
>
> Key: TS-4480
> URL: https://issues.apache.org/jira/browse/TS-4480
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Michael Sokolnicki
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: current_patch.diff
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> According to RFC 6125 section 6.4.3:
> {quote}
> If the wildcard character is the only character of the left-most label in the 
> presented identifier, the client SHOULD NOT compare against anything but the 
> left-most label of the reference identifier (e.g., *.example.com would match 
> foo.example.com but not bar.foo.example.com or example.com).
> {quote}
> In the current implementation, certificates are searched for in a trie, and 
> the longest match is returned, but there is no check if that match complies 
> with the above rule. This causes invalid certs to be returned and SLL errors 
> in the browser (in Firefox, we get SSL_ERROR_BAD_CERT_DOMAIN).



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

[GitHub] trafficserver issue #992: TS-4480: Wildcards in certificates should only mat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/992
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/775/ 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-4480) Wildcards in certificates should only match one level

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Wildcards in certificates should only match one level
> -
>
> Key: TS-4480
> URL: https://issues.apache.org/jira/browse/TS-4480
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Michael Sokolnicki
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: current_patch.diff
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> According to RFC 6125 section 6.4.3:
> {quote}
> If the wildcard character is the only character of the left-most label in the 
> presented identifier, the client SHOULD NOT compare against anything but the 
> left-most label of the reference identifier (e.g., *.example.com would match 
> foo.example.com but not bar.foo.example.com or example.com).
> {quote}
> In the current implementation, certificates are searched for in a trie, and 
> the longest match is returned, but there is no check if that match complies 
> with the above rule. This causes invalid certs to be returned and SLL errors 
> in the browser (in Firefox, we get SSL_ERROR_BAD_CERT_DOMAIN).



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

[GitHub] trafficserver issue #992: TS-4480: Wildcards in certificates should only mat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/992
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/671/ 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-4480) Wildcards in certificates should only match one level

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Wildcards in certificates should only match one level
> -
>
> Key: TS-4480
> URL: https://issues.apache.org/jira/browse/TS-4480
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Michael Sokolnicki
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: current_patch.diff
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> According to RFC 6125 section 6.4.3:
> {quote}
> If the wildcard character is the only character of the left-most label in the 
> presented identifier, the client SHOULD NOT compare against anything but the 
> left-most label of the reference identifier (e.g., *.example.com would match 
> foo.example.com but not bar.foo.example.com or example.com).
> {quote}
> In the current implementation, certificates are searched for in a trie, and 
> the longest match is returned, but there is no check if that match complies 
> with the above rule. This causes invalid certs to be returned and SLL errors 
> in the browser (in Firefox, we get SSL_ERROR_BAD_CERT_DOMAIN).



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

[GitHub] trafficserver issue #992: TS-4480: Wildcards in certificates should only mat...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/992
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/670/ 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-4480) Wildcards in certificates should only match one level

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Wildcards in certificates should only match one level
> -
>
> Key: TS-4480
> URL: https://issues.apache.org/jira/browse/TS-4480
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Michael Sokolnicki
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: current_patch.diff
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> According to RFC 6125 section 6.4.3:
> {quote}
> If the wildcard character is the only character of the left-most label in the 
> presented identifier, the client SHOULD NOT compare against anything but the 
> left-most label of the reference identifier (e.g., *.example.com would match 
> foo.example.com but not bar.foo.example.com or example.com).
> {quote}
> In the current implementation, certificates are searched for in a trie, and 
> the longest match is returned, but there is no check if that match complies 
> with the above rule. This causes invalid certs to be returned and SLL errors 
> in the browser (in Firefox, we get SSL_ERROR_BAD_CERT_DOMAIN).



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

[GitHub] trafficserver issue #992: TS-4480: Wildcards in certificates should only mat...

[atsci]

Github user atsci commented on the issue:

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



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

[jira] [Commented] (TS-4480) Wildcards in certificates should only match one level

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4480:


Fix is on PR #992.  Looks like I need to rebase it.

> Wildcards in certificates should only match one level
> -
>
> Key: TS-4480
> URL: https://issues.apache.org/jira/browse/TS-4480
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Michael Sokolnicki
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: current_patch.diff
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> According to RFC 6125 section 6.4.3:
> {quote}
> If the wildcard character is the only character of the left-most label in the 
> presented identifier, the client SHOULD NOT compare against anything but the 
> left-most label of the reference identifier (e.g., *.example.com would match 
> foo.example.com but not bar.foo.example.com or example.com).
> {quote}
> In the current implementation, certificates are searched for in a trie, and 
> the longest match is returned, but there is no check if that match complies 
> with the above rule. This causes invalid certs to be returned and SLL errors 
> in the browser (in Firefox, we get SSL_ERROR_BAD_CERT_DOMAIN).



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

Build failed in Jenkins: clang-analyzer #2620

[jenkins]

See 

Changes:

[shinrich] TS-4459: Force domain names in cert to be lowercase for lookup tree.

--
[...truncated 5337 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 71%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 72%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 72%] developer-guide/api/index.en
reading sources... [ 73%] 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... [ 74%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 74%] developer-guide/api/types/TSHttpType.en
reading sources... [ 75%] 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... [ 76%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 78%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 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... [ 84%] developer-guide/documentation/building.en
reading sources... [ 84%] 

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

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4459.

Resolution: Fixed

Odd, the PR seemed to get de-synced here too.  Finally addressed via PR 972.  
Commit # 12ab6b1f05c16416bc378af568f583b2147325d8

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



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

[jira] [Resolved] (TS-4503) MachineFatal should shutdown without cleanup

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4503.

Resolution: Fixed

Fixed by Commit 0ea702cc3399c4e3061b5d06bcc4cac2bc00f1a1

> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[jira] [Work logged] (TS-4503) MachineFatal should shutdown without cleanup

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

Worklog Id: (was: 28721)
Time Spent: 4h  (was: 3h 50m)

> MachineFatal should shutdown without cleanup
> 
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> When MachineFatalClass::raise() is called, it prints a message to the log and 
> then calls exit.  exit causes memory cleanup to be called.  But if we are in 
> such bad state that MachineFatal is called, it is quite likely that memory is 
> messed up.
> We saw a crash where MachineFatal is called in thread 84.  This stack has the 
> real error.  But the stack that got reported was on thread 1 in class 
> destructor logic.  It would have been better if ATS failed immediately and 
> the stack on thread 84 was reported.



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

[GitHub] trafficserver pull request #991: TS-4503: Replace MachineFatal by ink_abort

[shinrich]

Github user shinrich closed the pull request at:

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


---
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-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-4263.

Resolution: Fixed

Fixed by PR #942

Introduced as commit 1454812852ccc04635ce36db8afb81d7a6e5469e

> Session tickets keys in ssl_multicert.config do not work with SNI discovered 
> hosts
> --
>
> Key: TS-4263
> URL: https://issues.apache.org/jira/browse/TS-4263
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
>  Labels: A
> Fix For: 7.0.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI 
> negotiation to get a TLS session, then you can not configure the session 
> ticket keys block, at all. Meaning, there's no way to share the keys across 
> more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At 
> the point of resuming a session, the SSL call back provides the 16 byte 
> key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte 
> key-name, and keep a separate lookup table for the key blocks. This is in 
> itself a little ugly, because the ownerships around SSLCertContext is a 
> little murky. But it seems the cleanest, and definitely seemed to have been 
> the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to 
> remove the ticket_key_name= option from ssl_multicert.config entirely, and 
> only have a single, global key block configured via records.config.



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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/831
  
Sorry for the delay.  Looks good to me as well.


Issue Time Tracking
---

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

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

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

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

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

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

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/831
  
Sorry for the delay.  Looks good to me as well.


---
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 #831: TS-4475: Log Collation Client SM, added VC_...

[shinrich]

Github user shinrich closed the pull request at:

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


---
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-4806) Fix up event processor thread stacks

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/956
  
@PSUdaemon, the patch looks good, +1 on fixing the sleep(1).

Built and run it in production with ``exec_thread.affinity: 1`` and it run 
fine. 

Here some of the things I checked.

``numastat`` output looked pretty much the same like before the patch was 
applied

```
$ sudo numastat -p $(pgrep -f traffic_server)

Per-node process memory usage (in MBs) for PID 31075 ([TS_MAIN])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.520.942.46
Private 118751.97   119729.43   238481.40
  --- --- ---
Total   118753.49   119730.37   238483.86
```

"Stop using the main thread as ET_NET 0 ..." (from the Jira)
Here is a new thread showing now: TS_MAIN

```
$ ps -e -T -o 'pid,ucmd'|grep $(pgrep -f traffic_server)|cut -d" " -f2|sort 
|uniq -c
  5 [ACCEPT
 24 [ET_AIO
 24 [ET_NET
  1 [ET_OCSP
  2 [ET_TASK
  1 [LOG_FLUSH]
  1 [LOG_PREPROC
  2 traffic_server
  1 [TS_MAIN]
```

``traffic_server`` ``ET_NET`` threads are distributed evenly over the 2 
NUMA nodes on the machine where I tested (running on nodesets and bound to the 
corresponding cpusets as expected)

```
$  sudo lstopo --top --no-io -.xml|grep traffic_server|awk '{match($12, 
/(.*)"/, a); printf("%s %s ", $6, $9); system("ps -e -T -o pid,spid,ucmd|grep " 
a[1]);}'
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31101 
[ET_NET 22]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31099 
[ET_NET 20]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31097 
[ET_NET 18]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31095 
[ET_NET 16]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31093 
[ET_NET 14]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31091 
[ET_NET 12]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31089 
[ET_NET 10]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31087 
[ET_NET 8]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31085 
[ET_NET 6]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31083 
[ET_NET 4]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31081 
[ET_NET 2]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31079 
[ET_NET 0]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31102 [ET_NET 23]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31100 [ET_NET 21]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31098 [ET_NET 19]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31096 [ET_NET 17]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31094 [ET_NET 15]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31092 [ET_NET 13]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31090 [ET_NET 11]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31088 [ET_NET 9]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31086 [ET_NET 7]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31084 [ET_NET 5]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31082 [ET_NET 3]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31080 [ET_NET 1]
```


The NUMA policy is ``preferred=node0`` and ``preferred=node1`` for the 
corresponding stack segments.

```
$ for pid in `ps -e -T -o 'spid,ucmd'|grep ET_NET |cut -d" " -f1 `; do sudo 
grep stack /proc/${pid}/numa_maps; done| awk '{match($3, /.*:(.*)/, a); 
printf("%s ", $2); system("ps -e -T -o pid,spid,ucmd|grep " a[1])}' |sort -u
. . .
prefer:0 31075 31079 [ET_NET 0]
prefer:0 31075 31080 [ET_NET 1]
prefer:0 31075 31081 [ET_NET 2]
prefer:0 

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

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver pull request #972: TS-4459: Force domain names in cert to be l...

[shinrich]

Github user shinrich closed the pull request at:

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


---
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 #956: TS-4806: Fix up event processor thread stacks

[gtenev]

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/956
  
@PSUdaemon, the patch looks good, +1 on fixing the sleep(1).

Built and run it in production with ``exec_thread.affinity: 1`` and it run 
fine. 

Here some of the things I checked.

``numastat`` output looked pretty much the same like before the patch was 
applied

```
$ sudo numastat -p $(pgrep -f traffic_server)

Per-node process memory usage (in MBs) for PID 31075 ([TS_MAIN])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.520.942.46
Private 118751.97   119729.43   238481.40
  --- --- ---
Total   118753.49   119730.37   238483.86
```

"Stop using the main thread as ET_NET 0 ..." (from the Jira)
Here is a new thread showing now: TS_MAIN

```
$ ps -e -T -o 'pid,ucmd'|grep $(pgrep -f traffic_server)|cut -d" " -f2|sort 
|uniq -c
  5 [ACCEPT
 24 [ET_AIO
 24 [ET_NET
  1 [ET_OCSP
  2 [ET_TASK
  1 [LOG_FLUSH]
  1 [LOG_PREPROC
  2 traffic_server
  1 [TS_MAIN]
```

``traffic_server`` ``ET_NET`` threads are distributed evenly over the 2 
NUMA nodes on the machine where I tested (running on nodesets and bound to the 
corresponding cpusets as expected)

```
$  sudo lstopo --top --no-io -.xml|grep traffic_server|awk '{match($12, 
/(.*)"/, a); printf("%s %s ", $6, $9); system("ps -e -T -o pid,spid,ucmd|grep " 
a[1]);}'
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31101 
[ET_NET 22]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31099 
[ET_NET 20]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31097 
[ET_NET 18]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31095 
[ET_NET 16]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31093 
[ET_NET 14]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31091 
[ET_NET 12]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31089 
[ET_NET 10]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31087 
[ET_NET 8]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31085 
[ET_NET 6]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31083 
[ET_NET 4]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31081 
[ET_NET 2]
allowed_cpuset="0x3ff003ff" allowed_nodeset="0x0001" 31075 31079 
[ET_NET 0]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31102 [ET_NET 23]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31100 [ET_NET 21]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31098 [ET_NET 19]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31096 [ET_NET 17]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31094 [ET_NET 15]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31092 [ET_NET 13]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31090 [ET_NET 11]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31088 [ET_NET 9]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31086 [ET_NET 7]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31084 [ET_NET 5]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31082 [ET_NET 3]
allowed_cpuset="0x00ff,0xc00ffc00" allowed_nodeset="0x0002" 31075 
31080 [ET_NET 1]
```


The NUMA policy is ``preferred=node0`` and ``preferred=node1`` for the 
corresponding stack segments.

```
$ for pid in `ps -e -T -o 'spid,ucmd'|grep ET_NET |cut -d" " -f1 `; do sudo 
grep stack /proc/${pid}/numa_maps; done| awk '{match($3, /.*:(.*)/, a); 
printf("%s ", $2); system("ps -e -T -o pid,spid,ucmd|grep " a[1])}' |sort -u
. . .
prefer:0 31075 31079 [ET_NET 0]
prefer:0 31075 31080 [ET_NET 1]
prefer:0 31075 31081 [ET_NET 2]
prefer:0 31075 31082 [ET_NET 3]
. . .
prefer:0 31075 31100 [ET_NET 21]
prefer:0 31075 31101 [ET_NET 22]
prefer:0 31075 31102 [ET_NET 23]
. . .
prefer:1 31075 31079 [ET_NET 0]
prefer:1 31075 31080 [ET_NET 1]
prefer:1 31075 31081 [ET_NET 2]
prefer:1 31075 31082 [ET_NET 3]
. . .
prefer:1 31075 31100 [ET_NET 21]
prefer:1 31075 31101 [ET_NET 22]
prefer:1 31075 31102 

[GitHub] trafficserver pull request #956: TS-4806: Fix up event processor thread stac...

[gtenev]

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

https://github.com/apache/trafficserver/pull/956#discussion_r78275728
  
--- Diff: iocore/eventsystem/UnixEventProcessor.cc ---
@@ -129,34 +197,58 @@ EventProcessor::start(int n_event_threads, size_t 
stacksize)
 obj_name = (char *)"Machine";
   }
 
+  // How many of the above `obj_type` do we have in our topology?
   obj_count = hwloc_get_nbobjs_by_type(ink_get_topology(), obj_type);
   Debug("iocore_thread", "Affinity: %d %ss: %d PU: %d", affinity, 
obj_name, obj_count, ink_number_of_processors());
 
 #endif
   for (i = 0; i < n_ethreads; i++) {
 ink_thread tid;
-if (i > 0) {
-  snprintf(thr_name, MAX_THREAD_NAME_LENGTH, "[ET_NET %d]", i);
-  tid = all_ethreads[i]->start(thr_name, stacksize);
-} else {
-  tid = ink_thread_self();
-}
+
 #if TS_USE_HWLOC
 if (obj_count > 0) {
+  // Get our `obj` instance with index based on the thread number we 
are on.
   obj = hwloc_get_obj_by_type(ink_get_topology(), obj_type, i % 
obj_count);
--- End diff --

We could defensively check/handle ``NULL`` to "protect" ``obj->cpuset`` 
later.




---
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-4806) Fix up event processor thread stacks

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/956#discussion_r78275728
  
--- Diff: iocore/eventsystem/UnixEventProcessor.cc ---
@@ -129,34 +197,58 @@ EventProcessor::start(int n_event_threads, size_t 
stacksize)
 obj_name = (char *)"Machine";
   }
 
+  // How many of the above `obj_type` do we have in our topology?
   obj_count = hwloc_get_nbobjs_by_type(ink_get_topology(), obj_type);
   Debug("iocore_thread", "Affinity: %d %ss: %d PU: %d", affinity, 
obj_name, obj_count, ink_number_of_processors());
 
 #endif
   for (i = 0; i < n_ethreads; i++) {
 ink_thread tid;
-if (i > 0) {
-  snprintf(thr_name, MAX_THREAD_NAME_LENGTH, "[ET_NET %d]", i);
-  tid = all_ethreads[i]->start(thr_name, stacksize);
-} else {
-  tid = ink_thread_self();
-}
+
 #if TS_USE_HWLOC
 if (obj_count > 0) {
+  // Get our `obj` instance with index based on the thread number we 
are on.
   obj = hwloc_get_obj_by_type(ink_get_topology(), obj_type, i % 
obj_count);
--- End diff --

We could defensively check/handle ``NULL`` to "protect" ``obj->cpuset`` 
later.




Issue Time Tracking
---

Worklog Id: (was: 28716)
Time Spent: 4h  (was: 3h 50m)

> Fix up event processor thread stacks
> 
>
> Key: TS-4806
> URL: https://issues.apache.org/jira/browse/TS-4806
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Fix event processor to create stacks on the appropriate numa node and with 
> the appropriate page size. Also, stop using the main thread as ET_NET 0 since 
> we can't control any of these aspects of it.



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/972
  
It seems reasonable.  


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #972: TS-4459: Force domain names in cert to be lowercas...

[maskit]

Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/972
  
It seems reasonable. 👍 


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