[jira] [Commented] (TS-4778) CID 1361874: Null pointer dereferences (REVERSE_INULL) /mgmt/api/CfgContextManager.cc:

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4778:
---

This is from Coverity? Do we know where it's being dereferenced? 

> CID 1361874:  Null pointer dereferences  (REVERSE_INULL) 
> /mgmt/api/CfgContextManager.cc:
> 
>
> Key: TS-4778
> URL: https://issues.apache.org/jira/browse/TS-4778
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> Not sure why this showed up now, but it did...
> {code}
> *** CID 1361874:  Null pointer dereferences  (REVERSE_INULL)
> /mgmt/api/CfgContextManager.cc: 201 in CfgContextGet(CfgContext *)()
> 195   ats_free(old_text); // need to free memory
> 196   return ret;
> 197 }
> 198   }
> 199   delete (rule_list); // free RuleList memory
> 200   // TODO: Hmmm, this looks almost like a memory leak, why the strcmp 
> ??
>CID 1361874:  Null pointer dereferences  (REVERSE_INULL)
>Null-checking "old_text" suggests that it may be null, but it has already 
> been dereferenced on all paths leading to the check.
> 201   if (old_text && strcmp(old_text, "") != 0) {
> 202 ats_free(old_text); // need to free memory
> 203   }
> 204   return TS_ERR_OKAY;
> 205 }
> 206 
> {code}



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

[jira] [Comment Edited] (TS-4530) Enable proxy.config.hostdb.host_file.path by default

[Eric Schwartz (JIRA)]

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

Eric Schwartz edited comment on TS-4530 at 8/25/16 10:07 PM:
-

This is a string config variable. What should we make the default? I know the 
Yahoo default but don't know what's best for the general case. Maybe something 
depending on layout?


was (Author: es):
This is a string config variable. What should we make the default? I know the 
Yahoo default but don't know what's best for the general case.

> Enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



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

[jira] [Commented] (TS-4530) Enable proxy.config.hostdb.host_file.path by default

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4530:
---

This is a string config variable. What should we make the default? I know the 
Yahoo default but don't know what's best for the general case.

> Enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



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

[jira] [Commented] (TS-4423) Don't show function / filename / line numbers on "operational logs"

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4423:
---

PR here: https://github.com/apache/trafficserver/pull/928

> Don't show function / filename / line numbers on "operational logs"
> ---
>
> Key: TS-4423
> URL: https://issues.apache.org/jira/browse/TS-4423
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> As of v6.0.0, we've enabled the configuration
> {code}
> CONFIG proxy.config.diags.show_location INT 1
> {code}
> This means we now show file names / numbers on all logging, including 
> Notes(), Warning()'s etc. A suggestion is that for 7.0.0, we restore some of 
> the old functionality, such that we only show location on Debug() when this 
> is enabled. As an additional option feature, we could add an additional enum 
> value to this (2), which would then mean show location for all logging.



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

[jira] [Comment Edited] (TS-4423) Don't show function / filename / line numbers on "operational logs"

[Eric Schwartz (JIRA)]

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

Eric Schwartz edited comment on TS-4423 at 8/24/16 8:28 PM:


So to make sure I've got this before I change the code:

Current:
0 - don't show any line numbers
1 (DEFAULT) - show for all messages

Proposed:

0 - don't show any line numbers
1 (DEFAULT) - show for Debug() messages only
2 - show for all messages


was (Author: es):
So to make sure I've got this before I change the code:

0 - don't show any line numbers
1 (DEFAULT) - show for Debug() messages only
2 - show for all messages

> Don't show function / filename / line numbers on "operational logs"
> ---
>
> Key: TS-4423
> URL: https://issues.apache.org/jira/browse/TS-4423
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> As of v6.0.0, we've enabled the configuration
> {code}
> CONFIG proxy.config.diags.show_location INT 1
> {code}
> This means we now show file names / numbers on all logging, including 
> Notes(), Warning()'s etc. A suggestion is that for 7.0.0, we restore some of 
> the old functionality, such that we only show location on Debug() when this 
> is enabled. As an additional option feature, we could add an additional enum 
> value to this (2), which would then mean show location for all logging.



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

[jira] [Comment Edited] (TS-4423) Don't show function / filename / line numbers on "operational logs"

[Eric Schwartz (JIRA)]

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

Eric Schwartz edited comment on TS-4423 at 8/24/16 8:27 PM:


So to make sure I've got this before I change the code:

0 - don't show any line numbers
1 (DEFAULT) - show for Debug() messages only
2 - show for all messages


was (Author: es):
So to make sure I've got this before I write the code:

0 - don't show any line numbers
1 (DEFAULT) - show for Debug() messages only
2 - show for all messages

> Don't show function / filename / line numbers on "operational logs"
> ---
>
> Key: TS-4423
> URL: https://issues.apache.org/jira/browse/TS-4423
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> As of v6.0.0, we've enabled the configuration
> {code}
> CONFIG proxy.config.diags.show_location INT 1
> {code}
> This means we now show file names / numbers on all logging, including 
> Notes(), Warning()'s etc. A suggestion is that for 7.0.0, we restore some of 
> the old functionality, such that we only show location on Debug() when this 
> is enabled. As an additional option feature, we could add an additional enum 
> value to this (2), which would then mean show location for all logging.



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

[jira] [Commented] (TS-4423) Don't show function / filename / line numbers on "operational logs"

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4423:
---

So to make sure I've got this before I write the code:

0 - don't show any line numbers
1 (DEFAULT) - show for Debug() messages only
2 - show for all messages

> Don't show function / filename / line numbers on "operational logs"
> ---
>
> Key: TS-4423
> URL: https://issues.apache.org/jira/browse/TS-4423
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> As of v6.0.0, we've enabled the configuration
> {code}
> CONFIG proxy.config.diags.show_location INT 1
> {code}
> This means we now show file names / numbers on all logging, including 
> Notes(), Warning()'s etc. A suggestion is that for 7.0.0, we restore some of 
> the old functionality, such that we only show location on Debug() when this 
> is enabled. As an additional option feature, we could add an additional enum 
> value to this (2), which would then mean show location for all logging.



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

[jira] [Assigned] (TS-4778) CID 1361874: Null pointer dereferences (REVERSE_INULL) /mgmt/api/CfgContextManager.cc:

[Eric Schwartz (JIRA)]

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

Eric Schwartz reassigned TS-4778:
-

Assignee: Eric Schwartz

> CID 1361874:  Null pointer dereferences  (REVERSE_INULL) 
> /mgmt/api/CfgContextManager.cc:
> 
>
> Key: TS-4778
> URL: https://issues.apache.org/jira/browse/TS-4778
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> Not sure why this showed up now, but it did...
> {code}
> *** CID 1361874:  Null pointer dereferences  (REVERSE_INULL)
> /mgmt/api/CfgContextManager.cc: 201 in CfgContextGet(CfgContext *)()
> 195   ats_free(old_text); // need to free memory
> 196   return ret;
> 197 }
> 198   }
> 199   delete (rule_list); // free RuleList memory
> 200   // TODO: Hmmm, this looks almost like a memory leak, why the strcmp 
> ??
>CID 1361874:  Null pointer dereferences  (REVERSE_INULL)
>Null-checking "old_text" suggests that it may be null, but it has already 
> been dereferenced on all paths leading to the check.
> 201   if (old_text && strcmp(old_text, "") != 0) {
> 202 ats_free(old_text); // need to free memory
> 203   }
> 204   return TS_ERR_OKAY;
> 205 }
> 206 
> {code}



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

