[jira] [Created] (TS-3878) icp.config is not reloadable

2015-08-31 Thread Gota Adachi (JIRA)
Gota Adachi created TS-3878:
---

 Summary: icp.config is not reloadable
 Key: TS-3878
 URL: https://issues.apache.org/jira/browse/TS-3878
 Project: Traffic Server
  Issue Type: Bug
  Components: ICP
Reporter: Gota Adachi


Currently, traffic_server(or traffic_manager) is able to recognize any changes 
of icp.config which exec traffic_line -x.
But reloading function doesn't work.
{noformat}
# cat /usr/local/var/log/trafficserver/traffic.out 
[E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
traffic_server: using root directory '/usr/local'
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) On=2, MultiCast=0, 
Timeout=1 LocalCacheLookup=0
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) StaleLookup=0, 
ReplyToUnknowPeer=0, DefaultReplyPort=0
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: Type=L 
IP=192.168.56.98:3130 PPort=0 Host=localhost
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: MC ON=0 
MC_IP=*Not IP address [0]* MC_TTL=0
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: Type=S 
IP=192.168.56.22:3130 PPort=8080 Host=
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: MC ON=0 
MC_IP=0.0.0.0 MC_TTL=1
# vi /usr/local/etc/trafficserver/icp.config (change something)
# /usr/local/bin/traffic_ctl config reload
# cat /usr/local/var/log/trafficserver/traffic.out
[E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
traffic_server: using root directory '/usr/local'
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) On=2, MultiCast=0, 
Timeout=1 LocalCacheLookup=0
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) StaleLookup=0, 
ReplyToUnknowPeer=0, DefaultReplyPort=0
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: Type=L 
IP=192.168.56.98:3130 PPort=0 Host=localhost
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: MC ON=0 
MC_IP=*Not IP address [0]* MC_TTL=0
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: Type=S 
IP=192.168.56.22:3130 PPort=8080 Host=
[Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: MC ON=0 
MC_IP=0.0.0.0 MC_TTL=1
{noformat}
It is caused that termination of the icp process function doesn't work.

icp processor open socket for waiting query, and when finish the icp processor,
it sends a dummy queries towards the socket opened at 
ICPProcessor::CancelPendingReads().
{noformat}
void
ICPProcessor::CancelPendingReads()
{
  // Cancel pending ICP read by sending a bogus message to
  //  the local ICP port.
 
  // ...snip... 
  Peer *lp = GetLocalPeer();
  r->_sendMsgHdr.msg_name = (caddr_t) & (lp->GetSendChan())->addr;
  r->_sendMsgHdr.msg_namelen = sizeof((lp->GetSendChan())->addr);
  udpNet.sendmsg_re(r, r, lp->GetSendFD(), >_sendMsgHdr);
}
{noformat}
But this function's implemetation is broken because (lp->GetSendChan())->addr 
is not contain
local endpoint address, and it contains all 0. Therefore udpNet.sendmsg_re() 
always fail.

This problem is able to fix if only that set local endpoint address 
appropriately.

The patch that fix this issue is below(for currently master branch):
{noformat}
diff --git a/proxy/ICP.cc b/proxy/ICP.cc
index 4f3c768..7eacebb 100644
--- a/proxy/ICP.cc
+++ b/proxy/ICP.cc
@@ -2209,8 +2209,10 @@ ICPProcessor::CancelPendingReads()
   r->_ICPmsg.h.version = ~r->_ICPmsg.h.version; // bogus message
 
   Peer *lp = GetLocalPeer();
-  r->_sendMsgHdr.msg_name = (caddr_t) & (lp->GetSendChan())->addr;
-  r->_sendMsgHdr.msg_namelen = sizeof((lp->GetSendChan())->addr);
+  IpEndpoint local_endpoint;
+  ats_ip_copy(_endpoint.sa, lp->GetIP());
+  r->_sendMsgHdr.msg_name = (caddr_t) & local_endpoint;
+  r->_sendMsgHdr.msg_namelen = sizeof(local_endpoint);
   udpNet.sendmsg_re(r, r, lp->GetSendFD(), >_sendMsgHdr);
 }
 
{noformat}


Testing configurations:
{panel:title=records.config}
#...
CONFIG proxy.config.icp.enabled INT 2
CONFIG proxy.config.icp.icp_interface STRING eth1
CONFIG proxy.config.icp.icp_port INT 3130
CONFIG proxy.config.icp.multicast_enabled INT 0
CONFIG proxy.config.icp.query_timeout INT 1
#...
#output debugging messages for icp (minimal)
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING icp
{panel}
{panel:title=icp.config}
:192.168.56.22:2:8080:3130:0:0.0.0.0:1:
#:192.168.56.23:2:8080:3130:0:0.0.0.0:1:
{panel}


it works like this:
{noformat}
# /etc/init.d/trafficserver start
Starting Apache Traffic Server:[  OK  ]
# cat /usr/local/var/log/trafficserver/traffic.out
traffic_server: using root directory '/usr/local'
[Sep  1 08:28:32.404] Server {0x2ab665d0b040} DEBUG: (icp) On=2, MultiCast=0, 
Timeout=1 LocalCacheLookup=0
[Sep  1 08:28:32.404] Server {0x2ab665d0b040} DEBUG: (icp) StaleLookup=0, 
ReplyToUnknowPeer=0, DefaultReplyPort=0
[Sep  1 08:28:32.404] Server {0x2ab665d0b040} DEBUG: (icp) [0]: 

