[jira] [Commented] (TS-4205) Plugin to allow nocache only for some ip-ranges

[Christoph K. (JIRA)]

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

Christoph K. commented on TS-4205:
--

Gonna try this next week and create a PR afterwards.

> Plugin to allow nocache only for some ip-ranges
> ---
>
> Key: TS-4205
> URL: https://issues.apache.org/jira/browse/TS-4205
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Christoph K.
>Priority: Minor
> Fix For: sometime
>
>
> Would be nice if there was an easy way to allow sending nocache for some 
> ip-ranges / addresses only and ignore all the others. Right now the only 
> option is to allow or none.



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

[jira] [Created] (TS-4415) Pagespeed module doesnt work properly as ATS plugin in forward Proxy mode

[KAPIL KUMAR (JIRA)]

KAPIL KUMAR created TS-4415:
---

 Summary: Pagespeed module doesnt work properly as ATS plugin in 
forward Proxy mode
 Key: TS-4415
 URL: https://issues.apache.org/jira/browse/TS-4415
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Reporter: KAPIL KUMAR


I want to use pagespeed as a plugin in the ATS forward proxy mode.

I can see ATS/plugins/experimental/ats_pagespeed. I followed the instructions :
->Build and install using make and make install.
->Added the plugin entry in plugin.conf
->Mentioned the cache/log files (with 777 permissions too)
->i can see plugin is being loaded when i start ATS.