[jira] [Assigned] (TS-4457) Via header always reports http1

[Eric Schwartz (JIRA)]

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

Eric Schwartz reassigned TS-4457:
-

Assignee: Eric Schwartz

> Via header always reports http1
> ---
>
> Key: TS-4457
> URL: https://issues.apache.org/jira/browse/TS-4457
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> When using http2, the Via header says http1.1.
> $ curl -D- -o/dev/null -s "https://docs.trafficserver.apache.org/; | grep via
> via:http/1.1 ATS (ApacheTrafficServer/6.2.0 [cRs f ])



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

[jira] [Commented] (TS-4012) tcp_reused log field doesn't work for http2

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4012:
---

TS-3612 seems to have fixed this because HttpSM simply has access to the 
underlying netvc from the parent session.

> tcp_reused log field doesn't work for http2
> ---
>
> Key: TS-4012
> URL: https://issues.apache.org/jira/browse/TS-4012
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2, Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> This is something we noticed at Yahoo!
> Because it uses the HttpClientSession transact_count, the tcp_reused log 
> field will not properly work for http2 and spdy, where the HttpClientSession 
> isn't reused. 
> We need to essentially count the number of initiated streams instead.
> We've got a fix that does this for HTTP2. With SPDY eventually dying off, 
> does it make sense to also submit a change to fix this for SPDY? We have code 
> to do this as well, but it currently involves an H2 dependency that might be 
> undesirable.



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

[jira] [Commented] (TS-4012) tcp_reused log field doesn't work for http2

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4012:
---

[~bcall] running a test today on our internal traffic with TS-3612 to see if 
that fixed this. (It may have)

Will update this with results too.

> tcp_reused log field doesn't work for http2
> ---
>
> Key: TS-4012
> URL: https://issues.apache.org/jira/browse/TS-4012
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2, Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> This is something we noticed at Yahoo!
> Because it uses the HttpClientSession transact_count, the tcp_reused log 
> field will not properly work for http2 and spdy, where the HttpClientSession 
> isn't reused. 
> We need to essentially count the number of initiated streams instead.
> We've got a fix that does this for HTTP2. With SPDY eventually dying off, 
> does it make sense to also submit a change to fix this for SPDY? We have code 
> to do this as well, but it currently involves an H2 dependency that might be 
> undesirable.



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

[jira] [Created] (TS-4723) ATS CARP Plugin

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-4723:
-

 Summary: ATS CARP Plugin
 Key: TS-4723
 URL: https://issues.apache.org/jira/browse/TS-4723
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Eric Schwartz


Open sourcing this plugin we use internally within Yahoo in place of 
hierarchical caching.

CARP is a plugin that allows you to group a bunch of ATS hosts into a cluster 
and share cache space across the entire group. This is done with consistent 
hashing on the object URL to generate an "owner" node in the cluster. Requests 
to any other node in the cluster will be forwarded on to the corresponding 
owner. More info in the README.

Difference from internal version of note:

I've ripped out some code we weren't entirely sure we could open source because 
of a hash function. If it turns out that we can open source this, I'll do so. 
The CarpHashAlgorithm class is meant to be extensible, so any consistent hash 
function can replace it. The function included here is pretty straightforward 
but not what we use in production, so just wanted to use that caveat.

One last caveat:

You'll see some code and documentation in here for object replication. This is 
something I added recently to CARP that allows you to specify an object be 
replicated a certain number of times in the cluster. This is useful if you have 
a network partition or if you're performing some sort of update. When an 
object's primary owner is unreachable, a node in the cluster can go to the 
secondary owner if it's available rather than having to fall all the way back 
to origin. While I've done some initial testing on this with my own cluster of 
hosts, it's not been tested in production so use at your own risk for now. I'll 
be sure to keep the open source community informed on the progress of our tests 
with this feature.



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

[jira] [Assigned] (TS-4723) ATS CARP Plugin

[Eric Schwartz (JIRA)]

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

Eric Schwartz reassigned TS-4723:
-

Assignee: Eric Schwartz

> ATS CARP Plugin
> ---
>
> Key: TS-4723
> URL: https://issues.apache.org/jira/browse/TS-4723
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
>
> Open sourcing this plugin we use internally within Yahoo in place of 
> hierarchical caching.
> CARP is a plugin that allows you to group a bunch of ATS hosts into a cluster 
> and share cache space across the entire group. This is done with consistent 
> hashing on the object URL to generate an "owner" node in the cluster. 
> Requests to any other node in the cluster will be forwarded on to the 
> corresponding owner. More info in the README.
> Difference from internal version of note:
> I've ripped out some code we weren't entirely sure we could open source 
> because of a hash function. If it turns out that we can open source this, 
> I'll do so. The CarpHashAlgorithm class is meant to be extensible, so any 
> consistent hash function can replace it. The function included here is pretty 
> straightforward but not what we use in production, so just wanted to use that 
> caveat.
> One last caveat:
> You'll see some code and documentation in here for object replication. This 
> is something I added recently to CARP that allows you to specify an object be 
> replicated a certain number of times in the cluster. This is useful if you 
> have a network partition or if you're performing some sort of update. When an 
> object's primary owner is unreachable, a node in the cluster can go to the 
> secondary owner if it's available rather than having to fall all the way back 
> to origin. While I've done some initial testing on this with my own cluster 
> of hosts, it's not been tested in production so use at your own risk for now. 
> I'll be sure to keep the open source community informed on the progress of 
> our tests with this feature.



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

[jira] [Commented] (TS-4012) tcp_reused log field doesn't work for http2/spdy

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4012:
---

Yes! I should be able to fix this now that TS-3612 is finalized. 

On Tuesday, July 19, 2016 4:12 PM, Leif Hedstrom (JIRA)  
wrote:
 

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

Leif Hedstrom commented on TS-4012:
---

[~erics273]Are we getting a new PR for this?  Or should we close this?




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




> tcp_reused log field doesn't work for http2/spdy
> 
>
> Key: TS-4012
> URL: https://issues.apache.org/jira/browse/TS-4012
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2, Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> This is something we noticed at Yahoo!
> Because it uses the HttpClientSession transact_count, the tcp_reused log 
> field will not properly work for http2 and spdy, where the HttpClientSession 
> isn't reused. 
> We need to essentially count the number of initiated streams instead.
> We've got a fix that does this for HTTP2. With SPDY eventually dying off, 
> does it make sense to also submit a change to fix this for SPDY? We have code 
> to do this as well, but it currently involves an H2 dependency that might be 
> undesirable.



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

[jira] [Created] (TS-4379) Log field for connections to origin

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-4379:
-

 Summary: Log field for connections to origin 
 Key: TS-4379
 URL: https://issues.apache.org/jira/browse/TS-4379
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Eric Schwartz


Simple log field for # of connections open to the origin server. Did this a 
while back for some work we were doing to track the maximum number of 
connections to a given origin across some traffic spikes. Thought someone else 
might find it useful.



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

[jira] [Commented] (TS-4070) RemapProcessor Forward Mapping with Recv Port failing with TS-2157 changes

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4070:
---

