[jira] [Work logged] (TS-4763) Consistent request bytes logging tags.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/880#discussion_r75420890
  
--- Diff: proxy/logging/LogAccessHttp.cc ---
@@ -769,8 +782,11 @@ LogAccessHttp::marshal_client_req_uuid(char *buf)
 const char *uuid = (char *)Machine::instance()->uuid.getString();
 int len;
 
-len = snprintf(str, _MAX_CRUUID_LEN, "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
-marshal_str(buf, str, round_strlen(len + 1));
+len = snprintf(str, sizeof(str), "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
--- End diff --



> On Aug 18, 2016, at 7:25 PM, Leif Hedstrom  
wrote:
> 
> In proxy/logging/LogAccessHttp.cc:
> 
> > @@ -769,8 +782,11 @@ LogAccessHttp::marshal_client_req_uuid(char *buf)
> >  const char *uuid = (char *)Machine::instance()->uuid.getString();
> >  int len;
> >  
> > -len = snprintf(str, _MAX_CRUUID_LEN, "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
> > -marshal_str(buf, str, round_strlen(len + 1));
> > +len = snprintf(str, sizeof(str), "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
> Isn't this fixed/addressed in a separate PR?
> 
Yeh I just branched this from the other PR


> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 



Issue Time Tracking
---

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

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[GitHub] trafficserver pull request #880: TS-4763: Consistent request bytes logging t...

[jpeach]

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

https://github.com/apache/trafficserver/pull/880#discussion_r75420890
  
--- Diff: proxy/logging/LogAccessHttp.cc ---
@@ -769,8 +782,11 @@ LogAccessHttp::marshal_client_req_uuid(char *buf)
 const char *uuid = (char *)Machine::instance()->uuid.getString();
 int len;
 
-len = snprintf(str, _MAX_CRUUID_LEN, "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
-marshal_str(buf, str, round_strlen(len + 1));
+len = snprintf(str, sizeof(str), "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
--- End diff --



> On Aug 18, 2016, at 7:25 PM, Leif Hedstrom  
wrote:
> 
> In proxy/logging/LogAccessHttp.cc:
> 
> > @@ -769,8 +782,11 @@ LogAccessHttp::marshal_client_req_uuid(char *buf)
> >  const char *uuid = (char *)Machine::instance()->uuid.getString();
> >  int len;
> >  
> > -len = snprintf(str, _MAX_CRUUID_LEN, "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
> > -marshal_str(buf, str, round_strlen(len + 1));
> > +len = snprintf(str, sizeof(str), "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
> Isn't this fixed/addressed in a separate PR?
> 
Yeh I just branched this from the other PR


> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 



---
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-4466) Add links to other versions/languages of the documentation

[Masakazu Kitajo (JIRA)]

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

Masakazu Kitajo resolved TS-4466.
-
Resolution: Fixed

Closing this because the changes are already committed on master, and they are 
now totally different from the original ones.

> Add links to other versions/languages of the documentation
> --
>
> Key: TS-4466
> URL: https://issues.apache.org/jira/browse/TS-4466
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> The documentation pages generated with sphinx have lost links to other 
> versions or languages of the documentation since we moved them from RTD.
> It would be better to add the links so that we can know existence of other 
> versions and can choose them easily.



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

[jira] [Work logged] (TS-4763) Consistent request bytes logging tags.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/880#discussion_r75419974
  
--- Diff: proxy/logging/LogAccess.cc ---
@@ -326,11 +328,11 @@ LogAccess::marshal_proxy_resp_content_type(char *buf)
 /*-
   
-*/
 
-int
-LogAccess::marshal_proxy_resp_squid_len(char *buf)
-{
-  DEFAULT_INT_FIELD;
-}
+LOG_ACCESS_DEFAULT_FIELD(marshal_proxy_resp_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_client_req_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_proxy_req_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_server_resp_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_cache_resp_squid_len, DEFAULT_INT_FIELD)
--- End diff --

I guess I'm ok with this, just seems a little odd and wildly different from 
all other similar code, no?


Issue Time Tracking
---

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

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[GitHub] trafficserver pull request #880: TS-4763: Consistent request bytes logging t...

[zwoop]

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

https://github.com/apache/trafficserver/pull/880#discussion_r75419974
  
--- Diff: proxy/logging/LogAccess.cc ---
@@ -326,11 +328,11 @@ LogAccess::marshal_proxy_resp_content_type(char *buf)
 /*-
   
-*/
 
-int
-LogAccess::marshal_proxy_resp_squid_len(char *buf)
-{
-  DEFAULT_INT_FIELD;
-}
+LOG_ACCESS_DEFAULT_FIELD(marshal_proxy_resp_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_client_req_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_proxy_req_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_server_resp_squid_len, DEFAULT_INT_FIELD)
+LOG_ACCESS_DEFAULT_FIELD(marshal_cache_resp_squid_len, DEFAULT_INT_FIELD)
--- End diff --

I guess I'm ok with this, just seems a little odd and wildly different from 
all other similar code, no?


---
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-4763) Consistent request bytes logging tags.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/880#discussion_r75419879
  
--- Diff: proxy/logging/LogAccessHttp.cc ---
@@ -769,8 +782,11 @@ LogAccessHttp::marshal_client_req_uuid(char *buf)
 const char *uuid = (char *)Machine::instance()->uuid.getString();
 int len;
 
-len = snprintf(str, _MAX_CRUUID_LEN, "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
-marshal_str(buf, str, round_strlen(len + 1));
+len = snprintf(str, sizeof(str), "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
--- End diff --

Isn't this fixed/addressed in a separate PR?


Issue Time Tracking
---

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

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[GitHub] trafficserver pull request #880: TS-4763: Consistent request bytes logging t...

[zwoop]

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

https://github.com/apache/trafficserver/pull/880#discussion_r75419879
  
--- Diff: proxy/logging/LogAccessHttp.cc ---
@@ -769,8 +782,11 @@ LogAccessHttp::marshal_client_req_uuid(char *buf)
 const char *uuid = (char *)Machine::instance()->uuid.getString();
 int len;
 
-len = snprintf(str, _MAX_CRUUID_LEN, "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
-marshal_str(buf, str, round_strlen(len + 1));
+len = snprintf(str, sizeof(str), "%s-%" PRId64 "", uuid, 
m_http_sm->sm_id);
--- End diff --

Isn't this fixed/addressed in a separate 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 issue #872: TS-4735: Fix race condition in traffic_server star...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/872
  
Curious, where do these messages come from? Is that related to  clustering? 
[approveci]


---
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-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/872
  
Curious, where do these messages come from? Is that related to  clustering? 
[approveci]


Issue Time Tracking
---

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

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



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

[GitHub] trafficserver issue #873: fix 5 bugs about parent strategy

[keith2008]

Github user keith2008 commented on the issue:

https://github.com/apache/trafficserver/pull/873
  
@jrushford @zwoop OK,i have closed this pull. if you have time, please 
review my code on: https://github.com/keith2008/trafficserver


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877#discussion_r75416546
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if 

[GitHub] trafficserver pull request #877: TS-4755: Header Frequency plugin. Initial v...

[petarpenkov]

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

https://github.com/apache/trafficserver/pull/877#discussion_r75416546
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if (map.find(str) == map.end()) {
+  // Not found.
+  map[str] = 1;
+ } else {
+  // Found.
+  ++map[str];
+}
+
+TSHandleMLocRelease(bufp, hdr_loc, hdr);
+hdr = next_hdr;
+  }
+
+  TSHandleMLocRelease(bufp, TS_NULL_MLOC, hdr_loc);
+}
+
+/**
+ * Continuation callback. Invoked to count headers on READ_REQUEST_HDR and
+ * 

[jira] [Updated] (TS-4546) Build errors for H2 tests on OmniOS

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4546:

Assignee: Masakazu Kitajo  (was: Masaori Koshiba)

> Build errors for H2 tests on OmniOS
> ---
>
> Key: TS-4546
> URL: https://issues.apache.org/jira/browse/TS-4546
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, Tests
>Reporter: Leif Hedstrom
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {code}
>   CXX  test_HPACK.o
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc: In function 
> ‘int prepare()’:
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:12: error: 
> ‘struct dirent’ has no member named ‘d_type’
>  if (d->d_type == DT_REG) {
> ^
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:22: error: 
> ‘DT_REG’ was not declared in this scope
>  if (d->d_type == DT_REG) {
>   ^
> {code}



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

[jira] [Work logged] (TS-4743) parent use consistent_hash Strategy may cause crash while first parent is not set

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> parent use consistent_hash Strategy may cause crash while first parent is not 
> set 
> --
>
> Key: TS-4743
> URL: https://issues.apache.org/jira/browse/TS-4743
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> my parent.config
> eg :
> dest_domain=.  secondary_parent="192.168.104.229:80|1.0; 
> 192.168.104.182:80|1.0"  round_robin=consistent_hash
> the crash place is :
> DEBUG:  (parent_select) 
> wrap_around[PRIMARY]: 1, wrap_around[SECONDARY]: 0
> traffic_server: Segmentation fault (Address not mapped to object [0x10])
> ParentConsistentHash.cc:167 code:
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec->hostname);
> Fix the code like
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec ? pRec->hostname:"[NULL]");



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

[GitHub] trafficserver pull request #873: fix 5 bugs about parent strategy

[keith2008]

Github user keith2008 closed the pull request at:

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


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877
  
I have mixed feelings on the custom log for this. This is really for 
intermittent testing of behavior, similar to e.g. the memory usage dump 
feature. I.e. I can't imagine someone would use this in a way where it dumps 
the metrics more than a handful of times.


Issue Time Tracking
---

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

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



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

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

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
I have mixed feelings on the custom log for this. This is really for 
intermittent testing of behavior, similar to e.g. the memory usage dump 
feature. I.e. I can't imagine someone would use this in a way where it dumps 
the metrics more than a handful of times.


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877#discussion_r75409617
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if 

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877#discussion_r75409533
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if 

[GitHub] trafficserver pull request #877: TS-4755: Header Frequency plugin. Initial v...

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/877#discussion_r75409617
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if (map.find(str) == map.end()) {
+  // Not found.
+  map[str] = 1;
+ } else {
+  // Found.
+  ++map[str];
+}
+
+TSHandleMLocRelease(bufp, hdr_loc, hdr);
+hdr = next_hdr;
+  }
+
+  TSHandleMLocRelease(bufp, TS_NULL_MLOC, hdr_loc);
+}
+
+/**
+ * Continuation callback. Invoked to count headers on READ_REQUEST_HDR and

[GitHub] trafficserver pull request #877: TS-4755: Header Frequency plugin. Initial v...

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/877#discussion_r75409533
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if (map.find(str) == map.end()) {
+  // Not found.
+  map[str] = 1;
+ } else {
+  // Found.
+  ++map[str];
+}
+
+TSHandleMLocRelease(bufp, hdr_loc, hdr);
+hdr = next_hdr;
+  }
+
+  TSHandleMLocRelease(bufp, TS_NULL_MLOC, hdr_loc);
+}
+
+/**
+ * Continuation callback. Invoked to count headers on READ_REQUEST_HDR and

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877#discussion_r75408582
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if 

[GitHub] trafficserver pull request #877: TS-4755: Header Frequency plugin. Initial v...

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/877#discussion_r75408582
  
--- Diff: plugins/experimental/header_freq/header_freq.cc ---
@@ -0,0 +1,260 @@
+/** @file
+
+  This plugin counts the number of times every header has appeared.
+  Maintains separate counts for client and origin headers.
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+// plugin registration info
+static char plugin_name[]   = "header_freq";
+static char vendor_name[]   = "Apache Software Foundation";
+static char support_email[] = "d...@trafficserver.apache.org";
+
+// debug messages during one-time initialization
+static const char DEBUG_TAG_INIT[] = "header_freq.init";
+
+// debug messages in continuation callbacks
+static const char DEBUG_TAG_HOOK[] = "header_freq.hook";
+
+// maps from header name to # of times encountered
+static std::map client_freq;
+static std::map origin_freq;
+
+// for traffic_ctl, name is a convenient identifier
+static const char *ctl_tag = plugin_name;
+static const char *ctl_log = "log"; // log all data
+
+static TSMutex freq_mutex;  // lock on global data
+static const int retry_time = 10;   // spin after TSMutexLockTry failures
+
+static const char *log_name = plugin_name;
+static TSTextLogObject log;
+
+static bool
+freq_lock_try(TSCont contp)
+{
+  if (TSMutexLockTry(freq_mutex) != TS_SUCCESS) {
+TSDebug(DEBUG_TAG_HOOK, "Unable to acquire lock. Retrying in %d "
+"milliseconds", retry_time);
+TSContSchedule(contp, retry_time, TS_THREAD_POOL_DEFAULT);
+return false;
+  }
+  return true;
+}
+
+/**
+ * Logs the data collected, first the client, and then
+ * the origin headers.
+ */
+static void
+log_frequencies()
+{
+  std::stringstream ss("");
+
+  ss << std::endl << std::string(100, '+') << std::endl;
+
+  ss << "CLIENT HEADERS" << std::endl;
+  for (auto : client_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::endl;
+
+  ss << "ORIGIN HEADERS" << std::endl;
+  for (auto : origin_freq) {
+ss << elem.first << ": " << elem.second << std::endl;
+  }
+
+  ss << std::string(100, '+') << std::endl;
+  TSTextLogObjectWrite(log, "%s", ss.str().c_str());
+}
+
+/**
+ * Records all headers found in the buffer in the map provided. Comparison
+ * against existing entries is case-insensitive.
+ */
+static void
+count_all_headers(TSMBuffer , TSMLoc _loc, std::map )
+{
+  TSMLoc hdr, next_hdr;
+  hdr = TSMimeHdrFieldGet(bufp, hdr_loc, 0);
+  int n_headers = TSMimeHdrFieldsCount(bufp, hdr_loc);
+  TSDebug(DEBUG_TAG_HOOK, "%d headers found", n_headers);
+
+  // iterate through all headers
+  for (int i = 0; i < n_headers; ++i) {
+if (hdr == NULL)
+  break;
+next_hdr = TSMimeHdrFieldNext(bufp, hdr_loc, hdr);
+int hdr_len;
+const char *hdr_name = TSMimeHdrFieldNameGet(bufp, hdr_loc, hdr, 
_len);
+
+std::string str = std::string(hdr_name, hdr_len);
+
+// make case-insensitive by converting to lowercase
+for (auto : str) {
+  c = tolower(c);
+}
+
+// count the header
+if (map.find(str) == map.end()) {
+  // Not found.
+  map[str] = 1;
+ } else {
+  // Found.
+  ++map[str];
--- End diff --

If you use `find` then capture the iterator returned so you don't have to 
do the lookup again via the array operator. It might even be the case that the 
`int` default constructs to 0 so just `++map[str]` would suffice.


---
If your 

[jira] [Work logged] (TS-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver issue #879: TS-2153 : Add -M to traffic_manager options if nee...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/879
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/453/ 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-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver issue #879: TS-2153 : Add -M to traffic_manager options if nee...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/879
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/557/ 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] [Resolved] (TS-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

[James Peach (JIRA)]

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

James Peach resolved TS-4697.
-
Resolution: Fixed

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



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

[jira] [Work logged] (TS-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver issue #879: TS-2153 : Add -M to traffic_manager options if nee...

[jpeach]

Github user jpeach commented on the issue:

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



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

[jira] [Work logged] (TS-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/879#discussion_r75400338
  
--- Diff: mgmt/LocalManager.cc ---
@@ -900,6 +900,10 @@ LocalManager::startProxy()
 
 real_proxy_options.append(proxy_options, strlen(proxy_options));
 
+if (!strstr(proxy_options, "-M")) { // Make sure we're starting the 
proxy in mgmt mode
+  real_proxy_options.append(" -M ", strlen(" -M "));
--- End diff --

I tested without the trailing space and it worked so I removed it.


Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver pull request #879: TS-2153 : Add -M to traffic_manager options...

[strotyl]

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

https://github.com/apache/trafficserver/pull/879#discussion_r75400338
  
--- Diff: mgmt/LocalManager.cc ---
@@ -900,6 +900,10 @@ LocalManager::startProxy()
 
 real_proxy_options.append(proxy_options, strlen(proxy_options));
 
+if (!strstr(proxy_options, "-M")) { // Make sure we're starting the 
proxy in mgmt mode
+  real_proxy_options.append(" -M ", strlen(" -M "));
--- End diff --

I tested without the trailing space and it worked so I removed 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.
---

[GitHub] trafficserver pull request #823: TS-4697: free MIOBuffer if fails on ipallow...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



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

Build failed in Jenkins: clang-analyzer #2547

[jenkins]

See 

Changes:

[tstroh] TS-4696: Coverity 1267824: Missing unlock in mgmt/Alarms.cc

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

[jira] [Work logged] (TS-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



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

[GitHub] trafficserver issue #823: TS-4697: free MIOBuffer if fails on ipallow check.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/823
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/452/ 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-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



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

[GitHub] trafficserver issue #823: TS-4697: free MIOBuffer if fails on ipallow check.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/823
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/556/ 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-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver issue #879: TS-2153 : Add -M to traffic_manager options if nee...

[atsci]

Github user atsci commented on the issue:

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



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

[GitHub] trafficserver issue #823: TS-4697: free MIOBuffer if fails on ipallow check.

[jpeach]

Github user jpeach commented on the issue:

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


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

[jira] [Work logged] (TS-4697) MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> MIOBuffer is not freed if ipallow check fails in HttpSessionAccept::accept()
> 
>
> Key: TS-4697
> URL: https://issues.apache.org/jira/browse/TS-4697
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> {code}
> void
> HttpSessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
> IOBufferReader *reader)
> {
>   sockaddr const *client_ip = netvc->get_remote_addr();
>   const AclRecord *acl_record = NULL;
>   ip_port_text_buffer ipb;
>   IpAllow::scoped_config ipallow;
>   // The backdoor port is now only bound to "localhost", so no
>   // reason to check for if it's incoming from "localhost" or not.
>   if (backdoor) {
> acl_record = IpAllow::AllMethodAcl();
>   } else if (ipallow && (((acl_record = ipallow->match(client_ip)) == NULL) 
> || (acl_record->isEmpty( {
> 
> // if client address forbidden, close immediately //
> 
> Warning("client '%s' prohibited by ip-allow policy", 
> ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
> netvc->do_io_close();
> return;   // ->  MIOBuffer did not free.
>   }
> ...
> {code}



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

[jira] [Resolved] (TS-4668) Coverity 1021677, 1021676 : Uninitialized members in traffic_top/stats.h

[James Peach (JIRA)]

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

James Peach resolved TS-4668.
-
Resolution: Fixed

> Coverity 1021677, 1021676 : Uninitialized members in traffic_top/stats.h
> 
>
> Key: TS-4668
> URL: https://issues.apache.org/jira/browse/TS-4668
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tools
>Reporter: Leif Hedstrom
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Not sure why it discovered these now, but filing this regardless :).
> {code}
> ** CID 1021677:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 36 in LookupItem::LookupItem(const char *, const 
> char *, int)()
> 
> *** CID 1021677:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 36 in LookupItem::LookupItem(const char *, const 
> char *, int)()
> 30 #include 
> 31 #include "mgmtapi.h"
> 32 
> 33 using namespace std;
> 34 
> 35 struct LookupItem {
>CID 1021677:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "denominator" is not initialized in this 
> constructor nor in any functions that it calls.
> 36   LookupItem(const char *s, const char *n, const int t) : pretty(s), 
> name(n), type(t) {}
> 37   LookupItem(const char *s, const char *n, const char *d, const int t) 
> : pretty(s), name(n), numerator(n), denominator(d), type(t)
> 38   {
> 39   }
> 40   const char *pretty;
> 41   const char *name;
> ** CID 1021676:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 237 in Stats::Stats(const std::basic_string std::char_traits, std::allocator>&)()
> 
> *** CID 1021676:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 237 in Stats::Stats(const std::basic_string std::char_traits, std::allocator>&)()
> 231 
> 232 lookup_table.insert(make_pair("total_time", LookupItem("Total 
> Time", "proxy.process.http.total_transactions_time", 2)));
> 233 
> 234 // ratio
> 235 lookup_table.insert(make_pair("client_req_time", LookupItem("Resp 
> (ms)", "total_time", "client_req", 3)));
> 236 lookup_table.insert(make_pair("client_dyn_ka", 
> LookupItem("Dynamic KA", "ka_total", "ka_count", 3)));
>CID 1021676:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member field "_time.tv_usec" is not initialized in this 
> constructor nor in any functions that it calls.
> 237   }
> 238 
> 239   void
> 240   getStats()
> 241   {
> 242 if (_url == "") {
> {code}



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

[jira] [Work logged] (TS-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[jira] [Work logged] (TS-4668) Coverity 1021677, 1021676 : Uninitialized members in traffic_top/stats.h

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Coverity 1021677, 1021676 : Uninitialized members in traffic_top/stats.h
> 
>
> Key: TS-4668
> URL: https://issues.apache.org/jira/browse/TS-4668
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tools
>Reporter: Leif Hedstrom
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Not sure why it discovered these now, but filing this regardless :).
> {code}
> ** CID 1021677:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 36 in LookupItem::LookupItem(const char *, const 
> char *, int)()
> 
> *** CID 1021677:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 36 in LookupItem::LookupItem(const char *, const 
> char *, int)()
> 30 #include 
> 31 #include "mgmtapi.h"
> 32 
> 33 using namespace std;
> 34 
> 35 struct LookupItem {
>CID 1021677:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "denominator" is not initialized in this 
> constructor nor in any functions that it calls.
> 36   LookupItem(const char *s, const char *n, const int t) : pretty(s), 
> name(n), type(t) {}
> 37   LookupItem(const char *s, const char *n, const char *d, const int t) 
> : pretty(s), name(n), numerator(n), denominator(d), type(t)
> 38   {
> 39   }
> 40   const char *pretty;
> 41   const char *name;
> ** CID 1021676:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 237 in Stats::Stats(const std::basic_string std::char_traits, std::allocator>&)()
> 
> *** CID 1021676:  Uninitialized members  (UNINIT_CTOR)
> /cmd/traffic_top/stats.h: 237 in Stats::Stats(const std::basic_string std::char_traits, std::allocator>&)()
> 231 
> 232 lookup_table.insert(make_pair("total_time", LookupItem("Total 
> Time", "proxy.process.http.total_transactions_time", 2)));
> 233 
> 234 // ratio
> 235 lookup_table.insert(make_pair("client_req_time", LookupItem("Resp 
> (ms)", "total_time", "client_req", 3)));
> 236 lookup_table.insert(make_pair("client_dyn_ka", 
> LookupItem("Dynamic KA", "ka_total", "ka_count", 3)));
>CID 1021676:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member field "_time.tv_usec" is not initialized in this 
> constructor nor in any functions that it calls.
> 237   }
> 238 
> 239   void
> 240   getStats()
> 241   {
> 242 if (_url == "") {
> {code}



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

[GitHub] trafficserver pull request #875: TS-4668: CID 1021677, 1021676: Uninitialize...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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 #879: TS-2153 : Add -M to traffic_manager options if nee...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/879
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/555/ 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] [Assigned] (TS-4733) Cache writes fail when client requests IMS and server replies 200

[Shrihari (JIRA)]

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

Shrihari reassigned TS-4733:


Assignee: Shrihari

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



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

[jira] [Resolved] (TS-4696) CID 1267824: Missing unlock in mgmt/Alarms.cc

[James Peach (JIRA)]

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

James Peach resolved TS-4696.
-
Resolution: Fixed

> CID 1267824: Missing unlock in mgmt/Alarms.cc
> -
>
> Key: TS-4696
> URL: https://issues.apache.org/jira/browse/TS-4696
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {code}
> 2. lock: ink_mutex_acquire locks this->mutex. [show details]
>   ink_mutex_acquire();
>   if (!((n + (int)strlen("type: alarm\n")) < max)) {
> if (max >= 1) {
>   message[0] = '\0';
> }
> CID 1267824 (#1 of 1): Missing unlock (LOCK)
> 5. missing_unlock: Returning without unlocking this->mutex.
>return;
>   }
> {code}



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

[jira] [Work logged] (TS-4696) CID 1267824: Missing unlock in mgmt/Alarms.cc

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> CID 1267824: Missing unlock in mgmt/Alarms.cc
> -
>
> Key: TS-4696
> URL: https://issues.apache.org/jira/browse/TS-4696
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Tyler Stroh
>Assignee: Tyler Stroh
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {code}
> 2. lock: ink_mutex_acquire locks this->mutex. [show details]
>   ink_mutex_acquire();
>   if (!((n + (int)strlen("type: alarm\n")) < max)) {
> if (max >= 1) {
>   message[0] = '\0';
> }
> CID 1267824 (#1 of 1): Missing unlock (LOCK)
> 5. missing_unlock: Returning without unlocking this->mutex.
>return;
>   }
> {code}



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

[jira] [Work logged] (TS-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/879#discussion_r75394048
  
--- Diff: mgmt/LocalManager.cc ---
@@ -900,6 +900,10 @@ LocalManager::startProxy()
 
 real_proxy_options.append(proxy_options, strlen(proxy_options));
 
+if (!strstr(proxy_options, "-M")) { // Make sure we're starting the 
proxy in mgmt mode
+  real_proxy_options.append(" -M ", strlen(" -M "));
--- End diff --

I don't think you need to append the trailing space.


Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver pull request #874: TS-4696: Coverity 1267824: Missing unlock i...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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 #879: TS-2153 : Add -M to traffic_manager options...

[jpeach]

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

https://github.com/apache/trafficserver/pull/879#discussion_r75394048
  
--- Diff: mgmt/LocalManager.cc ---
@@ -900,6 +900,10 @@ LocalManager::startProxy()
 
 real_proxy_options.append(proxy_options, strlen(proxy_options));
 
+if (!strstr(proxy_options, "-M")) { // Make sure we're starting the 
proxy in mgmt mode
+  real_proxy_options.append(" -M ", strlen(" -M "));
--- End diff --

I don't think you need to append the trailing space.


---
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-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver issue #879: TS-2153 : Add -M to traffic_manager options if nee...

[jpeach]

Github user jpeach commented on the issue:

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



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

[jira] [Work logged] (TS-4763) Consistent request bytes logging tags.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[jira] [Work logged] (TS-4763) Consistent request bytes logging tags.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[GitHub] trafficserver issue #880: TS-4763: Consistent request bytes logging tags.

[atsci]

Github user atsci commented on the issue:

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



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

[GitHub] trafficserver issue #880: TS-4763: Consistent request bytes logging tags.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/880
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/450/ 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-4763) Consistent request bytes logging tags.

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4763: Consistent request bytes logging tags.

Make the byte count logging tags consistent. We have

- ``cqbl`` - client request body length
- ``cqhl`` - client request header length
- ``pscl`` - client response body length
- ``pshl`` - client response header length
- ``psql`` - client response total length
- ``pqbl`` - server request body length
- ``pqhl`` - server request header length
- ``sscl`` - server response body length
- ``sshl`` - server response header length

We should add ``*ql`` to get the missing totals and standardize on ``*cl`` 
for the content length (``csscl`` marginally tips the balance towards "content 
length" in favor of "body length").

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

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

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

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


commit 7e12104cecd01a1f93d3bfb35d60b41ba705f2a3
Author: James Peach 
Date:   2016-08-18T18:42:15Z

TS-4764: Return the aligned field size from marshal_client_req_uuid().

commit d81b884237806ff93236fe8bf11b8e4e66233aa6
Author: James Peach 
Date:   2016-08-18T20:29:25Z

TS-4763: Rename body_len log acces methods.

Standardize on content_len terminology for logging, so rename
"body_len" log access methods to "content_len".

commit 52d9a6abdf9ceea3a6a39a746c642c48957c57e8
Author: James Peach 
Date:   2016-08-18T20:37:38Z

TS-4763: Rename cqbl and pqbl log fields to cqcl and pqcl.

commit 94f4cb9d1962394db1f9a0e816ae5574159f70ff
Author: James Peach 
Date:   2016-08-18T21:12:37Z

TS-4763: Add the ssql, cqql, pqql, and cssql log fields.




Issue Time Tracking
---

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

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[GitHub] trafficserver issue #880: TS-4763: Consistent request bytes logging tags.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/880
  
/cc @zwoop @bryancall @sudheerv 


---
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-4763) Consistent request bytes logging tags.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/880
  
/cc @zwoop @bryancall @sudheerv 


Issue Time Tracking
---

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

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[GitHub] trafficserver pull request #880: TS-4763: Consistent request bytes logging t...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4763: Consistent request bytes logging tags.

Make the byte count logging tags consistent. We have

- ``cqbl`` - client request body length
- ``cqhl`` - client request header length
- ``pscl`` - client response body length
- ``pshl`` - client response header length
- ``psql`` - client response total length
- ``pqbl`` - server request body length
- ``pqhl`` - server request header length
- ``sscl`` - server response body length
- ``sshl`` - server response header length

We should add ``*ql`` to get the missing totals and standardize on ``*cl`` 
for the content length (``csscl`` marginally tips the balance towards "content 
length" in favor of "body length").

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

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

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

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


commit 7e12104cecd01a1f93d3bfb35d60b41ba705f2a3
Author: James Peach 
Date:   2016-08-18T18:42:15Z

TS-4764: Return the aligned field size from marshal_client_req_uuid().

commit d81b884237806ff93236fe8bf11b8e4e66233aa6
Author: James Peach 
Date:   2016-08-18T20:29:25Z

TS-4763: Rename body_len log acces methods.

Standardize on content_len terminology for logging, so rename
"body_len" log access methods to "content_len".

commit 52d9a6abdf9ceea3a6a39a746c642c48957c57e8
Author: James Peach 
Date:   2016-08-18T20:37:38Z

TS-4763: Rename cqbl and pqbl log fields to cqcl and pqcl.

commit 94f4cb9d1962394db1f9a0e816ae5574159f70ff
Author: James Peach 
Date:   2016-08-18T21:12:37Z

TS-4763: Add the ssql, cqql, pqql, and cssql log fields.




---
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-4765) Remove cqbl and pqbl log tags

[James Peach (JIRA)]

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

James Peach updated TS-4765:

Fix Version/s: 8.0.0

> Remove cqbl and pqbl log tags
> -
>
> Key: TS-4765
> URL: https://issues.apache.org/jira/browse/TS-4765
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: James Peach
> Fix For: 8.0.0
>
>
> In TS-4763 we standardized on "content length" as the common terminology. 
> Remove the {{cqbl}} and {{pqbl}} log tag aliases.



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

[jira] [Created] (TS-4765) Remove cqbl and pqbl log tags

[James Peach (JIRA)]

James Peach created TS-4765:
---

 Summary: Remove cqbl and pqbl log tags
 Key: TS-4765
 URL: https://issues.apache.org/jira/browse/TS-4765
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: James Peach


In TS-4763 we standardized on "content length" as the common terminology. 
Remove the {{cqbl}} and {{pqbl}} log tag aliases.



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

[jira] [Assigned] (TS-4763) Consistent request bytes logging tags.

[James Peach (JIRA)]

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

James Peach reassigned TS-4763:
---

Assignee: James Peach

> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[jira] [Updated] (TS-4763) Consistent request bytes logging tags.

[James Peach (JIRA)]

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

James Peach updated TS-4763:

Description: 
Make the byte count logging tags consistent. We have

{{cqbl}} - client request body length
{{cqhl}} - client request header length
{{pscl}} - client response body length
{{pshl}} - client response header length
{{psql}} - client response total length
{{pqbl}} - server request body length
{{pqhl}} - server request header length
{{sscl}} - server response body length
{{sshl}} - server response header length

We should add {{*ql}} to get the missing totals and standardize on {{*cl}} for 
the content length ({{csscl}} marginally tips the balance towards "content 
length" in favor of "body length").

  was:
Make the byte count logging tags consistent. We have

{{cqbl}} - client request body length
{{cqhl}} - client request header length
{{pscl}} - client response body length
{{pshl}} - client response header length
{{psql}} - client response total length
{{pqbl}} - server request body length
{{pqhl}} - server request header length
{{sscl}} - server response body length
{{sshl}} - server response header length

We should add {{*ql}} to get the missing totals and standardize on {{*bl}} for 
the body length.


> Consistent request bytes logging tags.
> --
>
> Key: TS-4763
> URL: https://issues.apache.org/jira/browse/TS-4763
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>
> Make the byte count logging tags consistent. We have
> {{cqbl}} - client request body length
> {{cqhl}} - client request header length
> {{pscl}} - client response body length
> {{pshl}} - client response header length
> {{psql}} - client response total length
> {{pqbl}} - server request body length
> {{pqhl}} - server request header length
> {{sscl}} - server response body length
> {{sshl}} - server response header length
> We should add {{*ql}} to get the missing totals and standardize on {{*cl}} 
> for the content length ({{csscl}} marginally tips the balance towards 
> "content length" in favor of "body length").



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

[GitHub] trafficserver issue #873: fix 5 bugs about parent strategy

[jrushford]

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/873
  
@keith2008 Can you break these commits up into individual PR's for each 
issue?


---
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-4764) cruuid log field is misaligned

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

[GitHub] trafficserver issue #878: TS-4764: Return the aligned field size from marsha...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/878
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/449/ 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-2153) traffic_manager -tsArgs without -M is fatal error

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-2153 : Add -M to traffic_manager options if needed



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

$ git pull https://github.com/strotyl/trafficserver TS-2153

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

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


commit 5ed7e151743dcc78c301c95a07e08d7fce2d
Author: Tyler Stroh 
Date:   2016-08-18T17:29:48Z

TS-2153 : Add -M to traffic_manager options if needed




Issue Time Tracking
---

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

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[GitHub] trafficserver pull request #879: TS-2153 : Add -M to traffic_manager options...

[strotyl]

GitHub user strotyl opened a pull request:

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

TS-2153 : Add -M to traffic_manager options if needed



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

$ git pull https://github.com/strotyl/trafficserver TS-2153

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

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


commit 5ed7e151743dcc78c301c95a07e08d7fce2d
Author: Tyler Stroh 
Date:   2016-08-18T17:29:48Z

TS-2153 : Add -M to traffic_manager options if needed




---
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-4764) cruuid log field is misaligned

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

[GitHub] trafficserver issue #878: TS-4764: Return the aligned field size from marsha...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/878
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/553/ 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-4764) cruuid log field is misaligned

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

[GitHub] trafficserver issue #878: TS-4764: Return the aligned field size from marsha...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/878
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/448/ 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-4764) cruuid log field is misaligned

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

[GitHub] trafficserver issue #878: TS-4764: Return the aligned field size from marsha...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/878
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/552/ 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-4764) cruuid log field is misaligned

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4764: Return the aligned field size from marshal_client_req_uuid().



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

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

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

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


commit cd844e0370d21e0a7280bc2c4fd03e4ee7f27152
Author: James Peach 
Date:   2016-08-18T18:42:15Z

TS-4764: Return the aligned field size from marshal_client_req_uuid().




Issue Time Tracking
---

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

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

[jira] [Work logged] (TS-4764) cruuid log field is misaligned

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/878
  
/cc @zwoop @bryancall 


Issue Time Tracking
---

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

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

[GitHub] trafficserver pull request #878: TS-4764: Return the aligned field size from...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4764: Return the aligned field size from marshal_client_req_uuid().



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

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

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

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


commit cd844e0370d21e0a7280bc2c4fd03e4ee7f27152
Author: James Peach 
Date:   2016-08-18T18:42:15Z

TS-4764: Return the aligned field size from marshal_client_req_uuid().




---
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 #878: TS-4764: Return the aligned field size from marsha...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/878
  
/cc @zwoop @bryancall 


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

[jira] [Assigned] (TS-4764) cruuid log field is misaligned

[James Peach (JIRA)]

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

James Peach reassigned TS-4764:
---

Assignee: James Peach

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

[jira] [Created] (TS-4764) cruuid log field is misaligned

[James Peach (JIRA)]

James Peach created TS-4764:
---

 Summary: cruuid log field is misaligned
 Key: TS-4764
 URL: https://issues.apache.org/jira/browse/TS-4764
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: James Peach


Triggering an assertion when I use the {{cruuid}} log field:
{noformat}
Thread 13542, [ET_NET 1]:
00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
10x2b0664cc0330 __restore_rt + (nil)
20x2b0665928c37 gsignal + 0x37
30x2b066592c028 abort + 0x148
40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned long, 
char*, unsigned long, unsigned long*) + (nil)
60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
90x006c0e6e Log::access(LogAccess*) + 0x29c
10   0x00641df3 HttpSM::kill_this() + 0x571
11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
#6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
790 ink_assert(bytes % INK_MIN_ALIGN == 0);
(gdb) l
785   char *ptr;
786   int bytes = 0;
787   for (LogField *f = first(); f; f = next(f)) {
788 ptr = [bytes];
789 bytes += f->marshal(lad, ptr);
790 ink_assert(bytes % INK_MIN_ALIGN == 0);
791   }
792   return bytes;
793 }
794
(gdb) p *f
$1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, m_marshal_func 
=  table offset 224,
  m_unmarshal_func = 0x6c5254 , m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
m_agg_cnt = 0, m_agg_val = 0,
  m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
m_set_func = NULL, link = { = {next = 0x1257dc0},
prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
2147483647}}
(gdb) p bytes
$2 = 198
(gdb) p bytes % 8
$3 = 6
{noformat}





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

[jira] [Updated] (TS-4764) cruuid log field is misaligned

[James Peach (JIRA)]

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

James Peach updated TS-4764:

Fix Version/s: 7.0.0

> cruuid log field is misaligned
> --
>
> Key: TS-4764
> URL: https://issues.apache.org/jira/browse/TS-4764
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> Triggering an assertion when I use the {{cruuid}} log field:
> {noformat}
> Thread 13542, [ET_NET 1]:
> 00x0051201d crash_logger_invoke(int, siginfo_t*, void*) + 0x98
> 10x2b0664cc0330 __restore_rt + (nil)
> 20x2b0665928c37 gsignal + 0x37
> 30x2b066592c028 abort + 0x148
> 40x2b0663a1ec54 ink_warning(char const*, ...) + (nil)
> 50x2b0663a1c5ea ats_base64_encode(unsigned char const*, unsigned 
> long, char*, unsigned long, unsigned long*) + (nil)
> 60x006d52ea LogFieldList::marshal(LogAccess*, char*) + 0x84
> 70x006e59ce LogObject::log(LogAccess*, char const*) + 0x6a4
> 80x006e80b1 LogObjectManager::log(LogAccess*) + 0x7b
> 90x006c0e6e Log::access(LogAccess*) + 0x29c
> 10   0x00641df3 HttpSM::kill_this() + 0x571
> 11   0x00631fb2 HttpSM::main_handler(int, void*) + 0x364
> #6  0x006d52ea in LogFieldList::marshal (this=0x1255170, 
> lad=0x72ee3980, buf=0x12589e8 "") at LogField.cc:790
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> (gdb) l
> 785 char *ptr;
> 786 int bytes = 0;
> 787 for (LogField *f = first(); f; f = next(f)) {
> 788   ptr = [bytes];
> 789   bytes += f->marshal(lad, ptr);
> 790   ink_assert(bytes % INK_MIN_ALIGN == 0);
> 791 }
> 792 return bytes;
> 793   }
> 794
> (gdb) p *f
> $1 = {m_name = 0x1257d80 "client_req_uuid", m_symbol = 0x1257da0 "cruuid", 
> m_type = LogField::STRING, m_container = LogField::NO_CONTAINER, 
> m_marshal_func =  table offset 224,
>   m_unmarshal_func = 0x6c5254  LogSlice*)>, m_unmarshal_func_map = 0x0, m_agg_op = LogField::NO_AGGREGATE, 
> m_agg_cnt = 0, m_agg_val = 0,
>   m_milestone1 = TS_MILESTONE_LAST_ENTRY, m_milestone2 = 
> TS_MILESTONE_LAST_ENTRY, m_time_field = false, m_alias_map = {m_ptr = 0x0}, 
> m_set_func = NULL, link = { = {next = 0x1257dc0},
> prev = 0x1257c00}, m_slice = {m_enable = false, m_start = 0, m_end = 
> 2147483647}}
> (gdb) p bytes
> $2 = 198
> (gdb) p bytes % 8
> $3 = 6
> {noformat}



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877
  
Should this use a TextLog rather than standard output? Then you would get 
log rotation, etc, which is probably desirable.


Issue Time Tracking
---

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

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



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

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

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
Should this use a TextLog rather than standard output? Then you would get 
log rotation, etc, which is probably desirable.


---
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 #877: TS-4755: Header Frequency plugin. Initial version

[petarpenkov]

Github user petarpenkov commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
Aw yeah, totally meant to do that and forgot. Will update ASAP.


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877
  
Aw yeah, totally meant to do that and forgot. Will update ASAP.


Issue Time Tracking
---

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

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



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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/877
  
Looks good, but I didn't see any locking when updating client_freq and 
origin_freq.


Issue Time Tracking
---

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

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



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

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

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/877
  
Looks good, but I didn't see any locking when updating client_freq and 
origin_freq.


---
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 #877: TS-4755: Header Frequency plugin. Initial v...

[petarpenkov]

GitHub user petarpenkov opened a pull request:

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

TS-4755: Header Frequency plugin. Initial version

Very basic version of the plugin. Additional options can be added to 
traffic_ctl to reset the counters, to print specific headers, maybe regex 
support. Additionally, the simple counters can be converted to decimal 
fractions.

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

$ git pull https://github.com/petarpenkov/trafficserver header_freq

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

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






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

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

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 18/Aug/16 18:02
Start Date: 18/Aug/16 18:02
Worklog Time Spent: 10m 
  Work Description: GitHub user petarpenkov opened a pull request:

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

TS-4755: Header Frequency plugin. Initial version

Very basic version of the plugin. Additional options can be added to 
traffic_ctl to reset the counters, to print specific headers, maybe regex 
support. Additionally, the simple counters can be converted to decimal 
fractions.

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

$ git pull https://github.com/petarpenkov/trafficserver header_freq

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

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






Issue Time Tracking
---

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

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



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

[jira] [Commented] (TS-3577) ATS with --enable-static-proxy does not compile

[James Peach (JIRA)]

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

James Peach commented on TS-3577:
-

[~zxcvbn4038] if you want to work on this I can help review. Otherwise I'm 
planning to remove the option.

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:760: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:762: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> ../lib/records/librecords_p.a(P_RecCore.o):/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:752:
>  more undefined 

[jira] [Commented] (TS-3577) ATS with --enable-static-proxy does not compile

[James Peach (JIRA)]

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

James Peach commented on TS-3577:
-

AFAIK no-one has ever used this. Lets nuke it.

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:760: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:762: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> ../lib/records/librecords_p.a(P_RecCore.o):/var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:752:
>  more undefined references to `textBuffer::copyFrom(void const*, unsigned 
> 

[GitHub] trafficserver pull request #876: Unit Test of web_transform plugin

[caricaturecm]

GitHub user caricaturecm opened a pull request:

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

Unit Test of web_transform plugin



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

$ git pull https://github.com/caricaturecm/trafficserver gtest-toSandeep

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

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






---
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 #876: Unit Test of web_transform plugin

[caricaturecm]

Github user caricaturecm closed the pull request at:

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


---
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-4722) CID 1361277: Uninitialized members in LogConfig::LogConfig

[James Peach (JIRA)]

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

James Peach resolved TS-4722.
-
Resolution: Fixed

Fixed on TS-4711

> CID 1361277:  Uninitialized members in LogConfig::LogConfig
> ---
>
> Key: TS-4722
> URL: https://issues.apache.org/jira/browse/TS-4722
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> {code}
> *** CID 1361277:  Uninitialized members  (UNINIT_CTOR)
> /proxy/logging/LogConfig.cc: 290 in LogConfig::LogConfig()()
> 284 {
> 285   // Setup the default values for all LogConfig public variables so 
> that
> 286   // a LogConfig object is valid upon return from the constructor even
> 287   // if no configuration file is read
> 288   //
> 289   setup_default_values();
>CID 1361277:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "custom_logs_enabled" is not initialized in this 
> constructor nor in any functions that it calls.
> 290 }
> 291 
> 292 
> /*-
> 293   LogConfig::~LogConfig
> 294 
> 295   Delete all config variable strings.
> {code}



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

Build failed in Jenkins: clang-analyzer #2546

[jenkins]

See 

Changes:

[James Peach] doc: Fix % formatting.

[Bryan Call] Fixed spelling in comments

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