But it doesnt seems to be working :(
for e.g, combine_css.html is still having 3 different CSS.

When i send Curl request,
curl -i http://local_server_ip/combine_css.html --proxy "ats_proxy_ip"

i see "x-page-speed 1.9.32.3-4488" only for the first time.
After second attempt, i dont see this header in response.

More details are being discussed one :
https://groups.google.com/forum/#!topic/mod-pagespeed-discuss/CL1PBCXGUM4



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3485:


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

https://github.com/apache/trafficserver/pull/614#discussion_r61987839
  
--- Diff: proxy/http2/Http2SessionAccept.cc ---
@@ -38,9 +39,22 @@ Http2SessionAccept::~Http2SessionAccept()
 void
 Http2SessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
IOBufferReader *reader)
 {
+  AclRecord *session_acl_record = NULL;
+  sockaddr const *client_ip = netvc->get_remote_addr();
+  IpAllow::scoped_config ipallow;
+  if (ipallow && (((session_acl_record = ipallow->match(client_ip)) == 
NULL) || (session_acl_record->isEmpty( {
+ip_port_text_buffer ipb;
+Warning("http2 client '%s' prohibited by ip-allow policy", 
ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
--- End diff --

Oh so this is fail-closed when there is no config? If that is the case, 
then HTTP/1 should do the same thing. We should have a single function that 
does this check for both protocols to avoid this kind of drift.


> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3485:


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

https://github.com/apache/trafficserver/pull/614#discussion_r61987763
  
--- Diff: proxy/http2/Http2SessionAccept.cc ---
@@ -38,9 +39,22 @@ Http2SessionAccept::~Http2SessionAccept()
 void
 Http2SessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
IOBufferReader *reader)
 {
+  AclRecord *session_acl_record = NULL;
+  sockaddr const *client_ip = netvc->get_remote_addr();
+  IpAllow::scoped_config ipallow;
+  if (ipallow && (((session_acl_record = ipallow->match(client_ip)) == 
NULL) || (session_acl_record->isEmpty( {
+ip_port_text_buffer ipb;
+Warning("http2 client '%s' prohibited by ip-allow policy", 
ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
+netvc->do_io_close();
+return;
+  } else if (!session_acl_record) {
--- End diff --

You would get here if ``ipallow`` is false ... that doesn't seem right?


> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3485:


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

https://github.com/apache/trafficserver/pull/614#discussion_r61987639
  
--- Diff: proxy/http2/Http2SessionAccept.cc ---
@@ -38,9 +39,22 @@ Http2SessionAccept::~Http2SessionAccept()
 void
 Http2SessionAccept::accept(NetVConnection *netvc, MIOBuffer *iobuf, 
IOBufferReader *reader)
 {
+  AclRecord *session_acl_record = NULL;
+  sockaddr const *client_ip = netvc->get_remote_addr();
+  IpAllow::scoped_config ipallow;
+  if (ipallow && (((session_acl_record = ipallow->match(client_ip)) == 
NULL) || (session_acl_record->isEmpty( {
+ip_port_text_buffer ipb;
+Warning("http2 client '%s' prohibited by ip-allow policy", 
ats_ip_ntop(client_ip, ipb, sizeof(ipb)));
--- End diff --

This is a user-visible message, so "HTTP/2" would be better.


> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3485:


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

https://github.com/apache/trafficserver/pull/614#discussion_r61987633
  
--- Diff: proxy/http2/Http2SessionAccept.cc ---
@@ -50,7 +64,7 @@ Http2SessionAccept::accept(NetVConnection *netvc, 
MIOBuffer *iobuf, IOBufferRead
 
   // XXX Allocate a Http2ClientSession
--- End diff --

Looks like this "XXX" is done now?


> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3485:


GitHub user shinrich opened a pull request:

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

TS-3485: Support ip_allow config for HTTP2

Actually enforce the ip-level ACL checks for HTTP2 and move to the accept 
logic to make the decision before creating the session object.

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

$ git pull https://github.com/shinrich/trafficserver ts-3485

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

https://github.com/apache/trafficserver/pull/614.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #614


commit adbec07a85f43c482797237e538c820b67dd1a4c
Author: Susan Hinrichs 
Date:   2016-05-04T01:49:30Z

TS-3485: Support ip_allow config for HTTP2




> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3485:


You are right.  I placed the logic in Http2ClientSession::new_connection 
because that is were I was running into permission problems.  But it makes more 
sense to make the IP level check in the Accept object before the session object 
is created.  I'm testing the change now and will issue a PR assuming that works 
out.

The ACL logic is still split because the non-IP checks are performed in 
HttpTransact.

> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Reopened] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reopened TS-3485:


> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

Jenkins build is back to normal : centos_7-master » gcc,centos_7,debug #1652

[jenkins]

See 

Build failed in Jenkins: clang-analyzer #2231

[jenkins]

See 

Changes:

[shinrich] TS-3485: Remove Warning message about ip-allow enforcement not being

--
[...truncated 2857 lines...]
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 60%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 61%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 63%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReadVIOGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReenable.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnShutdown.en
reading sources... [ 67%] 
developer-guide/api/functions/TSVConnSslConnectionGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnTunnel.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWrite.en
reading sources... 

Build failed in Jenkins: clang-analyzer #2230

[jenkins]

See 

Changes:

[shinrich] TS-4180: Support for multiple intermediate cert chains if openssl 
1.0.2

--
[...truncated 2857 lines...]
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 60%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 61%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 63%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReadVIOGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReenable.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnShutdown.en
reading sources... [ 67%] 
developer-guide/api/functions/TSVConnSslConnectionGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnTunnel.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWrite.en
reading sources

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

[jenkins]

See 


--
[...truncated 3576 lines...]
libtool: link: /bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/server-transform.exp" > ".libs/server-transform.expT"
libtool: link: mv -f ".libs/secure-link.expT" ".libs/secure-link.exp"
libtool: link:  echo "local: *; };" >> .libs/response-header-1.ver
libtool: link:  cc -shared  -fPIC -DPIC  
response-header-1/.libs/response-header-1.o   -lcap -lpcre -lz -lcrypt 
-lpthread -ldl -lxml2  -mcx16   -Wl,-soname -Wl,response-header-1.so 
-Wl,-version-script -Wl,.libs/response-header-1.ver -o 
.libs/response-header-1.so
libtool: link: mv -f ".libs/server-transform.expT" ".libs/server-transform.exp"
libtool: link: echo "{ global:" > .libs/secure-link.ver
libtool: link:  cat .libs/secure-link.exp | sed -e "s/\(.*\)/\1;/" >> 
.libs/secure-link.ver
libtool: link: echo "{ global:" > .libs/server-transform.ver
libtool: link:  cat .libs/server-transform.exp | sed -e "s/\(.*\)/\1;/" >> 
.libs/server-transform.ver
libtool: link:  echo "local: *; };" >> .libs/secure-link.ver
libtool: link:  cc -shared  -fPIC -DPIC  secure-link/.libs/secure-link.o   
-lcap -lpcre -lz -lcrypt -lpthread -ldl -lxml2  -mcx16   -Wl,-soname 
-Wl,secure-link.so -Wl,-version-script -Wl,.libs/secure-link.ver -o 
.libs/secure-link.so
libtool: link:  echo "local: *; };" >> .libs/server-transform.ver
libtool: link:  cc -shared  -fPIC -DPIC  
server-transform/.libs/server-transform.o   -lcap -lpcre -lz -lcrypt -lpthread 
-ldl -lxml2  -mcx16   -Wl,-soname -Wl,server-transform.so -Wl,-version-script 
-Wl,.libs/server-transform.ver -o .libs/server-transform.so
libtool: link: ( cd ".libs" && rm -f "secure-link.la" && ln -s 
"../secure-link.la" "secure-link.la" )
/bin/bash ../libtool  --tag=CXX   --mode=link ccache c++  -std=c++11 -ggdb3 
-pipe -Wall -Werror -Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
  -o remap_header_add.la -rpath 

 remap_header_add/remap_header_add.lo  -lcap -lpcre -lz -lcrypt -lpthread -ldl  
-lxml2
libtool: link: ( cd ".libs" && rm -f "response-header-1.la" && ln -s 
"../response-header-1.la" "response-header-1.la" )
/bin/bash ../libtool  --tag=CXX   --mode=link ccache c++  -std=c++11 -ggdb3 
-pipe -Wall -Werror -Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
  -o ssl-sni.la -rpath 

 ssl-sni/ssl-sni.lo  -lcap -lpcre -lz -lcrypt -lpthread -ldl  -lxml2
libtool: link: ( cd ".libs" && rm -f "server-transform.la" && ln -s 
"../server-transform.la" "server-transform.la" )
/bin/bash ../libtool  --tag=CXX   --mode=link ccache c++  -std=c++11 -ggdb3 
-pipe -Wall -Werror -Wno-invalid-offsetof -mcx16 -module -shared -avoid-version 
-export-symbols-regex 
'^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$'
  -o ssl-sni-whitelist.la -rpath 

 ssl-sni-whitelist/ssl-sni-whitelist.lo  -lcap -lpcre -lz -lcrypt -lpthread 
-ldl  -lxml2
libtool: link: /usr/bin/nm -B  ssl-preaccept/.libs/ssl-preaccept.o   | sed -n 
-e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed 
's/.* //' | sort | uniq > .libs/ssl-preaccept.exp
libtool: link: /bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/ssl-preaccept.exp" > ".libs/ssl-preaccept.expT"
libtool: link: mv -f ".libs/ssl-preaccept.expT" ".libs/ssl-preaccept.exp"
libtool: link: c++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o  
ssl-preaccept/.libs/ssl-preaccept.o   -lcap -lpcre -lz -lcrypt -lpthread -ldl 
-lxml2 -L/usr/lib/gcc/x86_64-linux-gnu/4.8 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o 
/usr/lib/gcc/x86

Build failed in Jenkins: ubuntu_12_04-master » gcc,ubuntu_12_04,release #1876

[jenkins]

See 


--
[...truncated 5128 lines...]
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/Store.cc: Cannot open: No such file or 
directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/CacheHttp.cc: Cannot open: No such file 
or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/CacheHosting.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/P_CacheVol.h: Cannot open: No such file 
or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/P_RamCache.h: Cannot open: No such file 
or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/Notes: Cannot open: No such file or 
directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/P_CacheDir.h: Cannot open: No such file 
or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/Makefile.in: Cannot open: No such file or 
directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/RamCacheCLFUS.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cache/CacheRead.cc: Cannot open: No such file 
or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/Makefile.in: Cannot open: No such file or 
directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterRPC.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterLib.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterHandler.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/test_P_Cluster.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterProcessor.cc: Cannot open: No 
such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/Inline.cc: Cannot open: No such file or 
directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_ClusterInline.h: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_ClusterCacheInternal.h: Cannot open: 
No such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_ClusterLib.h: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_ClusterLoadMonitor.h: Cannot open: No 
such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_TimeTrace.h: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterConfig.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_ClusterMachine.h: Cannot open: No 
such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterHandlerBase.cc: Cannot open: No 
such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_ClusterInternal.h: Cannot open: No 
such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterMachine.cc: Cannot open: No such 
file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/P_ClusterHandler.h: Cannot open: No 
such file or directory
tar: trafficserver-7.0.0: Cannot mkdir: No such file or directory
tar: trafficserver-7.0.0/iocore/cluster/ClusterHash.cc: Cannot ope

Build failed in Jenkins: ubuntu_12_04-master » gcc,ubuntu_12_04,debug #1876

[jenkins]

See 


--
[...truncated 4087 lines...]
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory 
`
Making check in traffic_manager
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory 
`
Making check in traffic_top
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory 
`
Making check in traffic_via
make[2]: Entering directory 
`
make  check-TESTS
make[3]: Entering directory 
`
make[4]: Entering directory 
`
PASS: test_traffic_via
make[5]: Entering directory 
`
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory 
`

Testsuite summary for Apache Traffic Server 7.0.0

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[4]: Leaving directory 
`
make[3]: Leaving directory 
`
make[2]: Leaving directory 
`
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check-am'.
make[2]: Leaving directory 
`
make[1]: Leaving directory 
`
Making check in plugins
make[1]: Entering directory 
`
Making check in cacheurl
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory 
`
Making check in conf_remap
make[2]: Entering directory 
`
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory 
`
Making check in gzip
make[2]: Entering directory 
`

[jira] [Comment Edited] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[James Peach (JIRA)]

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

James Peach edited comment on TS-3485 at 5/3/16 11:12 PM:
--

Why is the ACL on {{Http2ClientSession::new_connection}} for HTTP/2 but on 
{{HttpSessionAccept::accept}} for HTTP/1.1?

In the HTTP/2 case, it looks like the code warns but doesn't actually deny 
access?

Can we refactor this to that ACLs are checked in one place?


was (Author: jamespeach):
Why is the ACL on {[Http2ClientSession::new_connection}} for HTTP/2 but on 
{{HttpSessionAccept::accept}} for HTTP/1.1?

In the HTTP/2 case, it looks like the code warns but doesn't actually deny 
access?

Can we refactor this to that ACLs are checked in one place?

> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[James Peach (JIRA)]

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

James Peach commented on TS-3485:
-

Why is the ACL on {[Http2ClientSession::new_connection}} for HTTP/2 but on 
{{HttpSessionAccept::accept}} for HTTP/1.1?

In the HTTP/2 case, it looks like the code warns but doesn't actually deny 
access?

Can we refactor this to that ACLs are checked in one place?

> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

Build failed in Jenkins: centos_7-master » gcc,centos_7,debug #1651

[jenkins]

See 


--
[...truncated 17954 lines...]
0|0|31.239.15.0|31.239.15.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8295624502146446079|0|0|1|0
0|0|198.30.6.0|198.30.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16821743131905027583|0|0|1|0
0|0|160.133.4.0|160.133.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8878584891531470591|0|0|1|0
0|0|233.201.8.0|233.201.8.0|per_ip| |F|0|0|1970/01/01 
00:00:00|9363017653771039167|0|0|1|0
0|0|86.110.4.0|86.110.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|1888958975128722431|0|0|1|0
0|0|116.92.7.0|116.92.7.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16631009639014254015|0|0|1|0
0|0|144.237.10.0|144.237.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|12905853032977407679|0|0|1|0
0|0|103.150.5.0|103.150.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16572297681063508287|0|0|1|0
0|0|250.74.6.0|250.74.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3435544084056601407|0|0|1|0
0|0|33.228.1.0|33.228.1.0|per_ip| |F|0|0|1970/01/01 
00:00:00|7054485740756729087|0|0|1|0
0|0|5.119.12.0|5.119.12.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14495321938049529599|0|0|1|0
0|0|176.81.0.0|176.81.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11377479059831779583|0|0|1|0
0|0|156.11.6.0|156.11.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8234706063569537663|0|0|1|0
0|0|109.134.9.0|109.134.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14050053816847377407|0|0|1|0
0|0|140.42.10.0|140.42.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8162434488007175487|0|0|1|0
0|0|114.61.13.0|114.61.13.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3945992723180975743|0|0|1|0
0|0|33.100.6.0|33.100.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6825087806830268671|0|0|1|0
0|0|83.94.9.0|83.94.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3346846807966173951|0|0|1|0
0|0|145.111.0.0|145.111.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4310273191177806975|0|0|1|0
RPRINT Congestion_CongestionDB: There are 1048576 records in the db
RPRINT Congestion_CongestionDB: After test [1] there are 1024 records in the db
RPRINT Congestion_CongestionDB: After test [2] there are 2816 records in the db
RPRINT Congestion_CongestionDB: After test [3] there are 1048576 records in the 
db
REGRESSION_RESULT Congestion_CongestionDB:  PASSED
REGRESSION TEST Congestion_FailHistory started
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 2612 , sum = 2612
RPRINT Congestion_FailHistory: bucket 1 => events 3974 , sum = 6586
RPRINT Congestion_FailHistory: bucket 2 => events 4015 , sum = 10601
RPRINT Congestion_FailHistory: bucket 3 => events 3855 , sum = 14456
RPRINT Congestion_FailHistory: bucket 4 => events 4029 , sum = 18485
RPRINT Congestion_FailHistory: bucket 5 => events 4023 , sum = 22508
RPRINT Congestion_FailHistory: bucket 6 => events 3828 , sum = 26336
RPRINT Congestion_FailHistory: bucket 7 => events 3855 , sum = 30191
RPRINT Congestion_FailHistory: bucket 8 => events 3914 , sum = 34105
RPRINT Congestion_FailHistory: bucket 9 => events 3864 , sum = 37969
RPRINT Congestion_FailHistory: bucket 10 => events 3926 , sum = 41895
RPRINT Congestion_FailHistory: bucket 11 => events 4018 , sum = 45913
RPRINT Congestion_FailHistory: bucket 12 => events 3957 , sum = 49870
RPRINT Congestion_FailHistory: bucket 13 => events 3935 , sum = 53805
RPRINT Congestion_FailHistory: bucket 14 => events 3959 , sum = 57764
RPRINT Congestion_FailHistory: bucket 15 => events 3869 , sum = 61633
RPRINT Congestion_FailHistory: bucket 16 => events 3903 , sum = 65536
Events: 65536, CurIndex: 0, LastEvent: 299, HistLen: 306, BinLen: 18, Start: 0
RPRINT Congestion_FailHistory: 233|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:03:53|0|299|65536|1|0
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 961 , sum = 961
RPRINT Congestion_FailHistory: bucket 1 => events 978 , sum = 1939
RPRINT Congestion_FailHistory: bucket 2 => events 602 , sum = 2541
RPRINT Congestion_FailHistory: bucket 3 => events 1011 , sum = 3552
RPRINT Congestion_FailHistory: bucket 4 => events 956 , sum = 4508
RPRINT Congestion_FailHistory: bucket 5 => events 1019 , sum = 5527
RPRINT Congestion_FailHistory: bucket 6 => events 992 , sum = 6519
RPRINT Congestion_FailHistory: bucket 7 => events 969 , sum = 7488
RPRINT Congestion_FailHistory: bucket 8 => events 1009 , sum = 8497
RPRINT Congestion_FailHistory: bucket 9 => events 950 , sum = 9447
RPRINT Congestion_FailHistory: bucket 10 => events 976 , sum = 10423
RPRINT Congestion_FailHistory: bucket 11 => events 974 , sum = 11397
RPRINT Congestion_FailHistory: bucket 12 => events 1007 , sum = 12404
RPRINT Congestion_FailHistory: bucket 13 => events 955 , sum = 13359
RPRINT Congestion_FailHistory: bucket 14 => events 998 , sum = 14357
RPRINT Congestion_FailHistory: bucket 15 => events 983 , sum = 15340
RPRINT C

[jira] [Closed] (TS-4180) support for serving multiple intermediate cert chains

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs closed TS-4180.
--
Resolution: Fixed

> support for serving multiple intermediate cert chains
> -
>
> Key: TS-4180
> URL: https://issues.apache.org/jira/browse/TS-4180
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 7.0.0
>
>
> We would like to serve two different intermediate certificate chains for RSA 
> certs and ECDSA certs. Today they are required to be in the same chain. It 
> seems the best way would be to modify "ssl_ca_name" (or 
> proxy.config.ssl.CA.cert.path) to support a comma-delimited list of 
> intermediate files.
> Bonus points if ATS validates that the intermediate chain matches the cert 
> being served (and spits out an error if there is a mismatch)!



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

[jira] [Updated] (TS-4180) support for serving multiple intermediate cert chains

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-4180:
---
Backport to Version: 6.2.0
  Fix Version/s: (was: 6.2.0)
 7.0.0

> support for serving multiple intermediate cert chains
> -
>
> Key: TS-4180
> URL: https://issues.apache.org/jira/browse/TS-4180
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 7.0.0
>
>
> We would like to serve two different intermediate certificate chains for RSA 
> certs and ECDSA certs. Today they are required to be in the same chain. It 
> seems the best way would be to modify "ssl_ca_name" (or 
> proxy.config.ssl.CA.cert.path) to support a comma-delimited list of 
> intermediate files.
> Bonus points if ATS validates that the intermediate chain matches the cert 
> being served (and spits out an error if there is a mismatch)!



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

[jira] [Updated] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-3485:
---
Backport to Version: 6.2.0
  Fix Version/s: (was: 6.2.0)
 7.0.0

> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Closed] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs closed TS-3485.
--
Resolution: Fixed

> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 6.2.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Updated] (TS-4187) connections_currently_open stat not accurate with global server session pools

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-4187:
---
Backport to Version: 6.1.2, 6.2.0  (was: 6.1.2)
  Fix Version/s: (was: 6.2.0)
 7.0.0

> connections_currently_open stat not accurate with global server session pools
> -
>
> Key: TS-4187
> URL: https://issues.apache.org/jira/browse/TS-4187
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> When global server session pools are used, sockets may be moved to new VCs 
> associated with different threads.  The connections_currently_open stat was 
> not being correctly incremented in that case meaning the 
> connections_currently_open stat would go negative.
> This means that the connection throttling logic would likely not trigger. 



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

[jira] [Closed] (TS-4187) connections_currently_open stat not accurate with global server session pools

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs closed TS-4187.
--
Resolution: Fixed

> connections_currently_open stat not accurate with global server session pools
> -
>
> Key: TS-4187
> URL: https://issues.apache.org/jira/browse/TS-4187
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> When global server session pools are used, sockets may be moved to new VCs 
> associated with different threads.  The connections_currently_open stat was 
> not being correctly incremented in that case meaning the 
> connections_currently_open stat would go negative.
> This means that the connection throttling logic would likely not trigger. 



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

[jira] [Commented] (TS-3485) We should honor ip_allow.config ACLs for HTTP/2 streams

[ASF subversion and git services (JIRA)]

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

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

Commit 2dd1c4f02414f7639e6cddc580d26f1bc5f1502c in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2dd1c4f ]

TS-3485: Remove Warning message about ip-allow enforcement not being present 
for HTTP2.


> We should honor ip_allow.config ACLs for HTTP/2 streams
> ---
>
> Key: TS-3485
> URL: https://issues.apache.org/jira/browse/TS-3485
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 6.2.0
>
>
> From the comments:
> {code}
> // XXX we need to refactor the ACL checks from HttpSessionAccept so that we 
> can invoke them here, and also in
> // the SPDY protocol layer ...
> {code}



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

[jira] [Commented] (TS-4180) support for serving multiple intermediate cert chains

[ASF subversion and git services (JIRA)]

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

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

Commit dfd3c078ab3bd6cf110a026a55e833ffa332ff00 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=dfd3c07 ]

TS-4180: Support for multiple intermediate cert chains if openssl 1.0.2 is 
present.  This closes #578.


> support for serving multiple intermediate cert chains
> -
>
> Key: TS-4180
> URL: https://issues.apache.org/jira/browse/TS-4180
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We would like to serve two different intermediate certificate chains for RSA 
> certs and ECDSA certs. Today they are required to be in the same chain. It 
> seems the best way would be to modify "ssl_ca_name" (or 
> proxy.config.ssl.CA.cert.path) to support a comma-delimited list of 
> intermediate files.
> Bonus points if ATS validates that the intermediate chain matches the cert 
> being served (and spits out an error if there is a mismatch)!



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

[jira] [Commented] (TS-4180) support for serving multiple intermediate cert chains

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4180:


Github user asfgit closed the pull request at:

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


> support for serving multiple intermediate cert chains
> -
>
> Key: TS-4180
> URL: https://issues.apache.org/jira/browse/TS-4180
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We would like to serve two different intermediate certificate chains for RSA 
> certs and ECDSA certs. Today they are required to be in the same chain. It 
> seems the best way would be to modify "ssl_ca_name" (or 
> proxy.config.ssl.CA.cert.path) to support a comma-delimited list of 
> intermediate files.
> Bonus points if ATS validates that the intermediate chain matches the cert 
> being served (and spits out an error if there is a mismatch)!



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

Build failed in Jenkins: clang-analyzer #2229

[jenkins]

See 

Changes:

[shinrich] TS-4187: Keep the currently_open connections in sync with the number 
of

--
[...truncated 2857 lines...]
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 60%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 61%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 63%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReadVIOGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReenable.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnShutdown.en
reading sources... [ 67%] 
developer-guide/api/functions/TSVConnSslConnectionGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnTunnel.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWrite.en
reading sources

[jira] [Closed] (TS-4348) proxy.process.net.connections_currently_open does not match OS in terms of number of open connections

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs closed TS-4348.
--
Resolution: Duplicate

I ended up tracking the fix on TS-4187.

> proxy.process.net.connections_currently_open does not match OS in terms of 
> number of open connections
> -
>
> Key: TS-4348
> URL: https://issues.apache.org/jira/browse/TS-4348
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.2.0
>
>
> Testing master (proto 6.2) in production.  ATS eventually gets to throttled 
> mode and stays there.  
> The value of proxy.process.net.connections_currently_open is much greater 
> than the established value shown is "ss -s" (180K vs 40K).



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

[jira] [Commented] (TS-4187) connections_currently_open stat not accurate with global server session pools

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4187:


Github user asfgit closed the pull request at:

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


> connections_currently_open stat not accurate with global server session pools
> -
>
> Key: TS-4187
> URL: https://issues.apache.org/jira/browse/TS-4187
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.2.0
>
>
> When global server session pools are used, sockets may be moved to new VCs 
> associated with different threads.  The connections_currently_open stat was 
> not being correctly incremented in that case meaning the 
> connections_currently_open stat would go negative.
> This means that the connection throttling logic would likely not trigger. 



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

[jira] [Commented] (TS-4187) connections_currently_open stat not accurate with global server session pools

[ASF subversion and git services (JIRA)]

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

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

Commit 6f1119222126db29e508104f88782b2478972bdf in trafficserver's branch 
refs/heads/master from [~shinrich]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6f11192 ]

TS-4187: Keep the currently_open connections in sync with the number of sockets 
open. This closes #583.


> connections_currently_open stat not accurate with global server session pools
> -
>
> Key: TS-4187
> URL: https://issues.apache.org/jira/browse/TS-4187
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.2.0
>
>
> When global server session pools are used, sockets may be moved to new VCs 
> associated with different threads.  The connections_currently_open stat was 
> not being correctly incremented in that case meaning the 
> connections_currently_open stat would go negative.
> This means that the connection throttling logic would likely not trigger. 



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

[jira] [Commented] (TS-4180) support for serving multiple intermediate cert chains

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4180:


Github user shinrich commented on the pull request:

https://github.com/apache/trafficserver/pull/578#issuecomment-216679391
  
I'll plan on working with @jacksontj at the summit next week to get the 
TSQA and openssl version issue figured out.


> support for serving multiple intermediate cert chains
> -
>
> Key: TS-4180
> URL: https://issues.apache.org/jira/browse/TS-4180
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We would like to serve two different intermediate certificate chains for RSA 
> certs and ECDSA certs. Today they are required to be in the same chain. It 
> seems the best way would be to modify "ssl_ca_name" (or 
> proxy.config.ssl.CA.cert.path) to support a comma-delimited list of 
> intermediate files.
> Bonus points if ATS validates that the intermediate chain matches the cert 
> being served (and spits out an error if there is a mismatch)!



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

[jira] [Commented] (TS-4187) connections_currently_open stat not accurate with global server session pools

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4187:


Github user shinrich commented on the pull request:

https://github.com/apache/trafficserver/pull/583#issuecomment-216679006
  
I think you could do a TSQA test.  Configure with global pools.   Run a set 
of requests through.  Wait a while for things to drain out.  Verify that the 
current_open connection count is 0 or really close to 0.  I don't see how to do 
an integration test that would exercise this case.  


> connections_currently_open stat not accurate with global server session pools
> -
>
> Key: TS-4187
> URL: https://issues.apache.org/jira/browse/TS-4187
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.2.0
>
>
> When global server session pools are used, sockets may be moved to new VCs 
> associated with different threads.  The connections_currently_open stat was 
> not being correctly incremented in that case meaning the 
> connections_currently_open stat would go negative.
> This means that the connection throttling logic would likely not trigger. 



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

[jira] [Updated] (TS-4090) CID 1343359, 1343358: Coverity issues in new memcached plugin

[John Rushford (JIRA)]

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

John Rushford updated TS-4090:
--
Fix Version/s: (was: 6.2.0)

> CID 1343359, 1343358: Coverity issues in new memcached plugin
> -
>
> Key: TS-4090
> URL: https://issues.apache.org/jira/browse/TS-4090
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: John Rushford
>  Labels: coverity
> Fix For: 7.0.0
>
>
> Hi [~jplevyak],
> can you please take a look at this? I'm merging this new plugin into 6.1.x as 
> well, so it'd be great to have these fixed.
> {code}
> *** CID 1343359:(DEADCODE)
> /plugins/experimental/memcache/tsmemcache.cc: 483 in 
> MC::binary_get_event(int, void *)()
> 477   if (event != TSMEMCACHE_EVENT_GOT_ITEM) {
> 478 CHECK_READ_AVAIL(binary_header.request.keylen, &MC::binary_get);
> 479 key = binary_get_key(this);
> 480 header.nkey = binary_header.request.keylen;
> 481 return get_item();
> 482   } else if (event == CACHE_EVENT_OPEN_READ_FAILED) {
>CID 1343359:(DEADCODE)
>Execution cannot reach this statement: "if ((*this).f.noreply)
>  re...".
> 483 if (f.noreply)
> 484   return read_from_client();
> 485 if (binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETK) {
> 486   add_binary_header(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0, 
> header.nkey, header.nkey);
> 487   wbuf->write(key, header.nkey);
> 488   return write_then_read_from_client();
> /plugins/experimental/memcache/tsmemcache.cc: 492 in 
> MC::binary_get_event(int, void *)()
> 486   add_binary_header(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0, 
> header.nkey, header.nkey);
> 487   wbuf->write(key, header.nkey);
> 488   return write_then_read_from_client();
> 489 } else
> 490   return write_binary_error(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 
> 0);
> 491   } else if (event == CACHE_EVENT_OPEN_READ) {
>CID 1343359:(DEADCODE)
>Execution cannot reach this statement: "rsp = &this->res.get;".
> 492 protocol_binary_response_get *rsp = &res.get;
> 493 uint16_t keylen = 0;
> 494 uint32_t bodylen = sizeof(rsp->message.body) + 
> (rcache_header->nbytes - 2);
> 495 bool getk =
> 496   (binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETK || 
> binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETKQ);
> 497 if (getk) {
> ** CID 1343358:  Uninitialized members  (UNINIT_CTOR)
> /plugins/experimental/memcache/tsmemcache.h: 95 in MCAccept::MCAccept()()
> 
> *** CID 1343358:  Uninitialized members  (UNINIT_CTOR)
> /plugins/experimental/memcache/tsmemcache.h: 95 in MCAccept::MCAccept()()
> 89   MCAccept()
> 90 #ifndef HAVE_TLS
> 91 : theMCThreadAllocator(NULL)
> 92 #endif
> 93   {
> 94 SET_HANDLER(&MCAccept::main_event);
>CID 1343358:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "accept_port" is not initialized in this 
> constructor nor in any functions that it calls.
> 95   }
> 96 };
> 97 
> 98 #define TS_PUSH_HANDLER(_h)\
> 99   do { \
> 100 handler_stack[ihandler_stack++] = handler; \
> {code}



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

[jira] [Updated] (TS-4090) CID 1343359, 1343358: Coverity issues in new memcached plugin

[John Rushford (JIRA)]

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

John Rushford updated TS-4090:
--
Fix Version/s: 7.0.0

> CID 1343359, 1343358: Coverity issues in new memcached plugin
> -
>
> Key: TS-4090
> URL: https://issues.apache.org/jira/browse/TS-4090
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: John Rushford
>  Labels: coverity
> Fix For: 7.0.0
>
>
> Hi [~jplevyak],
> can you please take a look at this? I'm merging this new plugin into 6.1.x as 
> well, so it'd be great to have these fixed.
> {code}
> *** CID 1343359:(DEADCODE)
> /plugins/experimental/memcache/tsmemcache.cc: 483 in 
> MC::binary_get_event(int, void *)()
> 477   if (event != TSMEMCACHE_EVENT_GOT_ITEM) {
> 478 CHECK_READ_AVAIL(binary_header.request.keylen, &MC::binary_get);
> 479 key = binary_get_key(this);
> 480 header.nkey = binary_header.request.keylen;
> 481 return get_item();
> 482   } else if (event == CACHE_EVENT_OPEN_READ_FAILED) {
>CID 1343359:(DEADCODE)
>Execution cannot reach this statement: "if ((*this).f.noreply)
>  re...".
> 483 if (f.noreply)
> 484   return read_from_client();
> 485 if (binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETK) {
> 486   add_binary_header(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0, 
> header.nkey, header.nkey);
> 487   wbuf->write(key, header.nkey);
> 488   return write_then_read_from_client();
> /plugins/experimental/memcache/tsmemcache.cc: 492 in 
> MC::binary_get_event(int, void *)()
> 486   add_binary_header(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0, 
> header.nkey, header.nkey);
> 487   wbuf->write(key, header.nkey);
> 488   return write_then_read_from_client();
> 489 } else
> 490   return write_binary_error(PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 
> 0);
> 491   } else if (event == CACHE_EVENT_OPEN_READ) {
>CID 1343359:(DEADCODE)
>Execution cannot reach this statement: "rsp = &this->res.get;".
> 492 protocol_binary_response_get *rsp = &res.get;
> 493 uint16_t keylen = 0;
> 494 uint32_t bodylen = sizeof(rsp->message.body) + 
> (rcache_header->nbytes - 2);
> 495 bool getk =
> 496   (binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETK || 
> binary_header.request.opcode == PROTOCOL_BINARY_CMD_GETKQ);
> 497 if (getk) {
> ** CID 1343358:  Uninitialized members  (UNINIT_CTOR)
> /plugins/experimental/memcache/tsmemcache.h: 95 in MCAccept::MCAccept()()
> 
> *** CID 1343358:  Uninitialized members  (UNINIT_CTOR)
> /plugins/experimental/memcache/tsmemcache.h: 95 in MCAccept::MCAccept()()
> 89   MCAccept()
> 90 #ifndef HAVE_TLS
> 91 : theMCThreadAllocator(NULL)
> 92 #endif
> 93   {
> 94 SET_HANDLER(&MCAccept::main_event);
>CID 1343358:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "accept_port" is not initialized in this 
> constructor nor in any functions that it calls.
> 95   }
> 96 };
> 97 
> 98 #define TS_PUSH_HANDLER(_h)\
> 99   do { \
> 100 handler_stack[ihandler_stack++] = handler; \
> {code}



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

[jira] [Updated] (TS-4330) Real or statistical differences in response time between 5.3 and 6.1

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4330:

Fix Version/s: (was: 6.2.0)
   7.0.0

> Real or statistical differences in response time between 5.3 and 6.1
> 
>
> Key: TS-4330
> URL: https://issues.apache.org/jira/browse/TS-4330
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Performance
>Reporter: Susan Hinrichs
> Fix For: 7.0.0
>
>
> We are evaluating 6.1 in our production caching environment and verifying it 
> against a 5.3.x box in the same pod.
> Our performance reporter (ysar) shows that the response time for 6.1 is 
> higher than it is on the 5.3 box.  The difference is in the range of 10ms.
> We also noticed that the error statistics difference.  In 6.1 the reported 
> client aborts are higher.  Also the number of connection failures is low and 
> the number of "other" errors is higher.  In 5.3, the number of connection 
> failures is higher and the number of "other" errors is low.
> Finally, I set the slow log on both machines.  On the 6.1 machine, I see 
> every second or two an entry with ua_begin set to 0, all other fields set to 
> -1 except for sm_finish which is 120 seconds.  I do not see these slow logs 
> on the 5.3 machine.   It is as if the TCP deferred accept path is not being 
> used on the 6.1 build.
> We are continuing to investigate, but wanted to share in case others have 
> seem similar issues.



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

[jira] [Assigned] (TS-4348) proxy.process.net.connections_currently_open does not match OS in terms of number of open connections

[Phil Sorber (JIRA)]

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

Phil Sorber reassigned TS-4348:
---

Assignee: Susan Hinrichs

> proxy.process.net.connections_currently_open does not match OS in terms of 
> number of open connections
> -
>
> Key: TS-4348
> URL: https://issues.apache.org/jira/browse/TS-4348
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.2.0
>
>
> Testing master (proto 6.2) in production.  ATS eventually gets to throttled 
> mode and stays there.  
> The value of proxy.process.net.connections_currently_open is much greater 
> than the established value shown is "ss -s" (180K vs 40K).



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

[jira] [Commented] (TS-4406) The % log tag now always shows http/1.1

[ASF subversion and git services (JIRA)]

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

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

Commit 9f74372ceeecdb03bfd2315575c5edb10aa7f09a in trafficserver's branch 
refs/heads/6.2.x from [~shinrich]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9f74372 ]

TS-4406: Fix % tag. This closes #610.

(cherry picked from commit 2e12b62b6e5af184ee507bc11746d991a61d8642)


> The % log tag now always shows http/1.1
> -
>
> Key: TS-4406
> URL: https://issues.apache.org/jira/browse/TS-4406
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 6.2.0, 7.0.0
>
>
> As of commitaf76977adb9f3c0296a2 (TS-3612) , the % log now always shows 
> http/1.1. Whereas before, it would show http/2 if the session negotiated H2. 
> Assuming this isn't intentional (cause if it is, it should be moved out to 
> 7.0.0), this is is a blocker for 6.2.0 release IMO.



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

[jira] [Updated] (TS-4406) The % log tag now always shows http/1.1

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4406:

Backport to Version:   (was: 6.2.0)

> The % log tag now always shows http/1.1
> -
>
> Key: TS-4406
> URL: https://issues.apache.org/jira/browse/TS-4406
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 6.2.0, 7.0.0
>
>
> As of commitaf76977adb9f3c0296a2 (TS-3612) , the % log now always shows 
> http/1.1. Whereas before, it would show http/2 if the session negotiated H2. 
> Assuming this isn't intentional (cause if it is, it should be moved out to 
> 7.0.0), this is is a blocker for 6.2.0 release IMO.



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

[jira] [Updated] (TS-4406) The % log tag now always shows http/1.1

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4406:

Fix Version/s: 6.2.0

> The % log tag now always shows http/1.1
> -
>
> Key: TS-4406
> URL: https://issues.apache.org/jira/browse/TS-4406
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 6.2.0, 7.0.0
>
>
> As of commitaf76977adb9f3c0296a2 (TS-3612) , the % log now always shows 
> http/1.1. Whereas before, it would show http/2 if the session negotiated H2. 
> Assuming this isn't intentional (cause if it is, it should be moved out to 
> 7.0.0), this is is a blocker for 6.2.0 release IMO.



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

[jira] [Resolved] (TS-4406) The % log tag now always shows http/1.1

[Phil Sorber (JIRA)]

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

Phil Sorber resolved TS-4406.
-
Resolution: Fixed

> The % log tag now always shows http/1.1
> -
>
> Key: TS-4406
> URL: https://issues.apache.org/jira/browse/TS-4406
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.0.0
>
>
> As of commitaf76977adb9f3c0296a2 (TS-3612) , the % log now always shows 
> http/1.1. Whereas before, it would show http/2 if the session negotiated H2. 
> Assuming this isn't intentional (cause if it is, it should be moved out to 
> 7.0.0), this is is a blocker for 6.2.0 release IMO.



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

[jira] [Updated] (TS-4359) Deprecate the SPDY protocol

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4359:
--
Fix Version/s: (was: 6.2.0)
   7.0.0

> Deprecate the SPDY protocol
> ---
>
> Key: TS-4359
> URL: https://issues.apache.org/jira/browse/TS-4359
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
> Fix For: 7.0.0
>
>
> In preparation of the SPDY removal in v7.0.0 (TS-4311) we should mark SPDY as 
> deprecated in both documentation and configure script.



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

[jira] [Updated] (TS-4235) Deprecate fuzzy cache revalidation ?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4235:
--
Fix Version/s: (was: 6.2.0)
   7.0.0

> Deprecate fuzzy cache revalidation ?
> 
>
> Key: TS-4235
> URL: https://issues.apache.org/jira/browse/TS-4235
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I'm starting this as a discussion here. I think there are good reasons to 
> deprecate (for now) and later remove the fuzz logic. These configs are 
> currently in place:
> {code}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT, 
> "0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> The reason for eliminating these are:
> 1) They are difficult to setup correctly, particularly if you have a mix of 
> various cache TTL on objects.
> 2) Currently, they have next to no value, since you lock out all other 
> readers from the object anyways. So you are likely to benefit / use this only 
> for objects which are infrequently accessed.
> 3) With the new proxy.config.http.cache.open_write_fail_action it's possible 
> that #2 improves, but in that case, I'd argue that if you allow it to serve 
> stale, you are better off letting it expire and not "prematurely" revalidate 
> the object.
> 4) It seems to cause confusing behavior as it is today (with default 
> settings), e.g. anything with less than 240s TTL is likely to trip up and 
> prematurely expire long before intended (this is why we added the 
> proxy.config.http.cache.fuzz.min_time option, but it's disabled by default, 
> and makes configuration even more complicated).
> So what does everyone think? Is anyone actually using and relying on the fuzz 
> logic? It feels better to spend some time on adding more features to the 
> fail_action feature.



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

[jira] [Updated] (TS-4235) Deprecate fuzzy cache revalidation ?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4235:
--
Backport to Version: 6.2.0

> Deprecate fuzzy cache revalidation ?
> 
>
> Key: TS-4235
> URL: https://issues.apache.org/jira/browse/TS-4235
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I'm starting this as a discussion here. I think there are good reasons to 
> deprecate (for now) and later remove the fuzz logic. These configs are 
> currently in place:
> {code}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.time", RECD_INT, "240", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.min_time", RECD_INT, "0", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>   {RECT_CONFIG, "proxy.config.http.cache.fuzz.probability", RECD_FLOAT, 
> "0.005", RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> The reason for eliminating these are:
> 1) They are difficult to setup correctly, particularly if you have a mix of 
> various cache TTL on objects.
> 2) Currently, they have next to no value, since you lock out all other 
> readers from the object anyways. So you are likely to benefit / use this only 
> for objects which are infrequently accessed.
> 3) With the new proxy.config.http.cache.open_write_fail_action it's possible 
> that #2 improves, but in that case, I'd argue that if you allow it to serve 
> stale, you are better off letting it expire and not "prematurely" revalidate 
> the object.
> 4) It seems to cause confusing behavior as it is today (with default 
> settings), e.g. anything with less than 240s TTL is likely to trip up and 
> prematurely expire long before intended (this is why we added the 
> proxy.config.http.cache.fuzz.min_time option, but it's disabled by default, 
> and makes configuration even more complicated).
> So what does everyone think? Is anyone actually using and relying on the fuzz 
> logic? It feels better to spend some time on adding more features to the 
> fail_action feature.



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

[jira] [Updated] (TS-4359) Deprecate the SPDY protocol

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4359:
--
Backport to Version: 6.2.0

> Deprecate the SPDY protocol
> ---
>
> Key: TS-4359
> URL: https://issues.apache.org/jira/browse/TS-4359
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>Priority: Blocker
> Fix For: 7.0.0
>
>
> In preparation of the SPDY removal in v7.0.0 (TS-4311) we should mark SPDY as 
> deprecated in both documentation and configure script.



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

[jira] [Updated] (TS-4397) Build on i386 fails due to lua_Integer type mismatch in traffic_manager metrics

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4397:

Backport to Version:   (was: 6.2.0)

> Build on i386 fails due to lua_Integer type mismatch in traffic_manager 
> metrics
> ---
>
> Key: TS-4397
> URL: https://issues.apache.org/jira/browse/TS-4397
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Felix Buenemann
>Assignee: Leif Hedstrom
> Fix For: 6.2.0, 7.0.0
>
>
> Currently building master at 4c3fe2aac5e6b45839238b4ae207dff798939e61 fails, 
> because a call to bind_constant in metrics.cc uses int64_t type casting 
> instead of the correct lua_Integer type.
> This causes the following compile error on i386:
>  {noformat}
> metrics.cc: In function ‘bool metrics_binding_initialize(BindingInstance&)’:
> metrics.cc:339:58: error: call of overloaded ‘bind_constant(const char [20], 
> int64_t)’ is ambiguous
>binding.bind_constant("metrics.update.pass", int64_t(0));
>   ^
> metrics.cc:339:58: note: candidates are:
> In file included from metrics.cc:29:0:
> ../../lib/bindings/bindings.h:44:8: note: bool 
> BindingInstance::bind_constant(const char*, lua_Integer)
>bool bind_constant(const char *name, lua_Integer value);
> ^
> ../../lib/bindings/bindings.h:45:8: note: bool 
> BindingInstance::bind_constant(const char*, const char*)
>bool bind_constant(const char *name, const char *value);
> ^
> {noformat}
> I have identified the problem and will provide a pull request on GitHub. 
> Update: PR GH-607



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

[jira] [Updated] (TS-4397) Build on i386 fails due to lua_Integer type mismatch in traffic_manager metrics

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4397:

Fix Version/s: 6.2.0

> Build on i386 fails due to lua_Integer type mismatch in traffic_manager 
> metrics
> ---
>
> Key: TS-4397
> URL: https://issues.apache.org/jira/browse/TS-4397
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Felix Buenemann
>Assignee: Leif Hedstrom
> Fix For: 6.2.0, 7.0.0
>
>
> Currently building master at 4c3fe2aac5e6b45839238b4ae207dff798939e61 fails, 
> because a call to bind_constant in metrics.cc uses int64_t type casting 
> instead of the correct lua_Integer type.
> This causes the following compile error on i386:
>  {noformat}
> metrics.cc: In function ‘bool metrics_binding_initialize(BindingInstance&)’:
> metrics.cc:339:58: error: call of overloaded ‘bind_constant(const char [20], 
> int64_t)’ is ambiguous
>binding.bind_constant("metrics.update.pass", int64_t(0));
>   ^
> metrics.cc:339:58: note: candidates are:
> In file included from metrics.cc:29:0:
> ../../lib/bindings/bindings.h:44:8: note: bool 
> BindingInstance::bind_constant(const char*, lua_Integer)
>bool bind_constant(const char *name, lua_Integer value);
> ^
> ../../lib/bindings/bindings.h:45:8: note: bool 
> BindingInstance::bind_constant(const char*, const char*)
>bool bind_constant(const char *name, const char *value);
> ^
> {noformat}
> I have identified the problem and will provide a pull request on GitHub. 
> Update: PR GH-607



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

[jira] [Commented] (TS-4397) Build on i386 fails due to lua_Integer type mismatch in traffic_manager metrics

[Felix Buenemann (JIRA)]

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

Felix Buenemann commented on TS-4397:
-

Yes

> Build on i386 fails due to lua_Integer type mismatch in traffic_manager 
> metrics
> ---
>
> Key: TS-4397
> URL: https://issues.apache.org/jira/browse/TS-4397
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Felix Buenemann
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Currently building master at 4c3fe2aac5e6b45839238b4ae207dff798939e61 fails, 
> because a call to bind_constant in metrics.cc uses int64_t type casting 
> instead of the correct lua_Integer type.
> This causes the following compile error on i386:
>  {noformat}
> metrics.cc: In function ‘bool metrics_binding_initialize(BindingInstance&)’:
> metrics.cc:339:58: error: call of overloaded ‘bind_constant(const char [20], 
> int64_t)’ is ambiguous
>binding.bind_constant("metrics.update.pass", int64_t(0));
>   ^
> metrics.cc:339:58: note: candidates are:
> In file included from metrics.cc:29:0:
> ../../lib/bindings/bindings.h:44:8: note: bool 
> BindingInstance::bind_constant(const char*, lua_Integer)
>bool bind_constant(const char *name, lua_Integer value);
> ^
> ../../lib/bindings/bindings.h:45:8: note: bool 
> BindingInstance::bind_constant(const char*, const char*)
>bool bind_constant(const char *name, const char *value);
> ^
> {noformat}
> I have identified the problem and will provide a pull request on GitHub. 
> Update: PR GH-607



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

[jira] [Commented] (TS-4397) Build on i386 fails due to lua_Integer type mismatch in traffic_manager metrics

[Phil Sorber (JIRA)]

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

Phil Sorber commented on TS-4397:
-

https://github.com/apache/trafficserver/commit/81c395beb7ebd47c458e799927cac4414c8b5378

Is this the commit to backport?

> Build on i386 fails due to lua_Integer type mismatch in traffic_manager 
> metrics
> ---
>
> Key: TS-4397
> URL: https://issues.apache.org/jira/browse/TS-4397
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Felix Buenemann
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Currently building master at 4c3fe2aac5e6b45839238b4ae207dff798939e61 fails, 
> because a call to bind_constant in metrics.cc uses int64_t type casting 
> instead of the correct lua_Integer type.
> This causes the following compile error on i386:
>  {noformat}
> metrics.cc: In function ‘bool metrics_binding_initialize(BindingInstance&)’:
> metrics.cc:339:58: error: call of overloaded ‘bind_constant(const char [20], 
> int64_t)’ is ambiguous
>binding.bind_constant("metrics.update.pass", int64_t(0));
>   ^
> metrics.cc:339:58: note: candidates are:
> In file included from metrics.cc:29:0:
> ../../lib/bindings/bindings.h:44:8: note: bool 
> BindingInstance::bind_constant(const char*, lua_Integer)
>bool bind_constant(const char *name, lua_Integer value);
> ^
> ../../lib/bindings/bindings.h:45:8: note: bool 
> BindingInstance::bind_constant(const char*, const char*)
>bool bind_constant(const char *name, const char *value);
> ^
> {noformat}
> I have identified the problem and will provide a pull request on GitHub. 
> Update: PR GH-607



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

[jira] [Commented] (TS-4403) HostDB's "stale while revalidate" doesn't span failed DNS lookups

[ASF subversion and git services (JIRA)]

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

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

Commit af91bf80d8a6ca1a85056c1ff960f8848b7dfac3 in trafficserver's branch 
refs/heads/6.2.x from [~jacksontj]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=af91bf8 ]

TS-4403: Fix stale-while-revalidate on DNS lookup failures (#609)

HostDB's "stale-while-revalidate" feature allows hostdb to return stale records 
while doing the DNS lookup in the background. This works properly in the case 
where the resolver goes away, but in the case that an error was returned from 
the resolver the record in cache was thrown away. This means that a transient 
error out in the DNS infrastructure would cause ATS to drop its stale record it 
would have contently served-- this patch simply makes hostdb honor its 
stale-while-revalidate contract (if configured). So, in the event that the DNS 
result comes back as `failed` hostdb will keep the old one if it is okay with 
being served stale.

This closes #609
(cherry picked from commit 131875cbe7b0975c8c3c4f3d20aa55a5c7caba86)


> HostDB's "stale while revalidate" doesn't span failed DNS lookups
> -
>
> Key: TS-4403
> URL: https://issues.apache.org/jira/browse/TS-4403
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>  Labels: review
> Fix For: 6.2.0, 7.0.0
>
>
> Right now if you set stale_while_revalidate hostdb will return the stale 
> record while waiting on the DNS lookup. In the event that you have the DNS 
> timeout set low (lets say 1 second) and the DNS server times out (lets say 
> due to an outage of your resolver) then ATS will start replacing all of your 
> stale entries (which were working) with error timeout entries (which are 
> empty)-- which is bad.
> The stale while revalidate configuration should serve stale records until a 
> valid response from DNS comes back-- the patch here should be relatively 
> simple, just a bit of a nuisance to test since DNS requires port 53 ;)



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

[jira] [Updated] (TS-4403) HostDB's "stale while revalidate" doesn't span failed DNS lookups

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4403:

Backport to Version: 5.3.3, 6.1.2  (was: 5.3.3, 6.1.2, 6.2.0)

> HostDB's "stale while revalidate" doesn't span failed DNS lookups
> -
>
> Key: TS-4403
> URL: https://issues.apache.org/jira/browse/TS-4403
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>  Labels: review
> Fix For: 6.2.0, 7.0.0
>
>
> Right now if you set stale_while_revalidate hostdb will return the stale 
> record while waiting on the DNS lookup. In the event that you have the DNS 
> timeout set low (lets say 1 second) and the DNS server times out (lets say 
> due to an outage of your resolver) then ATS will start replacing all of your 
> stale entries (which were working) with error timeout entries (which are 
> empty)-- which is bad.
> The stale while revalidate configuration should serve stale records until a 
> valid response from DNS comes back-- the patch here should be relatively 
> simple, just a bit of a nuisance to test since DNS requires port 53 ;)



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

[jira] [Updated] (TS-4403) HostDB's "stale while revalidate" doesn't span failed DNS lookups

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4403:

Fix Version/s: 6.2.0

> HostDB's "stale while revalidate" doesn't span failed DNS lookups
> -
>
> Key: TS-4403
> URL: https://issues.apache.org/jira/browse/TS-4403
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>  Labels: review
> Fix For: 6.2.0, 7.0.0
>
>
> Right now if you set stale_while_revalidate hostdb will return the stale 
> record while waiting on the DNS lookup. In the event that you have the DNS 
> timeout set low (lets say 1 second) and the DNS server times out (lets say 
> due to an outage of your resolver) then ATS will start replacing all of your 
> stale entries (which were working) with error timeout entries (which are 
> empty)-- which is bad.
> The stale while revalidate configuration should serve stale records until a 
> valid response from DNS comes back-- the patch here should be relatively 
> simple, just a bit of a nuisance to test since DNS requires port 53 ;)



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

[jira] [Updated] (TS-3123) Make proxy.config.http.transaction_active_timeout_in overridable

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-3123:

Backport to Version: 6.2.0

> Make proxy.config.http.transaction_active_timeout_in overridable
> 
>
> Key: TS-3123
> URL: https://issues.apache.org/jira/browse/TS-3123
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 7.0.0
>
>
> This also requires moving the setup to a slightly later state in the HttpSM.



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

[jira] [Commented] (TS-3123) Make proxy.config.http.transaction_active_timeout_in overridable

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3123:
---

I have a somewhat better patch for this, which does indeed work, and also 
retains backwards compatibility.

> Make proxy.config.http.transaction_active_timeout_in overridable
> 
>
> Key: TS-3123
> URL: https://issues.apache.org/jira/browse/TS-3123
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 7.0.0
>
>
> This also requires moving the setup to a slightly later state in the HttpSM.



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

[jira] [Commented] (TS-4205) Plugin to allow nocache only for some ip-ranges

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4205:
---

Definitely, can you write something and create a PR for it?

Also, I filed a Jira on adding a better IP matcher for header_rewrite. It'd be 
convenient to be able to express things like 192.168/16 (TS-4414).

> Plugin to allow nocache only for some ip-ranges
> ---
>
> Key: TS-4205
> URL: https://issues.apache.org/jira/browse/TS-4205
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Christoph K.
>Priority: Minor
> Fix For: sometime
>
>
> Would be nice if there was an easy way to allow sending nocache for some 
> ip-ranges / addresses only and ignore all the others. Right now the only 
> option is to allow or none.



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

[jira] [Updated] (TS-4414) header_rewrite: implement an IP range matcher

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4414:
--
Fix Version/s: sometime

> header_rewrite: implement an IP range matcher
> -
>
> Key: TS-4414
> URL: https://issues.apache.org/jira/browse/TS-4414
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> It'd be useful sometimes to have a way to match the client IP against a range 
> of IPs, such as 192.168/16.



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

[jira] [Created] (TS-4414) header_rewrite: implement an IP range matcher

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4414:
-

 Summary: header_rewrite: implement an IP range matcher
 Key: TS-4414
 URL: https://issues.apache.org/jira/browse/TS-4414
 Project: Traffic Server
  Issue Type: New Feature
  Components: Plugins
Reporter: Leif Hedstrom


It'd be useful sometimes to have a way to match the client IP against a range 
of IPs, such as 192.168/16.



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

[jira] [Commented] (TS-4413) Fix potential consistent hash iterator race.

[John Rushford (JIRA)]

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

John Rushford commented on TS-4413:
---

The consistent hash functions lookup(), lookup_available(), and 
lookup_by_hashval() take an iterator pointer as an argument and modify this 
iterator as part of the search through the map.  The state of this iterator 
needs to be kept in the HttpTransaction state so that nextParent() if called 
works correctly.  I saw a segmentation fault when under heavy load while the 
hash table was being search for parents.  Currently there is only one iterator 
per ParentConsistentHash instance.  There needs to be an iterator per 
HttpTransaction for correct lookups into the hash table.

> Fix potential consistent hash iterator race.
> 
>
> Key: TS-4413
> URL: https://issues.apache.org/jira/browse/TS-4413
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>
> There is a potential race with the iterators used in parent consistent hash 
> lookups.  PR follows.



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

[jira] [Commented] (TS-4413) Fix potential consistent hash iterator race.

[James Peach (JIRA)]

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

James Peach commented on TS-4413:
-

Please let's have some context here. What is the race? How was it discovered? 
What is the fix? Why does this patch fix the race? Is there test coverage that 
hits this code path? Could there be?

> Fix potential consistent hash iterator race.
> 
>
> Key: TS-4413
> URL: https://issues.apache.org/jira/browse/TS-4413
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>
> There is a potential race with the iterators used in parent consistent hash 
> lookups.  PR follows.



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

[jira] [Commented] (TS-4413) Fix potential consistent hash iterator race.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4413:


GitHub user jrushford opened a pull request:

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

TS-4413: Fix potential consistent hash iterator race.

Fixes a potential consistent hash iterator race.

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

$ git pull https://github.com/jrushford/trafficserver ts4413

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

https://github.com/apache/trafficserver/pull/613.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #613


commit d01dc00218566e3e41b504de41a655cb80cf423b
Author: John J. Rushford 
Date:   2016-05-03T15:05:28Z

TS-4413: Fix potential consistent hash iterator race.




> Fix potential consistent hash iterator race.
> 
>
> Key: TS-4413
> URL: https://issues.apache.org/jira/browse/TS-4413
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>
> There is a potential race with the iterators used in parent consistent hash 
> lookups.  PR follows.



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

[jira] [Comment Edited] (TS-4399) management API breaks diagnostic log rotation

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll edited comment on TS-4399 at 5/3/16 3:53 PM:
-

It looks like there is potentially a deeper bug although it's hard to be sure. 
{{traffic_manager}} has a command line argument {{--tsArgs}} which is a set of 
arguments to be passed on to {{traffic_server}}. The command {{traffic_line 
-U}} seems to ignore this as well and only use the values in the configuration 
file. This seems like it's a bug but I don't see anyway in the normal path of 
things to take advantage of {{--tsArgs}} in the first place.


was (Author: amc):
It looks like there is potentially a deeper bug although it's hard to be sure. 
`traffic_manager` has a command line argument `tsArgs` which is a set of 
arguments to be passed on to `traffic_server`. The command `traffic_line -U` 
seems to ignore this as well and only use the values in the configuration file. 
This seems like it's a bug but I don't see anyway in the normal path of things 
to take advantage of `tsArgs`` in the first place.

> management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging, Management API
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1   0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950   0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager 
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951   0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server 
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1   0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950   0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager 
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951   0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server 
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.



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

[jira] [Comment Edited] (TS-4399) management API breaks diagnostic log rotation

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll edited comment on TS-4399 at 5/3/16 3:52 PM:
-

It looks like there is potentially a deeper bug although it's hard to be sure. 
`traffic_manager` has a command line argument `tsArgs` which is a set of 
arguments to be passed on to `traffic_server`. The command `traffic_line -U` 
seems to ignore this as well and only use the values in the configuration file. 
This seems like it's a bug but I don't see anyway in the normal path of things 
to take advantage of `tsArgs`` in the first place.


was (Author: amc):
It looks like there is potentially a deeper bug although it's hard to be sure. 
`traffic_manager` has a command line argument `--tsArgs` which is a set of 
arguments to be passed on to `traffic_server`. The command `traffic_line -U` 
seems to ignore this as well and only use the values in the configuration file. 
This seems like it's a bug but I don't see anyway in the normal path of things 
to take advantage of `--tsArgs`` in the first place.

> management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging, Management API
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1   0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950   0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager 
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951   0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server 
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1   0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950   0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager 
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr 
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951   0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server 
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.



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

[jira] [Assigned] (TS-4413) Fix potential consistent hash iterator race.

[John Rushford (JIRA)]

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

John Rushford reassigned TS-4413:
-

Assignee: John Rushford

> Fix potential consistent hash iterator race.
> 
>
> Key: TS-4413
> URL: https://issues.apache.org/jira/browse/TS-4413
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: John Rushford
>Assignee: John Rushford
>
> There is a potential race with the iterators used in parent consistent hash 
> lookups.  PR follows.



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

[jira] [Created] (TS-4413) Fix potential consistent hash iterator race.

[John Rushford (JIRA)]

John Rushford created TS-4413:
-

 Summary: Fix potential consistent hash iterator race.
 Key: TS-4413
 URL: https://issues.apache.org/jira/browse/TS-4413
 Project: Traffic Server
  Issue Type: Bug
  Components: Parent Proxy
Reporter: John Rushford


There is a potential race with the iterators used in parent consistent hash 
lookups.  PR follows.



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

[jira] [Commented] (TS-4395) conf_purge: Simple plugin to purge an entire remap rule

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4395:
---

Pending internal review.

> conf_purge: Simple plugin to purge an entire remap rule
> ---
>
> Key: TS-4395
> URL: https://issues.apache.org/jira/browse/TS-4395
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> This is similar to the existing plugin to purge based on a genID stored in a 
> persistent storage. The difference is that the purging is done exclusively 
> via a restful API, and has little (no) overhead on performance (since the 
> generation ID is always in memory).
> Example:
> {code}
> map http://example.com/p1  http://p1.example.com
> @plugin=remap_purge.so @pparam=--path=__secret_purge__  
> @pparam=--state=example_p1
> {code}
> And to purge:
> {code}
> $ curl -s -D - -X PURGE http://example.com/p1/__secret_purge__
> HTTP/1.1 200 OK
> Date: Sat, 30 Apr 2016 00:09:34 GMT
> Connection: close
> Server: ATS/7.0.0
> Content-Length: 39
> Content-Type: text/html
> PURGED http://example.com/p1
> {code}



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

[jira] [Created] (TS-4412) event overwrited by SSL_READ_READY / COMPLETE in ssl_read_from_net

[Oknet Xu (JIRA)]

Oknet Xu created TS-4412:


 Summary: event overwrited by SSL_READ_READY / COMPLETE in 
ssl_read_from_net
 Key: TS-4412
 URL: https://issues.apache.org/jira/browse/TS-4412
 Project: Traffic Server
  Issue Type: Bug
  Components: SSL
Reporter: Oknet Xu


the {{ssl_read_from_net}} read data from socket and saved into MIOBuffer.

It was designed to fill the MIOBuffer as much as possible, even execeed the VIO 
{{nbytes}} setting.

It will try to call {{SSLReadBuffer}} again and again until the MIOBuffer is 
full or an error returned from {{SSLReadBuffer}}. The {{event}} will be set to 
a error status if an error returned from {{SSLReadBuffer}}.

But at the end of {{ssl_read_from_net}}, the {{event}} will be overwrited to 
SSL_READ_READY or SSL_READ_COMPLETE depend on {{vio.ntodo()}} if this is one 
success at least in {{SSLReadBuffer}} before an error.

For example:
The {{SSLNetVConnection::net_read_io}} could not get SSL_READ_EOS from 
{{ssl_read_from_net}} and can not close the SSLNetVConnection immediately. 
Because The {{event}} SSL_READ_EOS is overwrited.
The SSLNetVConnection will be closed by timeout.



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

Build failed in Jenkins: clang-analyzer #2228

[jenkins]

See 

--
[...truncated 2852 lines...]
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 60%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 61%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 63%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 65%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReadVIOGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReenable.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnShutdown.en
reading sources... [ 67%] 
developer-guide/api/functions/TSVConnSslConnectionGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnTunnel.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWrite.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWriteVIOGet.en
reading sources... [ 68%] developer-gui

[jira] [Resolved] (TS-4240) ATS Server Continuous crash！ HELP

[Kit Chan (JIRA)]

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

Kit Chan resolved TS-4240.
--
Resolution: Fixed

> ATS Server  Continuous crash！  HELP
> ---
>
> Key: TS-4240
> URL: https://issues.apache.org/jira/browse/TS-4240
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: gehaijiang
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ATS version  5.3.2
> 1.   traffic.out  log info:
> traffic_server: Segmentation fault (Address not mapped to object 
> [0x2b5c39408625])traffic_server - STACK TRACE:
> /usr/local/ts/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac0a9]
> /lib64/libc.so.6[0x346fc326a0]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib5Utils15parseAttributesEPKciRSt4listINS_9AttributeESaIS4_EES2_+0x14e)[0x2b5b3d9ffc0e]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib9Variables17_parseQueryStringEPKci+0x1be)[0x2b5b3da0233e]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZNK6EsiLib9Variables8getValueERKSs+0x26d)[0x2b5b3da0463d]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib10Expression6expandEPKci+0x168)[0x2b5b3d9fcf48]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN12EsiProcessor11_preprocessERN6EsiLib11DocNodeListERi+0x543)[0x2b5b3d9f7cf3]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN12EsiProcessor12addParseDataEPKci+0x67)[0x2b5b3d9f8dc7]
> /usr/local/ts/libexec/trafficserver/esi.so(+0xf815)[0x2b5b3d9e7815]
> /usr/local/ts/libexec/trafficserver/esi.so(+0x10990)[0x2b5b3d9e8990]
> /usr/local/ts/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x755fd5]
> /usr/local/ts/bin/traffic_server(_ZN7EThread7executeEv+0x65b)[0x756aab]
> /usr/local/ts/bin/traffic_server[0x75541a]
> /lib64/libpthread.so.0[0x34700079d1]
> /lib64/libc.so.6(clone+0x6d)[0x346fce88fd]
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local/ts'
> traffic_server: using root directory '/usr/local/ts'
>  2.   dmesg 信息
> [ET_NET 6][35494]: segfault at 2adcc3925586 ip 2adbccdf9c0e sp 
> 2adbc3925570 error 4 in esi.so[2adbccdd2000+39000]
> [ET_NET 6][49844]: segfault at 2af3bd810589 ip 2af2c2c0ec0e sp 
> 2af2bd810570 error 4 in esi.so[2af2c2be7000+39000]
> [ET_NET 0][159607] trap stack segment ip:2ae6cdc00c0e sp:738a96b0 error:0
> [ET_NET 5][175340]: segfault at 2b3336c7b651 ip 2b32403f4c0e sp 
> 2b3236c7b610 error 4 in esi.so[2b32403cd000+39000]
> [ET_NET 0][181385] trap stack segment ip:2b733e305c0e sp:7fff67c782d0 error:0
> [ET_NET 13][188636]: segfault at 2ad025609654 ip 2acf29c00c0e sp 
> 2acf25609610 error 4 in esi.so[2acf29bd9000+39000]
> [ET_NET 17][195066]: segfault at 2b5a63320588 ip 2b5967113c0e sp 
> 2b5963320570 error 4 in esi.so[2b59670ec000+39000]
> [ET_NET 16][199937]: segfault at 2b0bc200e62d ip 2b0ac6002c0e sp 
> 2b0ac200e610 error 4 in esi.so[2b0ac5fdb000+39000]
> [ET_NET 14][204128]: segfault at 2ac1f773c65f ip 2ac0fbb32c0e sp 
> 2ac0f773c610 error 4 in esi.so[2ac0fbb0b000+39000]
> [ET_NET 7][221859]: segfault at 2b9ce3ef5620 ip 2b9bed1fbc0e sp 
> 2b9be3ef5610 error 4 in esi.so[2b9bed1d4000+39000]
> [ET_NET 9][223854]: segfault at 2ad846a1f629 ip 2ad74b81ac0e sp 
> 2ad746a1f610 error 4 in esi.so[2ad74b7f3000+39000]
> [ET_NET 12][232585]: segfault at 2b1fe3f3762d ip 2b1eec7f6c0e sp 
> 2b1ee3f37610 error 4 in esi.so[2b1eec7cf000+39000]
> [ET_NET 22][17116]: segfault at 2b98e751d583 ip 2b97ea90bc0e sp 
> 2b97e751d570 error 4 in esi.so[2b97ea8e4000+39000]
> [ET_NET 13][21971]: segfault at 2b5c39408625 ip 2b5b3d9ffc0e sp 
> 2b5b39408610 error 4 in esi.so[2b5b3d9d8000+39000]
> 3.  plugin.config
> esi.so
> cacheurl.so
> 4.  core dump file
> Program terminated with signal 11, Segmentation fault.
> #0  0x2b8340c7fc0e in EsiLib::Utils::parseAttributes (data= optimized out>, data_len=, attr_list= out>,
> pair_separators=) at lib/Utils.cc:161
> 161   } else if (separator_lookup[static_cast(data[i])] && 
> !inside_quotes) {
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.12-1.149.el6_6.5.x86_64 hwloc-1.5-1.el6.x86_64 
> keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 
> libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 
> libcom_err-1.41.12-18.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 
> libselinux-2.0.94-5.3.el6_4.1.x86_64 libstdc++-4.4.7-4.el6.x86_64 
> libxml2-2.7.6-14.el6.x86_64 mogujie-zlib-1.2.7-1.x86_64 
> nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 
> numactl-2.0.7-8.el6.x86_64 openssl-1.0.1e-16.el6_5.7.x86_64 
> pciutils-libs-3.1.10-2.el6.x86_64 pcre-mogujie-8.31-1.x86_64 
> tcl-8.5.7-6.el6.x86_64
> (gdb) bt
> #0  0x2b8340c7fc0e in EsiLib::Utils::parseAttributes (data= optimized out>, data_len=, attr_list= out>,
> pair_separators=) a

[jira] [Updated] (TS-4240) ATS Server Continuous crash！ HELP

[Kit Chan (JIRA)]

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

Kit Chan updated TS-4240:
-
Fix Version/s: (was: 6.2.0)
   7.0.0

> ATS Server  Continuous crash！  HELP
> ---
>
> Key: TS-4240
> URL: https://issues.apache.org/jira/browse/TS-4240
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: gehaijiang
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ATS version  5.3.2
> 1.   traffic.out  log info:
> traffic_server: Segmentation fault (Address not mapped to object 
> [0x2b5c39408625])traffic_server - STACK TRACE:
> /usr/local/ts/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac0a9]
> /lib64/libc.so.6[0x346fc326a0]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib5Utils15parseAttributesEPKciRSt4listINS_9AttributeESaIS4_EES2_+0x14e)[0x2b5b3d9ffc0e]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib9Variables17_parseQueryStringEPKci+0x1be)[0x2b5b3da0233e]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZNK6EsiLib9Variables8getValueERKSs+0x26d)[0x2b5b3da0463d]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib10Expression6expandEPKci+0x168)[0x2b5b3d9fcf48]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN12EsiProcessor11_preprocessERN6EsiLib11DocNodeListERi+0x543)[0x2b5b3d9f7cf3]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN12EsiProcessor12addParseDataEPKci+0x67)[0x2b5b3d9f8dc7]
> /usr/local/ts/libexec/trafficserver/esi.so(+0xf815)[0x2b5b3d9e7815]
> /usr/local/ts/libexec/trafficserver/esi.so(+0x10990)[0x2b5b3d9e8990]
> /usr/local/ts/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x755fd5]
> /usr/local/ts/bin/traffic_server(_ZN7EThread7executeEv+0x65b)[0x756aab]
> /usr/local/ts/bin/traffic_server[0x75541a]
> /lib64/libpthread.so.0[0x34700079d1]
> /lib64/libc.so.6(clone+0x6d)[0x346fce88fd]
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local/ts'
> traffic_server: using root directory '/usr/local/ts'
>  2.   dmesg 信息
> [ET_NET 6][35494]: segfault at 2adcc3925586 ip 2adbccdf9c0e sp 
> 2adbc3925570 error 4 in esi.so[2adbccdd2000+39000]
> [ET_NET 6][49844]: segfault at 2af3bd810589 ip 2af2c2c0ec0e sp 
> 2af2bd810570 error 4 in esi.so[2af2c2be7000+39000]
> [ET_NET 0][159607] trap stack segment ip:2ae6cdc00c0e sp:738a96b0 error:0
> [ET_NET 5][175340]: segfault at 2b3336c7b651 ip 2b32403f4c0e sp 
> 2b3236c7b610 error 4 in esi.so[2b32403cd000+39000]
> [ET_NET 0][181385] trap stack segment ip:2b733e305c0e sp:7fff67c782d0 error:0
> [ET_NET 13][188636]: segfault at 2ad025609654 ip 2acf29c00c0e sp 
> 2acf25609610 error 4 in esi.so[2acf29bd9000+39000]
> [ET_NET 17][195066]: segfault at 2b5a63320588 ip 2b5967113c0e sp 
> 2b5963320570 error 4 in esi.so[2b59670ec000+39000]
> [ET_NET 16][199937]: segfault at 2b0bc200e62d ip 2b0ac6002c0e sp 
> 2b0ac200e610 error 4 in esi.so[2b0ac5fdb000+39000]
> [ET_NET 14][204128]: segfault at 2ac1f773c65f ip 2ac0fbb32c0e sp 
> 2ac0f773c610 error 4 in esi.so[2ac0fbb0b000+39000]
> [ET_NET 7][221859]: segfault at 2b9ce3ef5620 ip 2b9bed1fbc0e sp 
> 2b9be3ef5610 error 4 in esi.so[2b9bed1d4000+39000]
> [ET_NET 9][223854]: segfault at 2ad846a1f629 ip 2ad74b81ac0e sp 
> 2ad746a1f610 error 4 in esi.so[2ad74b7f3000+39000]
> [ET_NET 12][232585]: segfault at 2b1fe3f3762d ip 2b1eec7f6c0e sp 
> 2b1ee3f37610 error 4 in esi.so[2b1eec7cf000+39000]
> [ET_NET 22][17116]: segfault at 2b98e751d583 ip 2b97ea90bc0e sp 
> 2b97e751d570 error 4 in esi.so[2b97ea8e4000+39000]
> [ET_NET 13][21971]: segfault at 2b5c39408625 ip 2b5b3d9ffc0e sp 
> 2b5b39408610 error 4 in esi.so[2b5b3d9d8000+39000]
> 3.  plugin.config
> esi.so
> cacheurl.so
> 4.  core dump file
> Program terminated with signal 11, Segmentation fault.
> #0  0x2b8340c7fc0e in EsiLib::Utils::parseAttributes (data= optimized out>, data_len=, attr_list= out>,
> pair_separators=) at lib/Utils.cc:161
> 161   } else if (separator_lookup[static_cast(data[i])] && 
> !inside_quotes) {
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.12-1.149.el6_6.5.x86_64 hwloc-1.5-1.el6.x86_64 
> keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 
> libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 
> libcom_err-1.41.12-18.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 
> libselinux-2.0.94-5.3.el6_4.1.x86_64 libstdc++-4.4.7-4.el6.x86_64 
> libxml2-2.7.6-14.el6.x86_64 mogujie-zlib-1.2.7-1.x86_64 
> nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 
> numactl-2.0.7-8.el6.x86_64 openssl-1.0.1e-16.el6_5.7.x86_64 
> pciutils-libs-3.1.10-2.el6.x86_64 pcre-mogujie-8.31-1.x86_64 
> tcl-8.5.7-6.el6.x86_64
> (gdb) bt
> #0  0x2b8340c7fc0e in EsiLib::Utils::parseAttributes (data= optimized out>, data_len=, attr_

[jira] [Work started] (TS-4240) ATS Server Continuous crash！ HELP

[Kit Chan (JIRA)]

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

Work on TS-4240 started by Kit Chan.

> ATS Server  Continuous crash！  HELP
> ---
>
> Key: TS-4240
> URL: https://issues.apache.org/jira/browse/TS-4240
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: gehaijiang
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>
> ATS version  5.3.2
> 1.   traffic.out  log info:
> traffic_server: Segmentation fault (Address not mapped to object 
> [0x2b5c39408625])traffic_server - STACK TRACE:
> /usr/local/ts/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4ac0a9]
> /lib64/libc.so.6[0x346fc326a0]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib5Utils15parseAttributesEPKciRSt4listINS_9AttributeESaIS4_EES2_+0x14e)[0x2b5b3d9ffc0e]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib9Variables17_parseQueryStringEPKci+0x1be)[0x2b5b3da0233e]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZNK6EsiLib9Variables8getValueERKSs+0x26d)[0x2b5b3da0463d]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN6EsiLib10Expression6expandEPKci+0x168)[0x2b5b3d9fcf48]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN12EsiProcessor11_preprocessERN6EsiLib11DocNodeListERi+0x543)[0x2b5b3d9f7cf3]
> /usr/local/ts/libexec/trafficserver/esi.so(_ZN12EsiProcessor12addParseDataEPKci+0x67)[0x2b5b3d9f8dc7]
> /usr/local/ts/libexec/trafficserver/esi.so(+0xf815)[0x2b5b3d9e7815]
> /usr/local/ts/libexec/trafficserver/esi.so(+0x10990)[0x2b5b3d9e8990]
> /usr/local/ts/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x125)[0x755fd5]
> /usr/local/ts/bin/traffic_server(_ZN7EThread7executeEv+0x65b)[0x756aab]
> /usr/local/ts/bin/traffic_server[0x75541a]
> /lib64/libpthread.so.0[0x34700079d1]
> /lib64/libc.so.6(clone+0x6d)[0x346fce88fd]
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local/ts'
> traffic_server: using root directory '/usr/local/ts'
>  2.   dmesg 信息
> [ET_NET 6][35494]: segfault at 2adcc3925586 ip 2adbccdf9c0e sp 
> 2adbc3925570 error 4 in esi.so[2adbccdd2000+39000]
> [ET_NET 6][49844]: segfault at 2af3bd810589 ip 2af2c2c0ec0e sp 
> 2af2bd810570 error 4 in esi.so[2af2c2be7000+39000]
> [ET_NET 0][159607] trap stack segment ip:2ae6cdc00c0e sp:738a96b0 error:0
> [ET_NET 5][175340]: segfault at 2b3336c7b651 ip 2b32403f4c0e sp 
> 2b3236c7b610 error 4 in esi.so[2b32403cd000+39000]
> [ET_NET 0][181385] trap stack segment ip:2b733e305c0e sp:7fff67c782d0 error:0
> [ET_NET 13][188636]: segfault at 2ad025609654 ip 2acf29c00c0e sp 
> 2acf25609610 error 4 in esi.so[2acf29bd9000+39000]
> [ET_NET 17][195066]: segfault at 2b5a63320588 ip 2b5967113c0e sp 
> 2b5963320570 error 4 in esi.so[2b59670ec000+39000]
> [ET_NET 16][199937]: segfault at 2b0bc200e62d ip 2b0ac6002c0e sp 
> 2b0ac200e610 error 4 in esi.so[2b0ac5fdb000+39000]
> [ET_NET 14][204128]: segfault at 2ac1f773c65f ip 2ac0fbb32c0e sp 
> 2ac0f773c610 error 4 in esi.so[2ac0fbb0b000+39000]
> [ET_NET 7][221859]: segfault at 2b9ce3ef5620 ip 2b9bed1fbc0e sp 
> 2b9be3ef5610 error 4 in esi.so[2b9bed1d4000+39000]
> [ET_NET 9][223854]: segfault at 2ad846a1f629 ip 2ad74b81ac0e sp 
> 2ad746a1f610 error 4 in esi.so[2ad74b7f3000+39000]
> [ET_NET 12][232585]: segfault at 2b1fe3f3762d ip 2b1eec7f6c0e sp 
> 2b1ee3f37610 error 4 in esi.so[2b1eec7cf000+39000]
> [ET_NET 22][17116]: segfault at 2b98e751d583 ip 2b97ea90bc0e sp 
> 2b97e751d570 error 4 in esi.so[2b97ea8e4000+39000]
> [ET_NET 13][21971]: segfault at 2b5c39408625 ip 2b5b3d9ffc0e sp 
> 2b5b39408610 error 4 in esi.so[2b5b3d9d8000+39000]
> 3.  plugin.config
> esi.so
> cacheurl.so
> 4.  core dump file
> Program terminated with signal 11, Segmentation fault.
> #0  0x2b8340c7fc0e in EsiLib::Utils::parseAttributes (data= optimized out>, data_len=, attr_list= out>,
> pair_separators=) at lib/Utils.cc:161
> 161   } else if (separator_lookup[static_cast(data[i])] && 
> !inside_quotes) {
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.12-1.149.el6_6.5.x86_64 hwloc-1.5-1.el6.x86_64 
> keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 
> libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 
> libcom_err-1.41.12-18.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 
> libselinux-2.0.94-5.3.el6_4.1.x86_64 libstdc++-4.4.7-4.el6.x86_64 
> libxml2-2.7.6-14.el6.x86_64 mogujie-zlib-1.2.7-1.x86_64 
> nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 
> numactl-2.0.7-8.el6.x86_64 openssl-1.0.1e-16.el6_5.7.x86_64 
> pciutils-libs-3.1.10-2.el6.x86_64 pcre-mogujie-8.31-1.x86_64 
> tcl-8.5.7-6.el6.x86_64
> (gdb) bt
> #0  0x2b8340c7fc0e in EsiLib::Utils::parseAttributes (data= optimized out>, data_len=, attr_list= out>,
> pair_separators=) at l