Ah good catch, sorry about the mixup. I had one comment on your PR but other 
than that looks like a good fix to me too.

> RemapProcessor Forward Mapping with Recv Port failing with TS-2157 changes
> --
>
> Key: TS-4070
> URL: https://issues.apache.org/jira/browse/TS-4070
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Craig Schomburg
>Assignee: Eric Schwartz
>Priority: Critical
>  Labels: regression
> Fix For: 6.1.0
>
> Attachments: TS-4070.patch
>
>
> During the rework of RemapProcessor.cc, RemapProcessor::setup_for_remap() as 
> part of the TS-2157 changeset, the port access API appears to have been 
> incorrectly modified to use the client_info.src_addr.host_order_port() API 
> [source port, host order] instead of the client_info.dst_addr.port() 
> [destination/receive port, network 
> order] API.  This caused port based remapping based on the receive port to 
> fail with ATS 6.0.0.
> Functionality was previously working with ATS 4.0.1.
> See attached patch that was used to restore the ATS 4.0.1 functionality.
> Looking for confirmation that this fix/patch was correct.



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

[jira] [Created] (TS-4031) Update docs to show new log fields

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-4031:
-

 Summary: Update docs to show new log fields
 Key: TS-4031
 URL: https://issues.apache.org/jira/browse/TS-4031
 Project: Traffic Server
  Issue Type: Bug
  Components: Documentation
Reporter: Eric Schwartz


Lost some log fields a few weeks ago in an update. Need to get them back. Feel 
free to assign this to me.



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

[jira] [Created] (TS-4024) wire tracing enhancements

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-4024:
-

 Summary: wire tracing enhancements
 Key: TS-4024
 URL: https://issues.apache.org/jira/browse/TS-4024
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Eric Schwartz


Some enhancements from Yahoo! to make wire tracing dynamically enable-able and 
to enhance log messages.



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

[jira] [Commented] (TS-4024) wire tracing enhancements

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4024:
---

Could someone assign this to me?

> wire tracing enhancements
> -
>
> Key: TS-4024
> URL: https://issues.apache.org/jira/browse/TS-4024
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Eric Schwartz
>
> Some enhancements from Yahoo! to make wire tracing dynamically enable-able 
> and to enhance log messages.



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

[jira] [Comment Edited] (TS-4024) wire tracing enhancements

[Eric Schwartz (JIRA)]

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

Eric Schwartz edited comment on TS-4024 at 11/13/15 11:06 PM:
--

Could someone assign this to me? Have a patch for discussion.


was (Author: es):
Could someone assign this to me?

> wire tracing enhancements
> -
>
> Key: TS-4024
> URL: https://issues.apache.org/jira/browse/TS-4024
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Eric Schwartz
>
> Some enhancements from Yahoo! to make wire tracing dynamically enable-able 
> and to enhance log messages.



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

[jira] [Commented] (TS-4012) tcp_reused log field doesn't work for http2/spdy

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4012:
---

Also, could someone assign this to me?

> tcp_reused log field doesn't work for http2/spdy
> 
>
> Key: TS-4012
> URL: https://issues.apache.org/jira/browse/TS-4012
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Eric Schwartz
>
> This is something we noticed at Yahoo!
> Because it uses the HttpClientSession transact_count, the tcp_reused log 
> field will not properly work for http2 and spdy, where the HttpClientSession 
> isn't reused. 
> We need to essentially count the number of initiated streams instead.
> We've got a fix that does this for HTTP2. With SPDY eventually dying off, 
> does it make sense to also submit a change to fix this for SPDY? We have code 
> to do this as well, but it currently involves an H2 dependency that might be 
> undesirable.



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

[jira] [Created] (TS-4012) tcp_reused log field doesn't work for http2/spdy

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-4012:
-

 Summary: tcp_reused log field doesn't work for http2/spdy
 Key: TS-4012
 URL: https://issues.apache.org/jira/browse/TS-4012
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Eric Schwartz


This is something we noticed at Yahoo!

Because it uses the HttpClientSession transact_count, the tcp_reused log field 
will not properly work for http2 and spdy, where the HttpClientSession isn't 
reused. 

We need to essentially count the number of initiated streams instead.

We've got a fix that does this for HTTP2. With SPDY eventually dying off, does 
it make sense to also submit a change to fix this for SPDY? We have code to do 
this as well, but it currently involves an H2 dependency that might be 
undesirable.



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

[jira] [Commented] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3900:
---

this can be closed out

> Create log tag for server connection reuse
> --
>
> Key: TS-3900
> URL: https://issues.apache.org/jira/browse/TS-3900
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
>Priority: Minor
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> There was a log tag % added a while back by [~fpesce] that logged 
> whether the connection between ATS and the client was reused. There's been 
> some interest at Yahoo! in a similar tag for whether the connection between 
> ATS and the origin server was reused.



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

[jira] [Commented] (TS-3648) Desire support for client TLS cipher in custom log format

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3648:
---

this can be closed out

> Desire support for client TLS cipher in custom log format
> -
>
> Key: TS-3648
> URL: https://issues.apache.org/jira/browse/TS-3648
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Sproul
>Assignee: Eric Schwartz
> Fix For: 6.1.0
>
>
> While the TLS cipher stats from TS-2169 are awesome for seeing what ciphers 
> are in active use, I would also like to be able to create a custom log to 
> track cipher by client request.  That would enable me, for example, to 
> determine who among my users might be affected by a cipher list change.



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

[jira] [Commented] (TS-3911) New log tag for proxy connection being over SSL, pqssl

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3911:
---

this can be closed out

> New log tag for proxy connection being over SSL, pqssl
> --
>
> Key: TS-3911
> URL: https://issues.apache.org/jira/browse/TS-3911
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 6.1.0
>
>
> Want to add a log tag identifying whether the connection between the proxy 
> and origin is over SSL.  We have a similar tag for the client connection.



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

[jira] [Created] (TS-3911) Create log tag for server connection isSSL

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-3911:
-

 Summary: Create log tag for server connection isSSL
 Key: TS-3911
 URL: https://issues.apache.org/jira/browse/TS-3911
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Eric Schwartz


Want to add a log tag identifying whether the connection between the proxy and 
origin is over SSL.  We have a similar tag for the client connection.



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

[jira] [Commented] (TS-3911) Create log tag for server connection isSSL

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3911:
---

1) Could someone assign this to me?
2) PR here: https://github.com/apache/trafficserver/pull/293

> Create log tag for server connection isSSL
> --
>
> Key: TS-3911
> URL: https://issues.apache.org/jira/browse/TS-3911
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>
> Want to add a log tag identifying whether the connection between the proxy 
> and origin is over SSL.  We have a similar tag for the client connection.



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

[jira] [Updated] (TS-3911) Create log tag for whether proxy to server connection is ssl

[Eric Schwartz (JIRA)]

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

Eric Schwartz updated TS-3911:
--
Summary: Create log tag for whether proxy to server connection is ssl  
(was: Create log tag for server connection isSSL)

> Create log tag for whether proxy to server connection is ssl
> 
>
> Key: TS-3911
> URL: https://issues.apache.org/jira/browse/TS-3911
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>
> Want to add a log tag identifying whether the connection between the proxy 
> and origin is over SSL.  We have a similar tag for the client connection.



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

[jira] [Updated] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

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