[jira] [Commented] (TS-3872) Enhance open_write_fail_action feature to support returning error on revalidation.

2015-08-31 Thread William Bardwell (JIRA)

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

William Bardwell commented on TS-3872:
--

Do any of those options go ahead and do a conditional revalidate (even if they 
can't save the answer), just passing through the answer if they don't get a 
304?  Because that seems like a much better behavior than the old 'tunnel' case 
(aka 0), but I wasn't clear if one of the other options does that...

> Enhance open_write_fail_action feature to support returning error on 
> revalidation.
> --
>
> Key: TS-3872
> URL: https://issues.apache.org/jira/browse/TS-3872
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> Refer TS-3549.
> The setting *proxy.config.http.cache.open_write_fail_action* currently 
> supports the below options:
> On a cache write lock failure (multiple concurrent requests for the same 
> object):
> (a) Return a 502 error on cache miss
> (b) Return a stale copy on revalidation
> (c) Both (a) and (b)
> This jira is to add a new option to allow ATS to return a 502 error on both 
> cache miss as well as revalidation scenario.



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


[jira] [Updated] (TS-3878) icp.config is not reloadable

2015-08-31 Thread Gota Adachi (JIRA)

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

Gota Adachi updated TS-3878:

Affects Version/s: 4.2.3
   5.3.1

> icp.config is not reloadable
> 
>
> Key: TS-3878
> URL: https://issues.apache.org/jira/browse/TS-3878
> Project: Traffic Server
>  Issue Type: Bug
>  Components: ICP
>Affects Versions: 4.2.3, 5.3.1
>Reporter: Gota Adachi
>
> Currently, traffic_server(or traffic_manager) is able to recognize any 
> changes of icp.config which exec traffic_line -x.
> But reloading function doesn't work.
> {noformat}
> # cat /usr/local/var/log/trafficserver/traffic.out 
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
> traffic_server: using root directory '/usr/local'
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) On=2, MultiCast=0, 
> Timeout=1 LocalCacheLookup=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) StaleLookup=0, 
> ReplyToUnknowPeer=0, DefaultReplyPort=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: Type=L 
> IP=192.168.56.98:3130 PPort=0 Host=localhost
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: MC ON=0 
> MC_IP=*Not IP address [0]* MC_TTL=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: Type=S 
> IP=192.168.56.22:3130 PPort=8080 Host=
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: MC ON=0 
> MC_IP=0.0.0.0 MC_TTL=1
> # vi /usr/local/etc/trafficserver/icp.config (change something)
> # /usr/local/bin/traffic_ctl config reload
> # cat /usr/local/var/log/trafficserver/traffic.out
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
> traffic_server: using root directory '/usr/local'
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) On=2, MultiCast=0, 
> Timeout=1 LocalCacheLookup=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) StaleLookup=0, 
> ReplyToUnknowPeer=0, DefaultReplyPort=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: Type=L 
> IP=192.168.56.98:3130 PPort=0 Host=localhost
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: MC ON=0 
> MC_IP=*Not IP address [0]* MC_TTL=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: Type=S 
> IP=192.168.56.22:3130 PPort=8080 Host=
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: MC ON=0 
> MC_IP=0.0.0.0 MC_TTL=1
> {noformat}
> It is caused that termination of the icp process function doesn't work.
> icp processor open socket for waiting query, and when finish the icp 
> processor,
> it sends a dummy queries towards the socket opened at 
> ICPProcessor::CancelPendingReads().
> {noformat}
> void
> ICPProcessor::CancelPendingReads()
> {
>   // Cancel pending ICP read by sending a bogus message to
>   //  the local ICP port.
>  
>   // ...snip... 
>   Peer *lp = GetLocalPeer();
>   r->_sendMsgHdr.msg_name = (caddr_t) & (lp->GetSendChan())->addr;
>   r->_sendMsgHdr.msg_namelen = sizeof((lp->GetSendChan())->addr);
>   udpNet.sendmsg_re(r, r, lp->GetSendFD(), >_sendMsgHdr);
> }
> {noformat}
> But this function's implemetation is broken because (lp->GetSendChan())->addr 
> is not contain
> local endpoint address, and it contains all 0. Therefore udpNet.sendmsg_re() 
> always fail.
> This problem is able to fix if only that set local endpoint address 
> appropriately.
> The patch that fix this issue is below(for currently master branch):
> {noformat}
> diff --git a/proxy/ICP.cc b/proxy/ICP.cc
> index 4f3c768..7eacebb 100644
> --- a/proxy/ICP.cc
> +++ b/proxy/ICP.cc
> @@ -2209,8 +2209,10 @@ ICPProcessor::CancelPendingReads()
>r->_ICPmsg.h.version = ~r->_ICPmsg.h.version; // bogus message
>  
>Peer *lp = GetLocalPeer();
> -  r->_sendMsgHdr.msg_name = (caddr_t) & (lp->GetSendChan())->addr;
> -  r->_sendMsgHdr.msg_namelen = sizeof((lp->GetSendChan())->addr);
> +  IpEndpoint local_endpoint;
> +  ats_ip_copy(_endpoint.sa, lp->GetIP());
> +  r->_sendMsgHdr.msg_name = (caddr_t) & local_endpoint;
> +  r->_sendMsgHdr.msg_namelen = sizeof(local_endpoint);
>udpNet.sendmsg_re(r, r, lp->GetSendFD(), >_sendMsgHdr);
>  }
>  
> {noformat}
> Testing configurations:
> {panel:title=records.config}
> #...
> CONFIG proxy.config.icp.enabled INT 2
> CONFIG proxy.config.icp.icp_interface STRING eth1
> CONFIG proxy.config.icp.icp_port INT 3130
> CONFIG proxy.config.icp.multicast_enabled INT 0
> CONFIG proxy.config.icp.query_timeout INT 1
> #...
> #output debugging messages for icp (minimal)
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING icp
> {panel}
> {panel:title=icp.config}
> :192.168.56.22:2:8080:3130:0:0.0.0.0:1:
> #:192.168.56.23:2:8080:3130:0:0.0.0.0:1:
> {panel}
> it works like this:
> {noformat}
> # /etc/init.d/trafficserver start
> Starting Apache Traffic 