Eric Schwartz updated TS-3900:
--
Description: There was a log tag % added a while back by [~fpesce] 
that logged whether the connection between ATS and the client was reused. 
There's been some interest at Yahoo! in a similar tag for whether the 
connection between ATS and the origin server was reused.  (was: There was a log 
tag % added a while back by [~fpesce] that logged whether the connection 
between ATS and the client was reused. There's been some interest at Yahoo! in 
a similar tag for whether the connection between ATS and the origin server was 
reused.)

> Create log tag for server connection reuse
> --
>
> Key: TS-3900
> URL: https://issues.apache.org/jira/browse/TS-3900
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>  Labels: yahoo
>
> There was a log tag % added a while back by [~fpesce] that logged 
> whether the connection between ATS and the client was reused. There's been 
> some interest at Yahoo! in a similar tag for whether the connection between 
> ATS and the origin server was reused.



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

[jira] [Commented] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3900:
---

Don't seem to be able to assign this to myself but I can do this. My plan was 
to use the transact_count in the HttpServerSession and set the tag based on its 
count in HttpSM::attach_server_session.

There's been some discussion between myself, [~amc] and [~dcarlin] about 
whether the tag should be a boolean (not reused or reused) or simply a count. 
Might be nice to do a bool just because it would be consistent with % but 
wonder what everyone thinks.

> Create log tag for server connection reuse
> --
>
> Key: TS-3900
> URL: https://issues.apache.org/jira/browse/TS-3900
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>  Labels: yahoo
>
> There was a log tag % added a while back by [~fpesce] that logged 
> whether the connection between ATS and the client was reused. There's been 
> some interest at Yahoo! in a similar tag for whether the connection between 
> ATS and the origin server was reused.



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

[jira] [Updated] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

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

Eric Schwartz updated TS-3900:
--
Labels: yahoo  (was: )

> Create log tag for server connection reuse
> --
>
> Key: TS-3900
> URL: https://issues.apache.org/jira/browse/TS-3900
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>  Labels: yahoo
>
> There was a log tag % added a while back by [~fpesce] that logged 
> whether the connection between ATS and the client was reused. There's been 
> some interest at Yahoo! in a similar tag for whether the connection between 
> ATS and the origin server was reused.



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

[jira] [Created] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-3900:
-

 Summary: Create log tag for server connection reuse
 Key: TS-3900
 URL: https://issues.apache.org/jira/browse/TS-3900
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Eric Schwartz


There was a log tag % added a while back by [~fpesce] that logged whether 
the connection between ATS and the client was reused. There's been some 
interest at Yahoo! in a similar tag for whether the connection between ATS and 
the origin server was reused.



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

[jira] [Updated] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

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

Eric Schwartz updated TS-3900:
--
Priority: Minor  (was: Major)

> Create log tag for server connection reuse
> --
>
> Key: TS-3900
> URL: https://issues.apache.org/jira/browse/TS-3900
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>Priority: Minor
>  Labels: yahoo
>
> There was a log tag % added a while back by [~fpesce] that logged 
> whether the connection between ATS and the client was reused. There's been 
> some interest at Yahoo! in a similar tag for whether the connection between 
> ATS and the origin server was reused.



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

[jira] [Commented] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3900:
---

[~amc] I'll investigate whether the server session is available at the time of 
logging right now. I know the client session isn't typically.

And TS-3539 makes use of the transact_count counter in the client session, not 
the counter in the server session. That counter is used for % to log 
whether the client connection is reused. Was proposing to do the same thing for 
the origin side connection.

> Create log tag for server connection reuse
> --
>
> Key: TS-3900
> URL: https://issues.apache.org/jira/browse/TS-3900
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
>Priority: Minor
>  Labels: yahoo
>
> There was a log tag % added a while back by [~fpesce] that logged 
> whether the connection between ATS and the client was reused. There's been 
> some interest at Yahoo! in a similar tag for whether the connection between 
> ATS and the origin server was reused.



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

[jira] [Commented] (TS-3900) Create log tag for server connection reuse

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3900:
---

Looks like it's possible server_session is gone at log time so we'll need to 
add another field.

> Create log tag for server connection reuse
> --
>
> Key: TS-3900
> URL: https://issues.apache.org/jira/browse/TS-3900
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
>Priority: Minor
>  Labels: yahoo
>
> There was a log tag % added a while back by [~fpesce] that logged 
> whether the connection between ATS and the client was reused. There's been 
> some interest at Yahoo! in a similar tag for whether the connection between 
> ATS and the origin server was reused.



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

[jira] [Commented] (TS-3534) Wiretracing for SSL connections

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14711879#comment-14711879
 ] 

Eric Schwartz commented on TS-3534:
---

Just looked into this and looks like they aren't in there. Oversight on my 
part. Will add today.

 Wiretracing for SSL connections
 ---

 Key: TS-3534
 URL: https://issues.apache.org/jira/browse/TS-3534
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging, Tools
Reporter: Eric Schwartz
Assignee: Eric Schwartz
 Fix For: 6.0.0


 Opening a ticket for discussion of the wiretracing change I made on our 
 internal version of ATS.
 The change allows for tracing requests through ATS for: a small percentage of 
 traffic, traffic from a certain IP and/or traffic to a specific origin. These 
 settings can be combined.
 The main updates are to SSLNetVConnection and UnixNetVConnection (adding the 
 trace logic) and to the Logging APIs (to add the special trace logs). One 
 change is made to HttpSM to allow client and server traces to be associated 
 with one another.
 [~dcarlin] has some notes from the summit on the initial discussion.
 I'll add a pull request with actual code for people to look at shortly.



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

[jira] [Commented] (TS-3781) Ability to log the The proxy request server port

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635479#comment-14635479
 ] 

Eric Schwartz commented on TS-3781:
---

Looks like a duplicate of https://issues.apache.org/jira/browse/TS-2152

 Ability to log the The proxy request server port
 

 Key: TS-3781
 URL: https://issues.apache.org/jira/browse/TS-3781
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: Jonh Wendell
 Attachments: 0001-TS-3781-Add-the-log-field-pqsp-server-port.patch


 In addition to field pqsi, it would be good to have the server port 
 available to logging as well.



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

[jira] [Commented] (TS-3648) Desire support for client TLS cipher in custom log format

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603251#comment-14603251
 ] 

Eric Schwartz commented on TS-3648:
---

looking at [~acacio]'s PR it looks like there was one change requested. as this 
is now assigned to me I can make that edits to his PR and open a new PR if he's 
no longer working on this?

or do we want to go a different way with this? i agree with some of the 
commentary about not adding new fields to HttpSM every time we need to update 
log fields. there was some discussion of creating a separate logging substruct 
in HttpSM. i could also take that on if this and a couple of [~fpesce]'s PRs 
are reviewed and merged and we like that idea.

 Desire support for client TLS cipher in custom log format
 -

 Key: TS-3648
 URL: https://issues.apache.org/jira/browse/TS-3648
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Eric Sproul
Assignee: Eric Schwartz
 Fix For: 6.1.0


 While the TLS cipher stats from TS-2169 are awesome for seeing what ciphers 
 are in active use, I would also like to be able to create a custom log to 
 track cipher by client request.  That would enable me, for example, to 
 determine who among my users might be affected by a cipher list change.



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

[jira] [Commented] (TS-3476) Add a log tag for application protocol

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14571426#comment-14571426
 ] 

Eric Schwartz commented on TS-3476:
---

As far as I know, there isn't an existing path from the HttpSM back to the 
ProxyClientSession currently in the code. (If I'm wrong here, please let me 
know) 

Was looking into adding one by associating the HttpClientSession (ua_session) 
w/ its parent ProxyClientSession in FetchSM. However I could only access it 
toward the end of FetchSM's life cycle, in the final call to process_fetch_read.

The path I found was through the PluginVC's read_state.  Is there a way to 
access the underlying HttpClientSession earlier in FetchSM that anyone knows of?

 Add a log tag for application protocol
 --

 Key: TS-3476
 URL: https://issues.apache.org/jira/browse/TS-3476
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging, SSL
Reporter: Leif Hedstrom
Assignee: Eric Schwartz
 Fix For: 6.0.0


 It seems crucial to be able to log which protocol handler was negotiated with 
 ALPN (and perhaps NPN as long as we support it). This could simple be the 
 string that was negotiated by the client/server in the TLS handshake. For 
 example, with HTTP/2, it would be h2 (or h2-14 with some browsers).
 A suggested log tag name would be %alpn which seems clear enough to me and 
 easy to remember :).



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

[jira] [Commented] (TS-3476) Add a log tag for APLN/NPN negotiated protocol

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570004#comment-14570004
 ] 

Eric Schwartz commented on TS-3476:
---

Looking at the SSLNetVConnection it looks like we can get the ALPN/NPN 
negotiated protocol from the connection there pretty easily (right now it's 
stored temporarily and logged to traffic.out. I don't see a reason we couldn't 
just make this a field in the SSLNetVC class and then grab that from the NetVC 
in HttpSM for logging.  This works out nicely because even though for h2 and 
SPDY, the HttpSM doesn't have a flag with the protocol version, the SSLNetVC 
does.

That gets us the SSL case. We wouldn't be able to log the protocol from a 
UnixNetVC in this way though. Is that a problem/something we can come up with 
another solution for?

Alternatively, for both SSL and non-SSL cases, we can get the negotiated 
protocol on the client from the uppermost ClientSession. This involves 
introducing some sort of pointer from the underlying HttpClientSession in our 
SPDY implementation back to its parent session. I've been playing around with 
doing this for a while though and it gets very hairy, because it's difficult to 
get a pointer back to the SpdyClientSession from the HttpClientSession in any 
sort of fashion in time for the HttpSM to grab the protocol from its ua_session 
in time for logging.

In addition to these two approaches, does anyone have any alternative ideas how 
we might do this?

 Add a log tag for APLN/NPN negotiated protocol
 --

 Key: TS-3476
 URL: https://issues.apache.org/jira/browse/TS-3476
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging, SSL
Reporter: Leif Hedstrom
Assignee: Eric Schwartz
 Fix For: 6.0.0


 It seems crucial to be able to log which protocol handler was negotiated with 
 ALPN (and perhaps NPN as long as we support it). This could simple be the 
 string that was negotiated by the client/server in the TLS handshake. For 
 example, with HTTP/2, it would be h2 (or h2-14 with some browsers).
 A suggested log tag name would be %alpn which seems clear enough to me and 
 easy to remember :).



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

[jira] [Comment Edited] (TS-3476) Add a log tag for APLN/NPN negotiated protocol

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570004#comment-14570004
 ] 

Eric Schwartz edited comment on TS-3476 at 6/2/15 11:49 PM:


Looking at the SSLNetVConnection it looks like we can get the ALPN/NPN 
negotiated protocol from the connection there pretty easily (right now it's 
stored temporarily and logged to traffic.out). I don't see a reason we couldn't 
just make this a field in the SSLNetVC class and then grab that from the NetVC 
in HttpSM for logging.  This works out nicely because even though for h2 and 
SPDY, the HttpSM doesn't have a flag with the protocol version, the SSLNetVC 
does.

That gets us the SSL case. We wouldn't be able to log the protocol from a 
UnixNetVC in this way though. Is that a problem/something we can come up with 
another solution for?

Alternatively, for both SSL and non-SSL cases, we can get the negotiated 
protocol on the client from the uppermost ClientSession. This involves 
introducing some sort of pointer from the underlying HttpClientSession in our 
SPDY implementation back to its parent session. I've been playing around with 
doing this for a while though and it gets very hairy, because it's difficult to 
get a pointer back to the SpdyClientSession from the HttpClientSession in any 
sort of fashion in time for the HttpSM to grab the protocol from its ua_session 
in time for logging.

In addition to these two approaches, does anyone have any alternative ideas how 
we might do this?


was (Author: es):
Looking at the SSLNetVConnection it looks like we can get the ALPN/NPN 
negotiated protocol from the connection there pretty easily (right now it's 
stored temporarily and logged to traffic.out. I don't see a reason we couldn't 
just make this a field in the SSLNetVC class and then grab that from the NetVC 
in HttpSM for logging.  This works out nicely because even though for h2 and 
SPDY, the HttpSM doesn't have a flag with the protocol version, the SSLNetVC 
does.

That gets us the SSL case. We wouldn't be able to log the protocol from a 
UnixNetVC in this way though. Is that a problem/something we can come up with 
another solution for?

Alternatively, for both SSL and non-SSL cases, we can get the negotiated 
protocol on the client from the uppermost ClientSession. This involves 
introducing some sort of pointer from the underlying HttpClientSession in our 
SPDY implementation back to its parent session. I've been playing around with 
doing this for a while though and it gets very hairy, because it's difficult to 
get a pointer back to the SpdyClientSession from the HttpClientSession in any 
sort of fashion in time for the HttpSM to grab the protocol from its ua_session 
in time for logging.

In addition to these two approaches, does anyone have any alternative ideas how 
we might do this?

 Add a log tag for APLN/NPN negotiated protocol
 --

 Key: TS-3476
 URL: https://issues.apache.org/jira/browse/TS-3476
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging, SSL
Reporter: Leif Hedstrom
Assignee: Eric Schwartz
 Fix For: 6.0.0


 It seems crucial to be able to log which protocol handler was negotiated with 
 ALPN (and perhaps NPN as long as we support it). This could simple be the 
 string that was negotiated by the client/server in the TLS handshake. For 
 example, with HTTP/2, it would be h2 (or h2-14 with some browsers).
 A suggested log tag name would be %alpn which seems clear enough to me and 
 easy to remember :).



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

[jira] [Commented] (TS-3589) Enhance header_rewrite to support TRANSACT_COUNT as a condition

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559180#comment-14559180
 ] 

Eric Schwartz commented on TS-3589:
---

Does anyone have time to give this a look?

 Enhance header_rewrite to support TRANSACT_COUNT as a condition
 ---

 Key: TS-3589
 URL: https://issues.apache.org/jira/browse/TS-3589
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Eric Schwartz
Assignee: Eric Schwartz
 Fix For: 6.0.0


 Adding support to header_rewrite to support TRANSACT_COUNT as a condition.
 Will allow us to add/modify headers on connections that share a Client 
 Session.



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

[jira] [Commented] (TS-3534) Wiretracing for SSL connections

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559188#comment-14559188
 ] 

Eric Schwartz commented on TS-3534:
---