[jira] [Commented] (TS-3874) Header-rewrite doesn't support multiple header values in conditionals

2015-08-31 Thread Thomas Jackson (JIRA)

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

Thomas Jackson commented on TS-3874:


I'm fine with a backport, although I haven't done one before-- whats the
process for that (I assume there is something besides just pushing into the
6.x branch)?

On Sat, Aug 29, 2015 at 9:50 AM, Sudheer Vinukonda (JIRA) 



> Header-rewrite doesn't support multiple header values in conditionals
> -
>
> Key: TS-3874
> URL: https://issues.apache.org/jira/browse/TS-3874
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> Lets say we have the following rule
> {code}
> cond %{HEADER:foo} /bar/
> add-header Baz1 1
> cond %{HEADER:foo} =bar
> add-header Baz2 2
> {code}
> There are some weird interactions with how this works today, so lets start 
> with that:
> some request headers, and outcomes
> {code}
> # matches 1 and 2
> foo: bar
> # matches both 1 and 2
> foo: bar
> foo: baz
> # matches nothing
> foo: baz
> foo: bar
> {code}
> So the main problem we see here is that the second value is completely 
> ignored all of the time-- which is bad ;)
> And when we get more complicated there are some more issues. In HTTP headers 
> have to be collapsible into a single line 
> (http://tools.ietf.org/html/rfc2616#section-4.2). This means that 2 headers 
> with values `foo` and `bar` *must* be equivalent to a single header with 
> value `foo,bar`. With that information, lets assume the downstream actually 
> sent the values in the same header (which is completely valid-- and has to be 
> treated the same according to the RFC).
> {code}
> # matches 1
> foo: bar,baz
> # matches 1
> foo: baz,bar
> {code}
> So this means we can boil down the problem into 2 pieces: (1) duplicate 
> headers are ignored and (2) collapsed headers are treated differently than 
> separate headers.
> So, I have a PR open on github 
> (https://github.com/apache/trafficserver/pull/284) which combines the headers 
> (according to the RFC) before passing it to the conditional's matcher. Here 
> are the outcomes of the same set of headers
> {code}
> # matches 1 and 2
> foo: bar
> # matches 1
> foo: bar
> foo: baz
> # matches 1
> foo: baz
> foo: bar
> # matches 1
> foo: bar,baz
> # matches 1
> foo: baz,bar
> {code}
> And with this we have fixed both (1) taking the second header value as well 
> as (2) treating collapsed and non-collapsed the same.



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


[jira] [Updated] (TS-3874) Header-rewrite doesn't support multiple header values in conditionals

2015-08-31 Thread Sudheer Vinukonda (JIRA)

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

Sudheer Vinukonda updated TS-3874:
--
Backport to Version: 6.0.0

> Header-rewrite doesn't support multiple header values in conditionals
> -
>
> Key: TS-3874
> URL: https://issues.apache.org/jira/browse/TS-3874
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> Lets say we have the following rule
> {code}
> cond %{HEADER:foo} /bar/
> add-header Baz1 1
> cond %{HEADER:foo} =bar
> add-header Baz2 2
> {code}
> There are some weird interactions with how this works today, so lets start 
> with that:
> some request headers, and outcomes
> {code}
> # matches 1 and 2
> foo: bar
> # matches both 1 and 2
> foo: bar
> foo: baz
> # matches nothing
> foo: baz
> foo: bar
> {code}
> So the main problem we see here is that the second value is completely 
> ignored all of the time-- which is bad ;)
> And when we get more complicated there are some more issues. In HTTP headers 
> have to be collapsible into a single line 
> (http://tools.ietf.org/html/rfc2616#section-4.2). This means that 2 headers 
> with values `foo` and `bar` *must* be equivalent to a single header with 
> value `foo,bar`. With that information, lets assume the downstream actually 
> sent the values in the same header (which is completely valid-- and has to be 
> treated the same according to the RFC).
> {code}
> # matches 1
> foo: bar,baz
> # matches 1
> foo: baz,bar
> {code}
> So this means we can boil down the problem into 2 pieces: (1) duplicate 
> headers are ignored and (2) collapsed headers are treated differently than 
> separate headers.
> So, I have a PR open on github 
> (https://github.com/apache/trafficserver/pull/284) which combines the headers 
> (according to the RFC) before passing it to the conditional's matcher. Here 
> are the outcomes of the same set of headers
> {code}
> # matches 1 and 2
> foo: bar
> # matches 1
> foo: bar
> foo: baz
> # matches 1
> foo: baz
> foo: bar
> # matches 1
> foo: bar,baz
> # matches 1
> foo: baz,bar
> {code}
> And with this we have fixed both (1) taking the second header value as well 
> as (2) treating collapsed and non-collapsed the same.



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


[jira] [Commented] (TS-3874) Header-rewrite doesn't support multiple header values in conditionals

2015-08-31 Thread Sudheer Vinukonda (JIRA)

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

Sudheer Vinukonda commented on TS-3874:
---

You just need to mark the jira with "Back port to Version" to the intended 
version and let the RM for the release do the merge. I've marked this jira to a 
back port and I suppose [~bcall] (RM for 6.0.0) will get to it, when he can.

> Header-rewrite doesn't support multiple header values in conditionals
> -
>
> Key: TS-3874
> URL: https://issues.apache.org/jira/browse/TS-3874
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> Lets say we have the following rule
> {code}
> cond %{HEADER:foo} /bar/
> add-header Baz1 1
> cond %{HEADER:foo} =bar
> add-header Baz2 2
> {code}
> There are some weird interactions with how this works today, so lets start 
> with that:
> some request headers, and outcomes
> {code}
> # matches 1 and 2
> foo: bar
> # matches both 1 and 2
> foo: bar
> foo: baz
> # matches nothing
> foo: baz
> foo: bar
> {code}
> So the main problem we see here is that the second value is completely 
> ignored all of the time-- which is bad ;)
> And when we get more complicated there are some more issues. In HTTP headers 
> have to be collapsible into a single line 
> (http://tools.ietf.org/html/rfc2616#section-4.2). This means that 2 headers 
> with values `foo` and `bar` *must* be equivalent to a single header with 
> value `foo,bar`. With that information, lets assume the downstream actually 
> sent the values in the same header (which is completely valid-- and has to be 
> treated the same according to the RFC).
> {code}
> # matches 1
> foo: bar,baz
> # matches 1
> foo: baz,bar
> {code}
> So this means we can boil down the problem into 2 pieces: (1) duplicate 
> headers are ignored and (2) collapsed headers are treated differently than 
> separate headers.
> So, I have a PR open on github 
> (https://github.com/apache/trafficserver/pull/284) which combines the headers 
> (according to the RFC) before passing it to the conditional's matcher. Here 
> are the outcomes of the same set of headers
> {code}
> # matches 1 and 2
> foo: bar
> # matches 1
> foo: bar
> foo: baz
> # matches 1
> foo: baz
> foo: bar
> # matches 1
> foo: bar,baz
> # matches 1
> foo: baz,bar
> {code}
> And with this we have fixed both (1) taking the second header value as well 
> as (2) treating collapsed and non-collapsed the same.



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


Jenkins build is still unstable: tsqa-lint #514

2015-08-31 Thread jenkins
See 



Jenkins build is still unstable: tsqa-lint #515

2015-08-31 Thread jenkins
See 



Build failed in Jenkins: tsqa-master #828

2015-08-31 Thread jenkins
See 

Changes:

[nkew] stream_editor: #define WHITESPACE rather than spell it out every time

--
[...truncated 491 lines...]
INFO 2015-08-31 17:42:32,093 - Client disconnected
INFO 2015-08-31 17:42:32,283 - Environment prefix is /tmp/tsqa.env.icEZan
INFO 2015-08-31 17:42:34,086 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... ok
Verify that we get 502s from origins that reset_after_accept, once any bytes 
are sent to origin we assume we cannot re-dispatch ... ok
INFO 2015-08-31 17:42:43,602 - Environment prefix is /tmp/tsqa.env.mjFvvQ
test_log_field (test_custom_log.TestCustomLogField) ... ok
INFO 2015-08-31 17:44:27,172 - Environment prefix is /tmp/tsqa.env.HTXx86
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-08-31 17:44:56,831 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-08-31 17:45:46,025 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-08-31 17:45:46,090 - Environment prefix is /tmp/tsqa.env.jPOTMJ
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-08-31 17:45:49,511 - Environment prefix is /tmp/tsqa.env.m5XPHj
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[31/Aug/2015 17:45:52] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-08-31 17:45:52,945 - Environment prefix is /tmp/tsqa.env.ZRviX6
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [31/Aug/2015 17:45:56] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-08-31 17:46:06,452 - Environment prefix is /tmp/tsqa.env.8XVjZ8
test_logs_exist (test_example.TestLogs) ... ok
SKIP: Skip the entire class
INFO 2015-08-31 17:46:19,915 - Environment prefix is /tmp/tsqa.env.ddZtm1
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [31/Aug/2015 17:46:23] "GET / HTTP/1.1" 200 5
ok
INFO 2015-08-31 17:46:23,364 - Environment prefix is /tmp/tsqa.env.12DQih
INFO 2015-08-31 17:46:23,366 - map / http://127.0.0.1:52591/
test_head_request_without_timout 
(test_headrequest.TestHeadRequestWithoutTimeout) ... INFO 2015-08-31 
17:46:26,602 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Vary: Accept-Encoding
Date: Mon, 31 Aug 2015 17:46:26 GMT
Age: 0
Connection: close


INFO 2015-08-31 17:46:26,602 - head request with case(TE) costs 0.003810 
seconds while the timout is 5.00 seconds.
INFO 2015-08-31 17:46:26,603 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Content-Length: 123
Vary: Accept-Encoding
Date: Mon, 31 Aug 2015 17:46:26 GMT
Age: 0
Connection: close


INFO 2015-08-31 17:46:26,603 - head request with case(CL) costs 0.001189 
seconds while the timout is 5.00 seconds.
INFO 2015-08-31 17:46:26,619 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Vary: Accept-Encoding
Date: Mon, 31 Aug 2015 17:46:26 GMT
Age: 0
Connection: close


INFO 2015-08-31 17:46:26,619 - head request with case() costs 0.015866 seconds 
while the timout is 5.00 seconds.
ok
INFO 2015-08-31 17:46:26,803 - Environment prefix is /tmp/tsqa.env.5nQFwL
test_working (test_hostdb.TestHostDBBadResolvConf) ... ok
INFO 2015-08-31 17:46:30,253 - Environment prefix is /tmp/tsqa.env.wUX4bQ

[jira] [Created] (TS-3875) Have SPDY allocate the MIOBuffers directly so we can track memory usage better

2015-08-31 Thread Bryan Call (JIRA)
Bryan Call created TS-3875:
--

 Summary: Have SPDY allocate the MIOBuffers directly so we can 
track memory usage better
 Key: TS-3875
 URL: https://issues.apache.org/jira/browse/TS-3875
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Bryan Call






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


[jira] [Commented] (TS-3875) Have SPDY allocate the MIOBuffers directly so we can track memory usage better

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call commented on TS-3875:


Instead of using TSIOBufferCreate, we can use 
reinterpret_cast(new_empty_MIOBuffer()).  This will allow us to 
track memory usage better when running with proxy.config.res_track_memory 
enabled.

> Have SPDY allocate the MIOBuffers directly so we can track memory usage better
> --
>
> Key: TS-3875
> URL: https://issues.apache.org/jira/browse/TS-3875
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
> Fix For: 6.1.0
>
>




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


[jira] [Updated] (TS-3875) Have SPDY allocate the MIOBuffers directly so we can track memory usage better

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call updated TS-3875:
---
Affects Version/s: 5.3.0

> Have SPDY allocate the MIOBuffers directly so we can track memory usage better
> --
>
> Key: TS-3875
> URL: https://issues.apache.org/jira/browse/TS-3875
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>




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


[jira] [Assigned] (TS-3875) Have SPDY allocate the MIOBuffers directly so we can track memory usage better

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call reassigned TS-3875:
--

Assignee: Bryan Call

> Have SPDY allocate the MIOBuffers directly so we can track memory usage better
> --
>
> Key: TS-3875
> URL: https://issues.apache.org/jira/browse/TS-3875
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>




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


[jira] [Commented] (TS-3875) Have SPDY allocate the MIOBuffers directly so we can track memory usage better

2015-08-31 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on TS-3875:
-

Commit 15c27d277057421b1dcae868db55772da3b84298 in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=15c27d2 ]

TS-3875: Have SPDY allocate the MIOBuffers directly so we can track memory 
usage better


> Have SPDY allocate the MIOBuffers directly so we can track memory usage better
> --
>
> Key: TS-3875
> URL: https://issues.apache.org/jira/browse/TS-3875
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.1.0
>
>




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


Jenkins build is still unstable: tsqa-lint #516

2015-08-31 Thread jenkins
See 



[jira] [Updated] (TS-3875) Have SPDY allocate the MIOBuffers directly so we can track memory usage better

2015-08-31 Thread David Carlin (JIRA)

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

David Carlin updated TS-3875:
-
Labels: yahoo  (was: )

> Have SPDY allocate the MIOBuffers directly so we can track memory usage better
> --
>
> Key: TS-3875
> URL: https://issues.apache.org/jira/browse/TS-3875
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Affects Versions: 5.3.0
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>




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


[jira] [Assigned] (TS-3876) add unit test framework for scripts for lua plugin

2015-08-31 Thread Kit Chan (JIRA)

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

Kit Chan reassigned TS-3876:


Assignee: Kit Chan

> add unit test framework for scripts for lua plugin
> --
>
> Key: TS-3876
> URL: https://issues.apache.org/jira/browse/TS-3876
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
>
> We want to provide the unit test framework we use for writing lua scripts for 
> the ts_lua plugin



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


[jira] [Created] (TS-3877) Add a tracking ClassAllocator to keep track of where the allocation happened

2015-08-31 Thread Bryan Call (JIRA)
Bryan Call created TS-3877:
--

 Summary: Add a tracking ClassAllocator to keep track of where the 
allocation happened
 Key: TS-3877
 URL: https://issues.apache.org/jira/browse/TS-3877
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Bryan Call






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


[jira] [Commented] (TS-3877) Add a tracking ClassAllocator to keep track of where the allocation happened

2015-08-31 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on TS-3877:
-

Commit 0bae26a9402203c55e36292abe7278971a910034 in trafficserver's branch 
refs/heads/master from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0bae26a ]

TS-3877: Add a tracking ClassAllocator to keep track of where the allocation 
happened


> Add a tracking ClassAllocator to keep track of where the allocation happened
> 
>
> Key: TS-3877
> URL: https://issues.apache.org/jira/browse/TS-3877
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Bryan Call
>




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


[jira] [Commented] (TS-3877) Add a tracking ClassAllocator to keep track of where the allocation happened

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call commented on TS-3877:


To use the TrackerClassAllocator you will need to replace the ClassAllocator 
with this class.

> Add a tracking ClassAllocator to keep track of where the allocation happened
> 
>
> Key: TS-3877
> URL: https://issues.apache.org/jira/browse/TS-3877
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Bryan Call
>




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


Jenkins build is still unstable: tsqa-lint #517

2015-08-31 Thread jenkins
See 



Jenkins build is still unstable: tsqa-lint #518

2015-08-31 Thread jenkins
See 



[jira] [Comment Edited] (TS-3877) Add a tracking ClassAllocator to keep track of where the allocation happened

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call edited comment on TS-3877 at 9/1/15 1:34 AM:


To use the TrackerClassAllocator you will need to replace the ClassAllocator 
with this class.

Example Code:
{code}
diff --git a/iocore/eventsystem/I_Lock.h b/iocore/eventsystem/I_Lock.h
index e90d1bf..0d9cc86 100644
--- a/iocore/eventsystem/I_Lock.h
+++ b/iocore/eventsystem/I_Lock.h
@@ -275,7 +275,7 @@ public:
 };

 // The ClassAlocator for ProxyMutexes
-extern inkcoreapi ClassAllocator mutexAllocator;
+extern inkcoreapi TrackerClassAllocator mutexAllocator;

 inline bool
 Mutex_trylock(
diff --git a/iocore/eventsystem/Lock.cc b/iocore/eventsystem/Lock.cc
index 098884c..83241e7 100644
--- a/iocore/eventsystem/Lock.cc
+++ b/iocore/eventsystem/Lock.cc
@@ -31,7 +31,7 @@
 #include "P_EventSystem.h"
 #include "ts/Diags.h"

-ClassAllocator mutexAllocator("mutexAllocator");
+TrackerClassAllocator mutexAllocator("mutexAllocator");

 void
 lock_waiting(const SrcLoc , const char *handler)
{code}

Example Output:
{code}
Allocs | Frees  | Size In-use  | Avg Size   | Location
---||--||
 1 |  0 |   96 | 96 | 1   
traffic_server  0x00010328ee13 _Z16initCacheControlv + 
19
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001032b2720 _ZN7IpAllow7startupEv + 
32
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001032ce41b main + 4619
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001032d1250 
_ZN12ParentConfig7startupEv + 32
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001032df6d3 _Z18init_reverse_proxyv 
+ 19
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001032e2aed _Z16start_stats_snapv + 
429
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001032e3091 
_Z27initialize_all_global_statsv + 1201
 1 |  0 |   96 | 96 | 1   
traffic_server  0x000103371f62 
_ZN10HttpConfig7startupEv + 82
63 |  0 | 6048 | 96 | 1   
traffic_server  0x000103376ee8 _Z15http_pages_initv + 72
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001033776b1 
_Z20init_HttpProxyServeri + 449
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001033777ef 
_Z20init_HttpProxyServeri + 767
 2 |  0 |  192 | 96 | 1   
traffic_server  0x00010339839d 
_ZN17ServerSessionPoolC2Ev + 29
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001033ef14e 
_Z21initCongestionControlv + 46
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001033fb5c9 
_ZN3Log17init_when_enabledEv + 249
64 |  0 | 6144 | 96 | 1   
traffic_server  0x000103447208 
_ZN15HostDBProcessor5startEim + 56
 1 |  0 |   96 | 96 | 1   
traffic_server  0x00010344754e 
_ZN15HostDBProcessor5startEim + 894
 1 |  0 |   96 | 96 | 1   
traffic_server  0x0001034476fe 
_ZN15HostDBProcessor5startEim + 1326
 1 |  0 |   96 | 96 | 1   
traffic_server  0x00010346ec27 
_ZN14SplitDNSConfig7startupEv + 23
 1 |  0 |   96 | 96 | 1   
traffic_server  0x00010346ecb7 
_ZN14SplitDNSConfig7startupEv + 167
 1 |  0 |   96 | 96 | 1   
traffic_server  0x000103470a83 _Z15clusterAPI_initv + 51
   256 |  0 |24576 | 96 | 1   
traffic_server  0x000103471dac 
_ZN23ClusterVConnectionCache4initEv + 60
   256 |  0 |24576 | 96 | 1   
traffic_server  0x000103471e59 
_ZN23ClusterVConnectionCache4initEv + 233
 16384 |  0 |  1572864 | 96 | 1   
traffic_server  0x000103472808 
_ZN17CacheContinuation4initEv + 56
 1 |  0 |  

[jira] [Updated] (TS-3877) Add a tracking ClassAllocator to keep track of where the allocation happened

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call updated TS-3877:
---
Component/s: Core

> Add a tracking ClassAllocator to keep track of where the allocation happened
> 
>
> Key: TS-3877
> URL: https://issues.apache.org/jira/browse/TS-3877
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 6.1.0
>
>




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


[jira] [Updated] (TS-3877) Add a tracking ClassAllocator to keep track of where the allocation happened

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call updated TS-3877:
---
Fix Version/s: 6.1.0

> Add a tracking ClassAllocator to keep track of where the allocation happened
> 
>
> Key: TS-3877
> URL: https://issues.apache.org/jira/browse/TS-3877
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
> Fix For: 6.1.0
>
>




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


[jira] [Resolved] (TS-3877) Add a tracking ClassAllocator to keep track of where the allocation happened

2015-08-31 Thread Bryan Call (JIRA)

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

Bryan Call resolved TS-3877.

Resolution: Fixed

> Add a tracking ClassAllocator to keep track of where the allocation happened
> 
>
> Key: TS-3877
> URL: https://issues.apache.org/jira/browse/TS-3877
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>




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


Build failed in Jenkins: tsqa-master #830

2015-08-31 Thread jenkins
See 

Changes:

[Bryan Call] TS-3877: Add a tracking ClassAllocator to keep track of where the 
allocation happened

--
[...truncated 491 lines...]
INFO 2015-09-01 01:43:38,841 - Client disconnected
INFO 2015-09-01 01:43:39,038 - Environment prefix is /tmp/tsqa.env.FMKbYz
INFO 2015-09-01 01:43:40,836 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... ok
Verify that we get 502s from origins that reset_after_accept, once any bytes 
are sent to origin we assume we cannot re-dispatch ... ok
INFO 2015-09-01 01:43:49,344 - Environment prefix is /tmp/tsqa.env.taXJc0
test_log_field (test_custom_log.TestCustomLogField) ... ok
INFO 2015-09-01 01:45:32,932 - Environment prefix is /tmp/tsqa.env.koU9b9
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-09-01 01:46:02,765 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-09-01 01:48:21,337 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-09-01 01:48:21,402 - Environment prefix is /tmp/tsqa.env.dk_vm4
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-09-01 01:48:24,832 - Environment prefix is /tmp/tsqa.env.wrTA_s
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[01/Sep/2015 01:48:28] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-09-01 01:48:28,274 - Environment prefix is /tmp/tsqa.env.owcjlf
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [01/Sep/2015 01:48:31] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-09-01 01:48:41,782 - Environment prefix is /tmp/tsqa.env.lwe08P
test_logs_exist (test_example.TestLogs) ... ok
SKIP: Skip the entire class
INFO 2015-09-01 01:48:55,293 - Environment prefix is /tmp/tsqa.env.GoEesZ
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [01/Sep/2015 01:48:58] "GET / HTTP/1.1" 200 5
ok
INFO 2015-09-01 01:48:58,764 - Environment prefix is /tmp/tsqa.env.colnpq
INFO 2015-09-01 01:48:58,766 - map / http://127.0.0.1:52668/
test_head_request_without_timout 
(test_headrequest.TestHeadRequestWithoutTimeout) ... INFO 2015-09-01 
01:49:02,006 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Vary: Accept-Encoding
Date: Tue, 01 Sep 2015 01:49:02 GMT
Age: 0
Connection: close


INFO 2015-09-01 01:49:02,006 - head request with case(TE) costs 0.016247 
seconds while the timout is 5.00 seconds.
INFO 2015-09-01 01:49:02,007 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Content-Length: 123
Vary: Accept-Encoding
Date: Tue, 01 Sep 2015 01:49:02 GMT
Age: 0
Connection: close


INFO 2015-09-01 01:49:02,007 - head request with case(CL) costs 0.001332 
seconds while the timout is 5.00 seconds.
INFO 2015-09-01 01:49:02,009 - HTTP/1.1 200 OK
Server: ATS/6.1.0
Vary: Accept-Encoding
Date: Tue, 01 Sep 2015 01:49:02 GMT
Age: 0
Connection: close


INFO 2015-09-01 01:49:02,009 - head request with case() costs 0.001129 seconds 
while the timout is 5.00 seconds.
ok
INFO 2015-09-01 01:49:02,200 - Environment prefix is /tmp/tsqa.env.F9DISC
test_working (test_hostdb.TestHostDBBadResolvConf) ... ok
INFO 2015-09-01 01:49:05,656 - Environment prefix is 

[jira] [Updated] (TS-3878) icp.config is not reloadable

2015-08-31 Thread Gota Adachi (JIRA)

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

Gota Adachi updated TS-3878:

Attachment: ts-3878_5.3.x.patch
ts-3878_master.patch

> icp.config is not reloadable
> 
>
> Key: TS-3878
> URL: https://issues.apache.org/jira/browse/TS-3878
> Project: Traffic Server
>  Issue Type: Bug
>  Components: ICP
>Affects Versions: 4.2.3, 5.3.1
>Reporter: Gota Adachi
> Attachments: ts-3878_5.3.x.patch, ts-3878_master.patch
>
>
> Currently, traffic_server(or traffic_manager) is able to recognize any 
> changes of icp.config which exec traffic_line -x.
> But reloading function doesn't work.
> {noformat}
> # cat /usr/local/var/log/trafficserver/traffic.out 
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
> traffic_server: using root directory '/usr/local'
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) On=2, MultiCast=0, 
> Timeout=1 LocalCacheLookup=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) StaleLookup=0, 
> ReplyToUnknowPeer=0, DefaultReplyPort=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: Type=L 
> IP=192.168.56.98:3130 PPort=0 Host=localhost
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: MC ON=0 
> MC_IP=*Not IP address [0]* MC_TTL=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: Type=S 
> IP=192.168.56.22:3130 PPort=8080 Host=
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: MC ON=0 
> MC_IP=0.0.0.0 MC_TTL=1
> # vi /usr/local/etc/trafficserver/icp.config (change something)
> # /usr/local/bin/traffic_ctl config reload
> # cat /usr/local/var/log/trafficserver/traffic.out
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
> traffic_server: using root directory '/usr/local'
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) On=2, MultiCast=0, 
> Timeout=1 LocalCacheLookup=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) StaleLookup=0, 
> ReplyToUnknowPeer=0, DefaultReplyPort=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: Type=L 
> IP=192.168.56.98:3130 PPort=0 Host=localhost
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [0]: MC ON=0 
> MC_IP=*Not IP address [0]* MC_TTL=0
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: Type=S 
> IP=192.168.56.22:3130 PPort=8080 Host=
> [Sep  1 08:19:59.681] Server {0x2af442a36040} DEBUG: (icp) [1]: MC ON=0 
> MC_IP=0.0.0.0 MC_TTL=1
> {noformat}
> It is caused that termination of the icp process function doesn't work.
> icp processor open socket for waiting query, and when finish the icp 
> processor,
> it sends a dummy queries towards the socket opened at 
> ICPProcessor::CancelPendingReads().
> {noformat}
> void
> ICPProcessor::CancelPendingReads()
> {
>   // Cancel pending ICP read by sending a bogus message to
>   //  the local ICP port.
>  
>   // ...snip... 
>   Peer *lp = GetLocalPeer();
>   r->_sendMsgHdr.msg_name = (caddr_t) & (lp->GetSendChan())->addr;
>   r->_sendMsgHdr.msg_namelen = sizeof((lp->GetSendChan())->addr);
>   udpNet.sendmsg_re(r, r, lp->GetSendFD(), >_sendMsgHdr);
> }
> {noformat}
> But this function's implemetation is broken because (lp->GetSendChan())->addr 
> is not contain
> local endpoint address, and it contains all 0. Therefore udpNet.sendmsg_re() 
> always fail.
> This problem is able to fix if only that set local endpoint address 
> appropriately.
> The patch that fix this issue is below(for currently master branch):
> {noformat}
> diff --git a/proxy/ICP.cc b/proxy/ICP.cc
> index 4f3c768..7eacebb 100644
> --- a/proxy/ICP.cc
> +++ b/proxy/ICP.cc
> @@ -2209,8 +2209,10 @@ ICPProcessor::CancelPendingReads()
>r->_ICPmsg.h.version = ~r->_ICPmsg.h.version; // bogus message
>  
>Peer *lp = GetLocalPeer();
> -  r->_sendMsgHdr.msg_name = (caddr_t) & (lp->GetSendChan())->addr;
> -  r->_sendMsgHdr.msg_namelen = sizeof((lp->GetSendChan())->addr);
> +  IpEndpoint local_endpoint;
> +  ats_ip_copy(_endpoint.sa, lp->GetIP());
> +  r->_sendMsgHdr.msg_name = (caddr_t) & local_endpoint;
> +  r->_sendMsgHdr.msg_namelen = sizeof(local_endpoint);
>udpNet.sendmsg_re(r, r, lp->GetSendFD(), >_sendMsgHdr);
>  }
>  
> {noformat}
> Testing configurations:
> {panel:title=records.config}
> #...
> CONFIG proxy.config.icp.enabled INT 2
> CONFIG proxy.config.icp.icp_interface STRING eth1
> CONFIG proxy.config.icp.icp_port INT 3130
> CONFIG proxy.config.icp.multicast_enabled INT 0
> CONFIG proxy.config.icp.query_timeout INT 1
> #...
> #output debugging messages for icp (minimal)
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING icp
> {panel}
> {panel:title=icp.config}
> :192.168.56.22:2:8080:3130:0:0.0.0.0:1:
> #:192.168.56.23:2:8080:3130:0:0.0.0.0:1:
> {panel}
> it works like 

[jira] [Commented] (TS-3585) Redirection does not do DNS if cache is disabled

2015-08-31 Thread Alan M. Carroll (JIRA)

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

Alan M. Carroll commented on TS-3585:
-

Fixed in commit 60ffbfda03997c018dac1d02118170c1eb1ecc1e.

> Redirection does not do DNS if cache is disabled
> 
>
> Key: TS-3585
> URL: https://issues.apache.org/jira/browse/TS-3585
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.2, 6.0.0
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>Priority: Minor
> Fix For: 6.0.0
>
>
> Disable cache by setting
> {code}
> CONFIG proxy.config.http.cache.http INT 0
> {code}
> Run ATS and do
> {code}
> curl --verbose --proxy localhost:8080 http://apache.org/index.html
> {code}
> This should work. Then try
> {code}
> curl --verbose --proxy localhost:8080 
> http://httpbin.org/redirect-to?http://apache.org/index.html
> {code}
> This will fail. If you trace it you will discover the problem is ATS uses the 
> IP address of {{httpbin.org}} for the redirect access to {{apache.org}}.



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