Does anyone have time to give this a look?

 Wiretracing for SSL connections
 ---

 Key: TS-3534
 URL: https://issues.apache.org/jira/browse/TS-3534
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging, Tools
Reporter: Eric Schwartz
Assignee: Eric Schwartz
 Fix For: sometime


 Opening a ticket for discussion of the wiretracing change I made on our 
 internal version of ATS.
 The change allows for tracing requests through ATS for: a small percentage of 
 traffic, traffic from a certain IP and/or traffic to a specific origin. These 
 settings can be combined.
 The main updates are to SSLNetVConnection and UnixNetVConnection (adding the 
 trace logic) and to the Logging APIs (to add the special trace logs). One 
 change is made to HttpSM to allow client and server traces to be associated 
 with one another.
 [~dcarlin] has some notes from the summit on the initial discussion.
 I'll add a pull request with actual code for people to look at shortly.



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

[jira] [Commented] (TS-3589) Enhance header_rewrite to support TRANSACT_COUNT as a condition

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14538722#comment-14538722
 ] 

Eric Schwartz commented on TS-3589:
---

going with TRANSACT-COUNT not TRANSACT_COUNT for consistency*

 Enhance header_rewrite to support TRANSACT_COUNT as a condition
 ---

 Key: TS-3589
 URL: https://issues.apache.org/jira/browse/TS-3589
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Eric Schwartz
Assignee: Eric Schwartz
 Fix For: 6.0.0


 Adding support to header_rewrite to support TRANSACT_COUNT as a condition.
 Will allow us to add/modify headers on connections that share a Client 
 Session.



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

[jira] [Created] (TS-3589) Enhance header_rewrite to support TRANSACT_COUNT as a condition

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-3589:
-

 Summary: Enhance header_rewrite to support TRANSACT_COUNT as a 
condition
 Key: TS-3589
 URL: https://issues.apache.org/jira/browse/TS-3589
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Eric Schwartz


Adding support to header_rewrite to support TRANSACT_COUNT as a condition.

Will allow us to add/modify headers on connections that share a Client Session.



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

[jira] [Commented] (TS-3534) Wiretracing for SSL connections

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14517618#comment-14517618
 ] 

Eric Schwartz commented on TS-3534:
---

Opened a PR here for people to review/comment on:

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

 Wiretracing for SSL connections
 ---

 Key: TS-3534
 URL: https://issues.apache.org/jira/browse/TS-3534
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging, Tools
Reporter: Eric Schwartz
Assignee: Eric Schwartz
 Fix For: sometime


 Opening a ticket for discussion of the wiretracing change I made on our 
 internal version of ATS.
 The change allows for tracing requests through ATS for: a small percentage of 
 traffic, traffic from a certain IP and/or traffic to a specific origin. These 
 settings can be combined.
 The main updates are to SSLNetVConnection and UnixNetVConnection (adding the 
 trace logic) and to the Logging APIs (to add the special trace logs). One 
 change is made to HttpSM to allow client and server traces to be associated 
 with one another.
 [~dcarlin] has some notes from the summit on the initial discussion.
 I'll add a pull request with actual code for people to look at shortly.



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

[jira] [Created] (TS-3534) Wiretracing for SSL connections

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-3534:
-

 Summary: Wiretracing for SSL connections
 Key: TS-3534
 URL: https://issues.apache.org/jira/browse/TS-3534
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging, Tools
Reporter: Eric Schwartz


Opening a ticket for discussion of the wiretracing change I made on our 
internal version of ATS.

The change allows for tracing requests through ATS for: a small percentage of 
traffic, traffic from a certain IP and/or traffic to a specific origin. These 
settings can be combined.

The main updates are to SSLNetVConnection and UnixNetVConnection (adding the 
trace logic) and to the Logging APIs (to add the special trace logs). One 
change is made to HttpSM to allow client and server traces to be associated 
with one another.

[~dcarlin] has some notes from the summit on the initial discussion.

I'll add a pull request with actual code for people to look at shortly.



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

[jira] [Commented] (TS-3396) new_tsqa SPDY protocol selection tests

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350990#comment-14350990
 ] 

Eric Schwartz commented on TS-3396:
---

hey [~jacksontj] how do these changes look to you?

 new_tsqa SPDY protocol selection tests
 --

 Key: TS-3396
 URL: https://issues.apache.org/jira/browse/TS-3396
 Project: Traffic Server
  Issue Type: Test
  Components: SPDY, tsqa
Reporter: Eric Schwartz
Assignee: Thomas Jackson
Priority: Minor
 Fix For: sometime


 Opening this JIRA to submit some SPDY protocol selection tests using spdycat 
 I wrote using the new_tsqa.



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

[jira] [Commented] (TS-3396) new_tsqa SPDY protocol selection tests

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14333631#comment-14333631
 ] 

Eric Schwartz commented on TS-3396:
---

Sorry for the confusion w/ 2 PRs here. The first one contained a cert that was 
unnecessary. I've rewritten the test to simply use one of [~jacksontj]'s certs 
from test_ssl_multicert, as reflected in the more recent PR.

 new_tsqa SPDY protocol selection tests
 --

 Key: TS-3396
 URL: https://issues.apache.org/jira/browse/TS-3396
 Project: Traffic Server
  Issue Type: Test
  Components: SPDY, tsqa
Reporter: Eric Schwartz
Assignee: Thomas Jackson
Priority: Minor
 Fix For: sometime


 Opening this JIRA to submit some SPDY protocol selection tests using spdycat 
 I wrote using the new_tsqa.



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

[jira] [Created] (TS-3396) new_tsqa SPDY protocol selection tests

[Eric Schwartz (JIRA)]

Eric Schwartz created TS-3396:
-

 Summary: new_tsqa SPDY protocol selection tests
 Key: TS-3396
 URL: https://issues.apache.org/jira/browse/TS-3396
 Project: Traffic Server
  Issue Type: Test
  Components: SPDY, tsqa
Reporter: Eric Schwartz


Opening this JIRA to submit some SPDY protocol selection tests using spdycat I 
wrote using the new_tsqa.



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

[jira] [Commented] (TS-3396) new_tsqa SPDY protocol selection tests

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14328430#comment-14328430
 ] 

Eric Schwartz commented on TS-3396:
---

I have a pr for this. Will submit when not mobile. 

 new_tsqa SPDY protocol selection tests
 --

 Key: TS-3396
 URL: https://issues.apache.org/jira/browse/TS-3396
 Project: Traffic Server
  Issue Type: Test
  Components: SPDY, tsqa
Reporter: Eric Schwartz
Assignee: Thomas Jackson
Priority: Minor
 Fix For: sometime


 Opening this JIRA to submit some SPDY protocol selection tests using spdycat 
 I wrote using the new_tsqa.



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

[jira] [Commented] (TS-1461) traffic_manager should only try X number of times to start traffic_server

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251874#comment-14251874
 ] 

Eric Schwartz commented on TS-1461:
---

In my testing I never ran into that.  How does cop check for manager to be up? 
The process simply goes into a non signal blocking sleep (nanosleep) for a 
time, which shouldn't be a problem if cop is just checking if the process is 
up, right?

 traffic_manager should only try X number of times to start traffic_server
 -

 Key: TS-1461
 URL: https://issues.apache.org/jira/browse/TS-1461
 Project: Traffic Server
  Issue Type: Improvement
  Components: Manager
Affects Versions: 3.2.0
Reporter: David Carlin
Assignee: Eric Schwartz
Priority: Minor
 Fix For: 5.3.0


 If there is a problem with the config and traffic_server doesn't start, 
 traffic_manager still tries indefinitely to restart ATS.  This fills up the 
 TS logs, /var/log/messages, and can send out hundreds of emails via 
 proxy.config.alarm_email.
 Is it possible to have traffic_manager only attempt X number of restarts?  Or 
 X number of restarts in a given period of time?



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

[jira] [Commented] (TS-1461) traffic_manager should only try X number of times to start traffic_server

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251882#comment-14251882
 ] 

Eric Schwartz commented on TS-1461:
---

Ah ok. Well, in my testing that never seemed to be an issue. I was running all 
three processes. The timer increased to and then plateaued at 60 seconds  I 
have it logging the times it's waiting for, so this was all visible to me in 
manager.log. I will admit that I don't know exactly how traffic cop's 
healthcheck works but can look into it when I'm in to see why I wasn't seeing 
any issue. 

 traffic_manager should only try X number of times to start traffic_server
 -

 Key: TS-1461
 URL: https://issues.apache.org/jira/browse/TS-1461
 Project: Traffic Server
  Issue Type: Improvement
  Components: Manager
Affects Versions: 3.2.0
Reporter: David Carlin
Assignee: Eric Schwartz
Priority: Minor
 Fix For: 5.3.0


 If there is a problem with the config and traffic_server doesn't start, 
 traffic_manager still tries indefinitely to restart ATS.  This fills up the 
 TS logs, /var/log/messages, and can send out hundreds of emails via 
 proxy.config.alarm_email.
 Is it possible to have traffic_manager only attempt X number of restarts?  Or 
 X number of restarts in a given period of time?



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

[jira] [Commented] (TS-2157) Replace addr with appropriate src_addr and dst_addr in ConnectionAttributes

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14250264#comment-14250264
 ] 

Eric Schwartz commented on TS-2157:
---

I have started work on this and wanted to bring up the following point/possible 
ambiguity:

In HttpTransact.h we declare 4 sets of ConnectionAttributes. Right now each 
stores only one addr.  For each different set of ConnectionAttributes, it looks 
like addr corresponds to slightly different things.  For example, if we take a 
connection path to go from the client, to ATS and then on to an origin, 
client_info's addr is clearly a src_addr while server_info's seems to clearly 
be a dst_addr. This means the additional field we are adding containing the 
proxy's info could be either src_addr or dst_addr depending on which 
ConnectionAttributes struct we are observing.  This isn't a problem but is 
ambiguous (might make additional logging TS-2152 less clear for example).

Is this possible ambiguity something we care about?  I can totally implement 
this as src_addr and dst_addr if that's the desired behavior, but would 
something like proxy_addr and remote_addr make sense instead? So that we're 
consistently storing the proxy's information in the same IpEndpoint in 
ConnectionAttributes?

Thanks for any input anyone has.

 Replace addr with appropriate src_addr and dst_addr in 
 ConnectionAttributes
 -

 Key: TS-2157
 URL: https://issues.apache.org/jira/browse/TS-2157
 Project: Traffic Server
  Issue Type: New Feature
  Components: Network
Reporter: Leif Hedstrom
Assignee: Eric Schwartz
 Fix For: 6.0.0


 This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
 for each connection. In addition, we ought to be able to remove the port 
 member from ConnectionAttributes as well, and its convoluted and overloaded 
 semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
 port information as necessary.



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

[jira] [Work started] (TS-2157) Replace addr with appropriate src_addr and dst_addr in ConnectionAttributes

[Eric Schwartz (JIRA)]

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

Work on TS-2157 started by Eric Schwartz.
-
 Replace addr with appropriate src_addr and dst_addr in 
 ConnectionAttributes
 -

 Key: TS-2157
 URL: https://issues.apache.org/jira/browse/TS-2157
 Project: Traffic Server
  Issue Type: New Feature
  Components: Network
Reporter: Leif Hedstrom
Assignee: Eric Schwartz
 Fix For: 6.0.0


 This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
 for each connection. In addition, we ought to be able to remove the port 
 member from ConnectionAttributes as well, and its convoluted and overloaded 
 semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
 port information as necessary.



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

[jira] [Commented] (TS-2157) Replace addr with appropriate src_addr and dst_addr in ConnectionAttributes

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14250870#comment-14250870
 ] 

Eric Schwartz commented on TS-2157:
---

A proposal that I think might be clearer:

Instead of src_addr and dst_addr (which gets confusing because of implied 
directionality) we instead store local_addr and remote_addr.

remote_addr would correspond to what addr is now, storing the addr of the 
remote host to which ats is connecting (both in the case of server_info and 
client_info to go off of the previous comment's example)

local_addr would then store the information for the local IpEndpoint for the 
ATS host.  This would make implementation of TS-2152 (with which i am also 
conveniently tasked) much more straightforward, I think.

 Replace addr with appropriate src_addr and dst_addr in 
 ConnectionAttributes
 -

 Key: TS-2157
 URL: https://issues.apache.org/jira/browse/TS-2157
 Project: Traffic Server
  Issue Type: New Feature
  Components: Network
Reporter: Leif Hedstrom
Assignee: Eric Schwartz
 Fix For: 6.0.0


 This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
 for each connection. In addition, we ought to be able to remove the port 
 member from ConnectionAttributes as well, and its convoluted and overloaded 
 semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
 port information as necessary.



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

[jira] [Commented] (TS-1461) traffic_manager should only try X number of times to start traffic_server

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240109#comment-14240109
 ] 

Eric Schwartz commented on TS-1461:
---

I am working on this now.  I think the upper limit on restart time seems 
reasonable but was wondering if I could get some clarification re: exponential 
backoff vs # of restarts.  I think it definitely makes sense to have it do 
exponential backoff up to some upper limit but once we reach that limit do we 
wish to continue attempting to restart or after we get to the point where we've 
waited 60 seconds for a restart do we want that to be our last attempt?

It looks like David's initial concern wouldn't be solved unless we have a limit 
on the # of times we restart in addition to doing exponential backoff for time 
between restarts.  What do we think would be a reasonable # of attempts?

 traffic_manager should only try X number of times to start traffic_server
 -

 Key: TS-1461
 URL: https://issues.apache.org/jira/browse/TS-1461
 Project: Traffic Server
  Issue Type: Improvement
  Components: Manager
Affects Versions: 3.2.0
Reporter: David Carlin
Assignee: Eric Schwartz
Priority: Minor
 Fix For: 5.3.0


 If there is a problem with the config and traffic_server doesn't start, 
 traffic_manager still tries indefinitely to restart ATS.  This fills up the 
 TS logs, /var/log/messages, and can send out hundreds of emails via 
 proxy.config.alarm_email.
 Is it possible to have traffic_manager only attempt X number of restarts?  Or 
 X number of restarts in a given period of time?



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

[jira] [Comment Edited] (TS-1461) traffic_manager should only try X number of times to start traffic_server

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240109#comment-14240109
 ] 

Eric Schwartz edited comment on TS-1461 at 12/9/14 9:43 PM:


I am working on this now.  I think the upper limit on restart time seems 
reasonable but was wondering if I could get some clarification re: exponential 
backoff and # of restarts.  I think it definitely makes sense to have it do 
exponential backoff up to some upper limit but once we reach that limit do we 
wish to continue attempting to restart or after we get to the point where we've 
waited 60 seconds for a restart do we want that to be our last attempt?

It looks like David's initial concern wouldn't be solved unless we have a limit 
on the # of times we restart in addition to doing exponential backoff for time 
between restarts.  What do we think would be a reasonable # of attempts?


was (Author: es):
I am working on this now.  I think the upper limit on restart time seems 
reasonable but was wondering if I could get some clarification re: exponential 
backoff vs # of restarts.  I think it definitely makes sense to have it do 
exponential backoff up to some upper limit but once we reach that limit do we 
wish to continue attempting to restart or after we get to the point where we've 
waited 60 seconds for a restart do we want that to be our last attempt?

It looks like David's initial concern wouldn't be solved unless we have a limit 
on the # of times we restart in addition to doing exponential backoff for time 
between restarts.  What do we think would be a reasonable # of attempts?

 traffic_manager should only try X number of times to start traffic_server
 -

 Key: TS-1461
 URL: https://issues.apache.org/jira/browse/TS-1461
 Project: Traffic Server
  Issue Type: Improvement
  Components: Manager
Affects Versions: 3.2.0
Reporter: David Carlin
Assignee: Eric Schwartz
Priority: Minor
 Fix For: 5.3.0


 If there is a problem with the config and traffic_server doesn't start, 
 traffic_manager still tries indefinitely to restart ATS.  This fills up the 
 TS logs, /var/log/messages, and can send out hundreds of emails via 
 proxy.config.alarm_email.
 Is it possible to have traffic_manager only attempt X number of restarts?  Or 
 X number of restarts in a given period of time?



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

[jira] [Commented] (TS-1461) traffic_manager should only try X number of times to start traffic_server

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240246#comment-14240246
 ] 

Eric Schwartz commented on TS-1461:
---

Ah, ok.  That makes sense to me, but it's definitely different than what David 
had originally requested w.r.t. to a fixed # of times traffic_manager would 
attempt the restart.  

I suppose this would drastically cut down on the number of emails he'd be 
getting but it wouldn't impose any sort of limit.  But just to make sure I 
understand, you wouldn't want to impose any sort of cap on the # of times it 
restarted?

 traffic_manager should only try X number of times to start traffic_server
 -

 Key: TS-1461
 URL: https://issues.apache.org/jira/browse/TS-1461
 Project: Traffic Server
  Issue Type: Improvement
  Components: Manager
Affects Versions: 3.2.0
Reporter: David Carlin
Assignee: Eric Schwartz
Priority: Minor
 Fix For: 5.3.0


 If there is a problem with the config and traffic_server doesn't start, 
 traffic_manager still tries indefinitely to restart ATS.  This fills up the 
 TS logs, /var/log/messages, and can send out hundreds of emails via 
 proxy.config.alarm_email.
 Is it possible to have traffic_manager only attempt X number of restarts?  Or 
 X number of restarts in a given period of time?



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

[jira] [Comment Edited] (TS-1461) traffic_manager should only try X number of times to start traffic_server

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240246#comment-14240246
 ] 

Eric Schwartz edited comment on TS-1461 at 12/9/14 11:06 PM:
-

Ah, ok.  That makes sense to me, but it's definitely different than what David 
had originally requested w.r.t. to a fixed # of times traffic_manager would 
attempt the restart.  

I suppose this would drastically cut down on the number of emails he'd be 
getting/stop floods of emails because presumably an admin could respond during 
one of the waits but it wouldn't impose any sort of limit.  But just to make 
sure I understand, you wouldn't want to impose any sort of cap on the # of 
times it restarted?


was (Author: es):
Ah, ok.  That makes sense to me, but it's definitely different than what David 
had originally requested w.r.t. to a fixed # of times traffic_manager would 
attempt the restart.  

I suppose this would drastically cut down on the number of emails he'd be 
getting but it wouldn't impose any sort of limit.  But just to make sure I 
understand, you wouldn't want to impose any sort of cap on the # of times it 
restarted?

 traffic_manager should only try X number of times to start traffic_server
 -

 Key: TS-1461
 URL: https://issues.apache.org/jira/browse/TS-1461
 Project: Traffic Server
  Issue Type: Improvement
  Components: Manager
Affects Versions: 3.2.0
Reporter: David Carlin
Assignee: Eric Schwartz
Priority: Minor
 Fix For: 5.3.0


 If there is a problem with the config and traffic_server doesn't start, 
 traffic_manager still tries indefinitely to restart ATS.  This fills up the 
 TS logs, /var/log/messages, and can send out hundreds of emails via 
 proxy.config.alarm_email.
 Is it possible to have traffic_manager only attempt X number of restarts?  Or 
 X number of restarts in a given period of time?



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

[jira] [Commented] (TS-1461) traffic_manager should only try X number of times to start traffic_server

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240307#comment-14240307
 ] 

Eric Schwartz commented on TS-1461:
---

Spoke to David Carlin on IRC who clarified the discrepancy here.  Will 
implement with exponential back off up to 60 seconds and then just continuing 
to attempt restarting forever with this maximum wait interval.

 traffic_manager should only try X number of times to start traffic_server
 -

 Key: TS-1461
 URL: https://issues.apache.org/jira/browse/TS-1461
 Project: Traffic Server
  Issue Type: Improvement
  Components: Manager
Affects Versions: 3.2.0
Reporter: David Carlin
Assignee: Eric Schwartz
Priority: Minor
 Fix For: 5.3.0


 If there is a problem with the config and traffic_server doesn't start, 
 traffic_manager still tries indefinitely to restart ATS.  This fills up the 
 TS logs, /var/log/messages, and can send out hundreds of emails via 
 proxy.config.alarm_email.
 Is it possible to have traffic_manager only attempt X number of restarts?  Or 
 X number of restarts in a given period of time?



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

[jira] [Commented] (TS-2152) Create a tag that logs the destination IP of the client connection

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207067#comment-14207067
 ] 

Eric Schwartz commented on TS-2152:
---

Ping.

 Create a tag that logs the destination IP of the client connection
 --

 Key: TS-2152
 URL: https://issues.apache.org/jira/browse/TS-2152
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Leif Hedstrom
  Labels: newbie
 Fix For: 6.0.0


 This would log the IP of the proxy server, as the client connected to. This 
 is useful for two reasons:
 1) A box can be multi-homed
 2) In a IPv4 / IPv6, you can then tell which endpoint the client connected to.



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

[jira] [Comment Edited] (TS-2152) Create a tag that logs the destination IP of the client connection

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207067#comment-14207067
 ] 

Eric Schwartz edited comment on TS-2152 at 11/11/14 9:15 PM:
-

Commenting so Alan can find my profile.


was (Author: es):
Ping.

 Create a tag that logs the destination IP of the client connection
 --

 Key: TS-2152
 URL: https://issues.apache.org/jira/browse/TS-2152
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Leif Hedstrom
  Labels: newbie
 Fix For: 6.0.0


 This would log the IP of the proxy server, as the client connected to. This 
 is useful for two reasons:
 1) A box can be multi-homed
 2) In a IPv4 / IPv6, you can then tell which endpoint the client connected to.



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