[GitHub] trafficserver pull request #861: TS-4360 Renames NPN_ defines to ALPN_

[zwoop]

Github user zwoop closed the pull request at:

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


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

[jira] [Work logged] (TS-4360) Rename public APIs / interfaces for ALPN (instead of NPN)

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Rename public APIs / interfaces for ALPN (instead of NPN)
> -
>
> Key: TS-4360
> URL: https://issues.apache.org/jira/browse/TS-4360
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: incompatible
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> For example, we have:
> {code}
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_HTTP_0_9;
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_HTTP_1_0;
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_HTTP_1_1;
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_SPDY_1;
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_SPDY_2;
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_SPDY_3;
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_SPDY_3_1;
> lib/ts/apidefs.h.in:extern tsapi int TS_NPN_PROTOCOL_INDEX_HTTP_2_0;
> {code}
> Which likely doesn't make a lot of sense, since ALPN is the de-facto standard 
> now (and NPN is gone or going away).



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

Build failed in Jenkins: clang-analyzer #2541

[jenkins]

See 

Changes:

[Leif Hedstrom] TS-2048 Avoids scheduling CFLUS compressor when not enabled

--
[...truncated 4963 lines...]
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNextDup.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldRemove.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 54%] 
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... [ 55%] 
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... [ 56%] 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... [ 57%] 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... [ 58%] 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... [ 59%] 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... [ 60%] 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... [ 61%] 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... [ 62%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 62%] 
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... [ 63%] 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... [ 64%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSUuidCreate.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... [ 66%] 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... 

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/823#discussion_r75058577
  
--- Diff: iocore/net/I_SessionAccept.h ---
@@ -29,12 +29,40 @@
 
 struct AclRecord;
 
+/**
+   The base class SessionAccept can not be used directly.
+   The inherited class of SessionAccept (ex. HttpSessionAccept) is 
designed to
+
+ - Check IPAllow policy
+ - Create ClientSession
+ - Pass NetVC and MIOBuffer by call ClientSession::new_connection()
+
+   NULL mutex:
+
+ - One specific protocol has ONLY one inherited class of SessionAccept.
+
+ - The object of this class is shared by all incoming request / NetVC 
that
+   identified as the protocol by ProtocolSessionProbe.
+
+ - The inherited class of SessionAccept is non-blocked to allow 
parellel accepts
+
+   To implement a inherited class of SessionAccept:
+
+ - No state is recorded by the handler
+
+ - Values are required to be set during construction and never changed
+
+ - Can not put into EventSystem.
+
+   So a NULL mutex is safe to continuation.
+*/
+
--- End diff --

@jpeach comments added, please review.


Issue Time Tracking
---

Worklog Id: (was: 26534)
Time Spent: 2.5h  (was: 2h 20m)

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



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

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

[oknet]

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

https://github.com/apache/trafficserver/pull/823#discussion_r75058577
  
--- Diff: iocore/net/I_SessionAccept.h ---
@@ -29,12 +29,40 @@
 
 struct AclRecord;
 
+/**
+   The base class SessionAccept can not be used directly.
+   The inherited class of SessionAccept (ex. HttpSessionAccept) is 
designed to
+
+ - Check IPAllow policy
+ - Create ClientSession
+ - Pass NetVC and MIOBuffer by call ClientSession::new_connection()
+
+   NULL mutex:
+
+ - One specific protocol has ONLY one inherited class of SessionAccept.
+
+ - The object of this class is shared by all incoming request / NetVC 
that
+   identified as the protocol by ProtocolSessionProbe.
+
+ - The inherited class of SessionAccept is non-blocked to allow 
parellel accepts
+
+   To implement a inherited class of SessionAccept:
+
+ - No state is recorded by the handler
+
+ - Values are required to be set during construction and never changed
+
+ - Can not put into EventSystem.
+
+   So a NULL mutex is safe to continuation.
+*/
+
--- End diff --

@jpeach comments added, please review.


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

[jira] [Work logged] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 17/Aug/16 03:39
Start Date: 17/Aug/16 03:39
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[GitHub] trafficserver pull request #867: TS-2048 Avoids scheduling CFLUS compressor ...

[zwoop]

Github user zwoop closed the pull request at:

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


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

[jira] [Updated] (TS-3832) test_marshall seg faults on ppc64

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3832:
---
Assignee: Eric Covener

> test_marshall seg faults on ppc64
> -
>
> Key: TS-3832
> URL: https://issues.apache.org/jira/browse/TS-3832
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Rafael Fonseca
>Assignee: Eric Covener
> Fix For: sometime
>
>
> 'make check' fails on ppc64 (big endian) with a segmentation fault.
> make  test_marshall
> make[3]: Entering directory 
> '/builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils'
> make[3]: 'test_marshall' is up to date.
> make[3]: Leaving directory 
> '/builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils'
> make  check-TESTS
> make[3]: Entering directory 
> '/builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils'
> make[4]: Entering directory 
> '/builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils'
> ../../build/aux/test-driver: line 107:  8630 Segmentation fault  (core 
> dumped) "$@" > $log_file 2>&1
> FAIL: test_marshall
> 
> Testsuite summary for Apache Traffic Server 5.3.0
> 
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See mgmt/utils/test-suite.log
> Please report to d...@trafficserver.apache.org
> 
> Makefile:1018: recipe for target 'test-suite.log' failed
> make[4]: *** [test-suite.log] Error 1
> make[4]: Leaving directory 
> '/builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils'
> Makefile:1124: recipe for target 'check-TESTS' failed
> make[3]: *** [check-TESTS] Error 2
> make[3]: Leaving directory 
> '/builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils'
> Makefile:1197: recipe for target 'check-am' failed
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory 
> '/builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils'
> Makefile:803: recipe for target 'check-recursive' failed
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory '/builddir/build/BUILD/trafficserver-5.3.0/mgmt'
> Makefile:671: recipe for target 'check-recursive' failed
> make: *** [check-recursive] Error 1
> Running gdb on the test:
> # gdb --args ./mgmt/utils/.libs/lt-test_marshall 
> (gdb) r
> Starting program: 
> /builddir/build/BUILD/trafficserver-5.3.0/mgmt/utils/.libs/lt-test_marshall 
> Missing separate debuginfos, use: dnf debuginfo-install 
> glibc-2.21-7.fc22.ppc64p7
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> REGRESSION_TEST initialization begun
> REGRESSION TEST MessageLength started
> REGRESSION_RESULT MessageLength:PASSED
> REGRESSION TEST MessageMarshall started
> RPRINT MessageMarshall: mgmt_message_parse(msgbuf, sizeof(msgbuf), sfields, 
> countof(sfields), ) returned length 4, expected 5
> Program received signal SIGSEGV, Segmentation fault.
> 0x2000434c in RegressionTest_MessageMarshall (t=, 
> pstatus=) at test_marshall.cc:251
> 251   CHECK_STRING(s, mstring);
> (gdb) p s
> $1 = 0x0
> (gdb) p mstring
> $2 = (MgmtMarshallString) 0x0
> Let me know if you need any further info.



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

[jira] [Updated] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3837:
---
Summary: The setting wait_for_cache waits indefinitely even when there are 
no cache disks configured  (was: The setting wait_for_cache waits indefinitely 
even when there are no cache disks configured.)

> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured
> ---
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Updated] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3837:

Fix Version/s: (was: 7.0.0)
   7.1.0

> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured.
> 
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Commented] (TS-3791) Diagnostics can crash in PCRE JIT when there's a bad config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3791:
---

The parent.config is also likely just a red-herring.

> Diagnostics can crash in PCRE JIT when there's a bad config 
> 
>
> Key: TS-3791
> URL: https://issues.apache.org/jira/browse/TS-3791
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
>  Labels: crash
> Fix For: 7.1.0
>
>
> Somewhat strange setup, but basically with a bad parent.config entry, e.g.
> {code}
> dest_domain=. parent="foo.example.com"
> {code}
> (notice the missing :port), and I run traffic_server with a -T option, e.g.
> {code}
> ./bin/traffic_server -T parent
> {code}
> I get a crash with a core of
> {code}
> (gdb) bt
> #0  0x752019c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x7520365a in __GI_abort () at abort.c:89
> #2  0x77bc3fb8 in ink_die_die_die () at 
> ../../../../lib/ts/ink_error.cc:43
> #3  ink_fatal_va (fmt=0x77bd0820 "ats_malloc: couldn't allocate %zu 
> bytes", ap=ap@entry=0x73994808) at ../../../../lib/ts/ink_error.cc:65
> #4  0x77bc404c in ink_fatal 
> (message_format=message_format@entry=0x77bd0820 "ats_malloc: couldn't 
> allocate %zu bytes") at ../../../../lib/ts/ink_error.cc:73
> #5  0x77bc6f16 in ats_malloc (size=32) at 
> ../../../../lib/ts/ink_memory.cc:56
> #6  0x76911694 in sljit_allocate_stack (allocator_data=0x0, 
> max_limit=1048576, limit=8192) at sljit/sljitUtils.c:236
> #7  pcre_jit_stack_alloc (startsize=8192, maxsize=, 
> maxsize@entry=1048576) at pcre_jit_compile.c:10571
> #8  0x77bbc656 in get_jit_stack (data=) at 
> ../../../../lib/ts/Regex.cc:44
> #9  0x76911358 in _pcre_jit_exec 
> (extra_data=extra_data@entry=0x10aa2d0, subject=subject@entry=0x80ac67 
> "pmgmt", length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=offsets@entry=0x73994be0, 
> offset_count=2) at pcre_jit_compile.c:10420
> #10 0x768e9e7e in pcre_exec (argument_re=0x10aa270, 
> extra_data=, subject=subject@entry=0x80ac67 "pmgmt", 
> length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=0x73994be0, offsetcount=30) at 
> pcre_exec.c:6483
> #11 0x77bbc79e in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5, 
> ovector=ovector@entry=0x73994be0, ovecsize=ovecsize@entry=30) at 
> ../../../../lib/ts/Regex.cc:120
> #12 0x77bbc7c5 in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5) at 
> ../../../../lib/ts/Regex.cc:112
> #13 0x77bbca1f in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=5) at ../../../../lib/ts/Regex.cc:235
> #14 0x77bbca67 in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt") at ../../../../lib/ts/Regex.cc:225
> #15 0x77bb0a32 in Diags::tag_activated (this=this@entry=0x10aa140, 
> tag=tag@entry=0x80ac67 "pmgmt", mode=mode@entry=DiagsTagType_Debug) at 
> ../../../../lib/ts/Diags.cc:394
> #16 0x77bb1429 in on (mode=DiagsTagType_Debug, tag=0x80ac67 "pmgmt", 
> this=0x10aa140) at ../../../../lib/ts/Diags.h:171
> #17 Diags::log (this=0x10aa140, tag=tag@entry=0x80ac67 "pmgmt", 
> level=level@entry=DL_Debug, file=file@entry=0x80a850 
> "../../../mgmt/ProcessManager.cc", func=func@entry=0x80acf0 
>  "processSignalQueue", 
> line=line@entry=148, format_string=0x80a8f8 "[ProcessManager] ==> Signalling 
> local manager '%d'\n") at ../../../../lib/ts/Diags.cc:513
> #18 0x006979f5 in ProcessManager::processSignalQueue (this=0x10eab30) 
> at ../../../mgmt/ProcessManager.cc:148
> #19 0x00697ffd in startProcessManager (arg=) at 
> ../../../mgmt/ProcessManager.cc:63
> #20 0x76039555 in start_thread (arg=0x73995700) at 
> pthread_create.c:333
> #21 0x752cfb9d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {code}



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

[jira] [Updated] (TS-3791) Diagnostics can crash in PCRE JIT when there's a bad config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3791:
--
Fix Version/s: (was: 7.0.0)
   7.1.0

> Diagnostics can crash in PCRE JIT when there's a bad config 
> 
>
> Key: TS-3791
> URL: https://issues.apache.org/jira/browse/TS-3791
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
>  Labels: crash
> Fix For: 7.1.0
>
>
> Somewhat strange setup, but basically with a bad parent.config entry, e.g.
> {code}
> dest_domain=. parent="foo.example.com"
> {code}
> (notice the missing :port), and I run traffic_server with a -T option, e.g.
> {code}
> ./bin/traffic_server -T parent
> {code}
> I get a crash with a core of
> {code}
> (gdb) bt
> #0  0x752019c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x7520365a in __GI_abort () at abort.c:89
> #2  0x77bc3fb8 in ink_die_die_die () at 
> ../../../../lib/ts/ink_error.cc:43
> #3  ink_fatal_va (fmt=0x77bd0820 "ats_malloc: couldn't allocate %zu 
> bytes", ap=ap@entry=0x73994808) at ../../../../lib/ts/ink_error.cc:65
> #4  0x77bc404c in ink_fatal 
> (message_format=message_format@entry=0x77bd0820 "ats_malloc: couldn't 
> allocate %zu bytes") at ../../../../lib/ts/ink_error.cc:73
> #5  0x77bc6f16 in ats_malloc (size=32) at 
> ../../../../lib/ts/ink_memory.cc:56
> #6  0x76911694 in sljit_allocate_stack (allocator_data=0x0, 
> max_limit=1048576, limit=8192) at sljit/sljitUtils.c:236
> #7  pcre_jit_stack_alloc (startsize=8192, maxsize=, 
> maxsize@entry=1048576) at pcre_jit_compile.c:10571
> #8  0x77bbc656 in get_jit_stack (data=) at 
> ../../../../lib/ts/Regex.cc:44
> #9  0x76911358 in _pcre_jit_exec 
> (extra_data=extra_data@entry=0x10aa2d0, subject=subject@entry=0x80ac67 
> "pmgmt", length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=offsets@entry=0x73994be0, 
> offset_count=2) at pcre_jit_compile.c:10420
> #10 0x768e9e7e in pcre_exec (argument_re=0x10aa270, 
> extra_data=, subject=subject@entry=0x80ac67 "pmgmt", 
> length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=0x73994be0, offsetcount=30) at 
> pcre_exec.c:6483
> #11 0x77bbc79e in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5, 
> ovector=ovector@entry=0x73994be0, ovecsize=ovecsize@entry=30) at 
> ../../../../lib/ts/Regex.cc:120
> #12 0x77bbc7c5 in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5) at 
> ../../../../lib/ts/Regex.cc:112
> #13 0x77bbca1f in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=5) at ../../../../lib/ts/Regex.cc:235
> #14 0x77bbca67 in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt") at ../../../../lib/ts/Regex.cc:225
> #15 0x77bb0a32 in Diags::tag_activated (this=this@entry=0x10aa140, 
> tag=tag@entry=0x80ac67 "pmgmt", mode=mode@entry=DiagsTagType_Debug) at 
> ../../../../lib/ts/Diags.cc:394
> #16 0x77bb1429 in on (mode=DiagsTagType_Debug, tag=0x80ac67 "pmgmt", 
> this=0x10aa140) at ../../../../lib/ts/Diags.h:171
> #17 Diags::log (this=0x10aa140, tag=tag@entry=0x80ac67 "pmgmt", 
> level=level@entry=DL_Debug, file=file@entry=0x80a850 
> "../../../mgmt/ProcessManager.cc", func=func@entry=0x80acf0 
>  "processSignalQueue", 
> line=line@entry=148, format_string=0x80a8f8 "[ProcessManager] ==> Signalling 
> local manager '%d'\n") at ../../../../lib/ts/Diags.cc:513
> #18 0x006979f5 in ProcessManager::processSignalQueue (this=0x10eab30) 
> at ../../../mgmt/ProcessManager.cc:148
> #19 0x00697ffd in startProcessManager (arg=) at 
> ../../../mgmt/ProcessManager.cc:63
> #20 0x76039555 in start_thread (arg=0x73995700) at 
> pthread_create.c:333
> #21 0x752cfb9d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {code}



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

[jira] [Updated] (TS-3758) Eliminate std::map from logging code

[James Peach (JIRA)]

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

James Peach updated TS-3758:

Summary: Eliminate std::map from logging code  (was: Elimiate std::map from 
logging code)

> Eliminate std::map from logging code
> 
>
> Key: TS-3758
> URL: https://issues.apache.org/jira/browse/TS-3758
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.2.0
>
>
> We introduce std::map in the logging code with TS-2150. We should replace 
> this.



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

[jira] [Updated] (TS-3785) List --command options in traffic_server usage information

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3785:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> List --command options in traffic_server usage information
> --
>
> Key: TS-3785
> URL: https://issues.apache.org/jira/browse/TS-3785
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 5.3.0
>Reporter: David Carlin
>Assignee: Alyssa Quek
>Priority: Minor
>  Labels: newbie, yahoo
> Fix For: 7.1.0
>
>
> Please update traffic_server --help (-h) output to show all the possible 
> options for the --command (-C) option.
> For example, there is currently no way to know -Cverify_config exists.



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

[jira] [Updated] (TS-3771) Cleanup ink_platform.h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3771:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Cleanup ink_platform.h
> --
>
> Key: TS-3771
> URL: https://issues.apache.org/jira/browse/TS-3771
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>
> There's a number of stuff that's unnecessary in this file, and similarly, 
> there are places that *should* use it, but instead do the platform dependent 
> includes directly.



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

[jira] [Updated] (TS-3770) ☂ Cleanup / remove unnecessary usage of STL

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3770:
---
Fix Version/s: (was: 7.0.0)
   sometime

> ☂ Cleanup  / remove unnecessary usage of STL
> 
>
> Key: TS-3770
> URL: https://issues.apache.org/jira/browse/TS-3770
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Other than in plugins and standalone apps (other than traffic_server), we've 
> long agreed to not use STL unless absolutely necessary. In particular, we 
> will never use STL on the critical path, but even in other areas we should 
> avoid it.
> I won't go into details here (e.g. memory management issues and code bloat). 
> This is an umbrella bug to keep track of all STL related Jira's.



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

[jira] [Updated] (TS-3768) Implement a tiered back-off in read-while-writer retries

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3768:
---
Summary: Implement a tiered back-off in read-while-writer retries  (was: 
Implement a tiered back-off in read-while-writer retries.)

> Implement a tiered back-off in read-while-writer retries
> 
>
> Key: TS-3768
> URL: https://issues.apache.org/jira/browse/TS-3768
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>
> There's some code in the current cache layer that attempts to do a tiered 
> back off in reattempting read-while-writer (either for acquiring writer lock 
> or waiting for the first fragment download etc), but, that code is buggy (see 
> below).
> https://github.com/apache/trafficserver/blob/master/iocore/cache/P_CacheInternal.h#L100
> {code}
> #define VC_SCHED_WRITER_RETRY()   \
>   do {\
> ink_assert(!trigger); \
> writer_lock_retry++;  \
> ink_hrtime _t = WRITER_RETRY_DELAY;   \
> if (writer_lock_retry > 2)\
>   _t = WRITER_RETRY_DELAY * 2;\
> else if (writer_lock_retry > 5)   \
>   _t = WRITER_RETRY_DELAY * 10;   \
> else if (writer_lock_retry > 10)  \
>   _t = WRITER_RETRY_DELAY * 100;  \
> trigger = mutex->thread_holding->schedule_in_local(this, _t); \
> return EVENT_CONT;\
>   } while (0)
> {code}
> Presently, the retry happens as follows: 
> {{WRITER_RETRY_DELAY, WRITER_RETRY_DELAY, 2*WRITER_RETRY_DELAY, 
> 2*WRITER_RETRY_DELAY, 2*WRITER_RETRY_DELAY etc}}
> I'm removing the buggy code with TS-3767 to avoid confusion, but, opening 
> this jira per [~zwoop]'s suggestion to implement a proper tiered back off in 
> the future.



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

[jira] [Closed] (TS-3763) Whole request and response headers are not available

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3763.
--
Resolution: Won't Fix

Please reopen with a pull request if you are willing to work on it.

> Whole request and response headers are not available
> 
>
> Key: TS-3763
> URL: https://issues.apache.org/jira/browse/TS-3763
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Jonh Wendell
>
> Currently it's possible to fetch a field within the header (request or 
> response). However it's not possible to access the whole header, as a big 
> string.
> I'm interested in the whole header, because I want not only the well known 
> fields, but all of them (in particular I'd like to know if clients send 
> unknown fields).
> For reference, Squid has these options as ">h" and "

[jira] [Updated] (TS-3763) Whole request and response headers are not available

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3763:
---
Assignee: (was: Bryan Call)

> Whole request and response headers are not available
> 
>
> Key: TS-3763
> URL: https://issues.apache.org/jira/browse/TS-3763
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Jonh Wendell
>
> Currently it's possible to fetch a field within the header (request or 
> response). However it's not possible to access the whole header, as a big 
> string.
> I'm interested in the whole header, because I want not only the well known 
> fields, but all of them (in particular I'd like to know if clients send 
> unknown fields).
> For reference, Squid has these options as ">h" and "

[jira] [Updated] (TS-3763) Whole request and response headers are not available

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3763:
---
Fix Version/s: (was: 7.0.0)

> Whole request and response headers are not available
> 
>
> Key: TS-3763
> URL: https://issues.apache.org/jira/browse/TS-3763
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Jonh Wendell
>Assignee: Bryan Call
>
> Currently it's possible to fetch a field within the header (request or 
> response). However it's not possible to access the whole header, as a big 
> string.
> I'm interested in the whole header, because I want not only the well known 
> fields, but all of them (in particular I'd like to know if clients send 
> unknown fields).
> For reference, Squid has these options as ">h" and "

[jira] [Updated] (TS-3763) Whole request and response headers are not available

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3763:
---
Summary: Whole request and response headers are not available  (was: whole 
request and response headers are not available)

> Whole request and response headers are not available
> 
>
> Key: TS-3763
> URL: https://issues.apache.org/jira/browse/TS-3763
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Jonh Wendell
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> Currently it's possible to fetch a field within the header (request or 
> response). However it's not possible to access the whole header, as a big 
> string.
> I'm interested in the whole header, because I want not only the well known 
> fields, but all of them (in particular I'd like to know if clients send 
> unknown fields).
> For reference, Squid has these options as ">h" and "

[jira] [Closed] (TS-3762) Logging to syslog

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3762.
--
   Resolution: Won't Fix
Fix Version/s: (was: sometime)

> Logging to syslog
> -
>
> Key: TS-3762
> URL: https://issues.apache.org/jira/browse/TS-3762
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Jonh Wendell
>
> It would be useful to have the ability to log directly to syslog.



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

[jira] [Updated] (TS-3758) Elimiate std::map from logging code

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3758:
---
Fix Version/s: (was: 7.0.0)
   7.2.0

> Elimiate std::map from logging code
> ---
>
> Key: TS-3758
> URL: https://issues.apache.org/jira/browse/TS-3758
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.2.0
>
>
> We introduce std::map in the logging code with TS-2150. We should replace 
> this.



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

[jira] [Updated] (TS-3751) stream_editor: Change to use PCRE instead of posix regexes

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3751:
---
Fix Version/s: (was: sometime)
   7.1.0

> stream_editor: Change to use PCRE instead of posix regexes
> --
>
> Key: TS-3751
> URL: https://issues.apache.org/jira/browse/TS-3751
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
>  Labels: newbie
> Fix For: 7.1.0
>
>
> We should keep our standardization on using PCRE regexes everywhere.



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

[jira] [Updated] (TS-3751) stream_editor: Change to use PCRE instead of posix regexes

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3751:
---
Assignee: Phil Sorber

> stream_editor: Change to use PCRE instead of posix regexes
> --
>
> Key: TS-3751
> URL: https://issues.apache.org/jira/browse/TS-3751
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
>  Labels: newbie
> Fix For: 7.1.0
>
>
> We should keep our standardization on using PCRE regexes everywhere.



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

[jira] [Updated] (TS-3748) Seg fault on Centos inside Ats-pageSpeed plugin always

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3748:
--
Fix Version/s: (was: 7.0.0)
   sometime

> Seg fault on Centos inside Ats-pageSpeed plugin always
> --
>
> Key: TS-3748
> URL: https://issues.apache.org/jira/browse/TS-3748
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: wanrui
>Assignee: Otto van der Schaaf
>Priority: Critical
>  Labels: crash
> Fix For: sometime
>
>
> Program terminated with signal 6, Aborted.
> #0  0x079a25d7 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install expat-2.1.0-8.el7.x86_64 
> glibc-2.17-78.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 
> krb5-libs-1.12.2-14.el7.x86_64 libattr-2.4.46-12.el7.x86_64 
> libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-7.el7.x86_64 
> libgcc-4.8.3-9.el7.x86_64 libpciaccess-0.13.1-4.1.el7.x86_64 
> libselinux-2.2.2-6.el7.x86_64 pcre-8.32-14.el7.x86_64 
> valgrind-3.10.0-7.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 
> zlib-1.2.7-13.el7.x86_64
> (gdb) bt
> #0  0x079a25d7 in raise () from /lib64/libc.so.6
> #1  0x079a3cc8 in abort () from /lib64/libc.so.6
> #2  0x005019f2 in ink_mutex_acquire (m=0x420e8b0) at 
> ../lib/ts/ink_mutex.h:115
> #3  0x00509987 in Mutex_lock (m=0x420e8a0, t=0x2e031d60) at 
> ../iocore/eventsystem/I_Lock.h:488
> #4  0x0052da9f in TSMutexLock (mutexp=0x420e8a0) at 
> InkIOCoreAPI.cc:224
> #5  0x1caec2cf in net_instaweb::AtsBaseFetch::ForwardData 
> (this=0x30ded530, sp=..., reenable=false, last=false) at ats_base_fetch.cc:123
> #6  0x1caec44d in net_instaweb::AtsBaseFetch::HandleWrite 
> (this=, sp=..., handler=) at 
> ats_base_fetch.cc:81
> #7  0x1cc01887 in 
> net_instaweb::AsyncFetch::Write(base::BasicStringPiece const&, 
> net_instaweb::MessageHandler*) ()
>from /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #8  0x1cc61418 in 
> net_instaweb::HtmlWriterFilter::EmitBytes(base::BasicStringPiece 
> const&) () from /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #9  0x1cc619cb in 
> net_instaweb::HtmlWriterFilter::StartElement(net_instaweb::HtmlElement*) () 
> from /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #10 0x1cc5eca4 in 
> net_instaweb::HtmlParse::ApplyFilter(net_instaweb::HtmlFilter*) () from 
> /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #11 0x1cc5eeaa in net_instaweb::HtmlParse::Flush() () from 
> /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #12 0x1cb3feb5 in net_instaweb::RewriteDriver::FlushAsyncDone(int, 
> net_instaweb::Function*) () from 
> /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #13 0x1cc2416f in net_instaweb::Function::CallRun() () from 
> /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #14 0x1cafc30c in 
> net_instaweb::QueuedWorkerPool::Run(net_instaweb::QueuedWorkerPool::Sequence*,
>  net_instaweb::QueuedWorker*) ()
>from /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #15 0x1cc2416f in net_instaweb::Function::CallRun() () from 
> /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #16 0x1cafe0c6 in net_instaweb::Worker::WorkThread::Run() () from 
> /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #17 0x1cafe9d8 in net_instaweb::PthreadThreadImpl::InvokeRun(void*) 
> () from /home/aca/dca/libexec/trafficserver/ats_pagespeed.so
> #18 0x05089df5 in start_thread () from /lib64/libpthread.so.0
> #19 0x07a631ad in clone () from /lib64/libc.so.6
> Looks like the mutex  lock  return 22.then abort  .



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

[jira] [Commented] (TS-3743) Crash Under Heavy Load and Sending Plugin Error Page

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3743:


[~basking2] [~niq]
Please make a pull request for this.

> Crash Under Heavy Load and Sending Plugin Error Page
> 
>
> Key: TS-3743
> URL: https://issues.apache.org/jira/browse/TS-3743
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Sam Baskinger
>Assignee: Nick Kew
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: TS-3743.patch, stacktrace.txt
>
>
> One of the tests done on the [IronBee|http://www.ironbee.com] plugin for 
> TrafficServer is to send a [OWASP 
> Zap|https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project] scan 
> through the proxy at a DokuWiki server. When this is done TrafficServer will 
> crash. The crash is not always at the same point in the scan, but is always 
> when IronBee is generating a custom block page. We've reviewed IronBee and 
> cannot find anything it is doing to provoke the crash.
> The crash is always in {{HttpTunnel::producer_run 
> (this=this@entry=0xaf6021c8, p=p@entry=0xaf6022f8)}} and in all cases 
> {{c->vc}} is invalid.
> Our investigations correlated the crash with HttpSM's 
> {{ua_session->m_active}} being false. More specifically we suspect that 
> {{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}} 
> as true and then closes it -- setting {{ua_session->m_active}} to false -- 
> before {{tunnel.tunnel_run(p)}} is called at the end of the function.
> Please refer to two attachments. The first is a copy of the stack trace we've 
> been working off of. Every crash has a remarkably similar call stack. The 
> second attachment is a patch that is working in our labs.
> This crash also appears in the TrafficServer 4.x code, and the same patch 
> seems to resolve it.



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

[jira] [Updated] (TS-3736) AMC will replace std::map in the core

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3736:
---
Fix Version/s: (was: 7.0.0)
   7.2.0

> AMC will replace std::map in the core
> -
>
> Key: TS-3736
> URL: https://issues.apache.org/jira/browse/TS-3736
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.2.0
>
>




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

[jira] [Updated] (TS-3726) Expose build_error_response in order to making a formated error response in plugin

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3726:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Expose build_error_response in order to making a formated error response in 
> plugin
> --
>
> Key: TS-3726
> URL: https://issues.apache.org/jira/browse/TS-3726
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: TS API
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Labels: API, review
> Fix For: 7.1.0
>
> Attachments: TSHttpTxnErrorpageSet.patch
>
>
> expose build_error_response in order to making a formated error response in 
> plugin.
> ATS support multi-language error response page by body_factory.
> In the ATS internal, build_error_response used to generating it.
> I wrote a patch to expose build_error_response function for plugin.
> and modified example/basic_auth for a sample usage.



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

[jira] [Updated] (TS-3713) Should SSLNextProtocolTrampoline be a freelist object?

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3713:
---
Assignee: Jari Alhonen  (was: Susan Hinrichs)

> Should SSLNextProtocolTrampoline be a freelist object?
> --
>
> Key: TS-3713
> URL: https://issues.apache.org/jira/browse/TS-3713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
>  Labels: newbie
> Fix For: 7.1.0
>
>
> As it is now, we new() / delete() these for every new TLS object (at least 
> when NPN / ALPN is available). Maybe it'd be worth freelist'ing this object?



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

[jira] [Updated] (TS-3713) Should SSLNextProtocolTrampoline be a freelist object?

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3713:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Should SSLNextProtocolTrampoline be a freelist object?
> --
>
> Key: TS-3713
> URL: https://issues.apache.org/jira/browse/TS-3713
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>  Labels: newbie
> Fix For: 7.1.0
>
>
> As it is now, we new() / delete() these for every new TLS object (at least 
> when NPN / ALPN is available). Maybe it'd be worth freelist'ing this object?



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

[jira] [Closed] (TS-3702) Crash in cache handling with https

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3702.
--
Resolution: Cannot Reproduce

Please reopen if you are still having issues.

> Crash in cache handling with https
> --
>
> Key: TS-3702
> URL: https://issues.apache.org/jira/browse/TS-3702
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Aron Xu
>Assignee: Susan Hinrichs
>
> There's a random crash that happens in 5.3.0 on Linux x86_64. It's only seen 
> with https requests, either GET/POST requests. Requesting the same URL 
> without HTTPS never reproduce a crash on the same installation. I have core 
> dump but there could be the SSL cert within which I don't want to post 
> publicly. 
> (gdb) bt full
> #0  ink_aio_read (op=op@entry=0x2b9e4e7e0180) at AIO.cc:585
> No locals.
> #1  0x2b9e3bf0cd2e in CacheVC::handleRead 
> (this=this@entry=0x2b9e4e7e) at Cache.cc:2756
> o = 
> #2  0x2b9e3bf2e41a in do_read_call (akey=0x2b9e4e7e0038, 
> this=0x2b9e4e7e) at P_CacheInternal.h:707
> No locals.
> #3  Cache::open_read (this=, cont=, 
> key=, request=0x2b9e4e3f3078, params=, 
> type=, hostname=0x2b9e4e43e02e "portal.bfsu.edu.cn ", 
> host_len=18) at CacheRead.cc:138
> lock = {m = {m_ptr = 0x2b9e3c254410}, lock_acquired = true}
> vol = 
> c = 0x2b9e4e7e
> result = {w = {2697, 15360, 11224, 0, 0}}
> last_collision = 0x2b9e4e527470
> od = 0x0
> #4  0x2b9e3bf0bc36 in open_read (type=, params= out>, request=, url=, cont=, 
> this=) at P_CacheInternal.h:1074
> md5 = {b = {8565970937377538256, 10916790875855195096}, u64 = 
> {8565970937377538256, 10916790875855195096}, u32 = {3736420560, 1994420526, 
> 1116933080, 2541763446}, u8 = 
> "\320@\265\336.q\340v\330\v\223Bv;\200\227"}
> #5  CacheProcessor::open_read (this=0x20, cont=0x2b9e4e3f4398, 
> url=0x2b9e4e3f2a10, cluster_cache_local=224, request=0x2b9e4e3f3078, 
> params=0x2b9e4e3f2a50, 
> pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3598
> No locals.
> #6  0x2b9e3bdd9563 in HttpCacheSM::do_cache_open_read 
> (this=this@entry=0x2b9e4e3f4398) at HttpCacheSM.cc:211
> action_handle = 
> #7  0x2b9e3bdd989d in HttpCacheSM::open_read 
> (this=this@entry=0x2b9e4e3f4398, url=url@entry=0x2b9e4e3f2a10, 
> hdr=hdr@entry=0x2b9e4e3f3078, 
> params=params@entry=0x2b9e4e3f2a50, pin_in_cache=) at 
> HttpCacheSM.cc:243
> act_return = 
> #8  0x2b9e3bdea404 in HttpSM::do_cache_lookup_and_read 
> (this=0x2b9e4e3f2970) at HttpSM.cc:4389
> #13 0x2b9e3bdfd903 in HttpSM::set_next_state (this=0x2b9e4e3f2970) at 
> HttpSM.cc:6888
> __FUNCTION__ = "set_next_state"
> #14 0x2b9e3bdf1501 in HttpSM::state_read_client_request_header 
> (this=0x2b9e4e3f2970, event=100, data=0x21) at HttpSM.cc:777
> __FUNCTION__ = "state_read_client_request_header"
> bytes_used = 137
> state = PARSE_DONE
> #15 0x2b9e3bdff3f4 in HttpSM::main_handler (this=0x2b9e4e3f2970, 
> event=100, data=0x2b9e4c6d8f88) at HttpSM.cc:2554
> jump_point = 
> ---Type  to continue, or q  to quit--- 
> __FUNCTION__ = "main_handler"
> vc_entry = 
> #16 0x2b9e3bf75dc9 in handleEvent (data=0x2b9e4c6d8f88, event=100, 
> this=) at ../../iocore/eventsystem/I_Continuation.h:145
> No locals.
> #17 read_signal_and_update (vc=vc@entry=0x2b9e4c6d8e70, 
> event=event@entry=100) at UnixNetVConnection.cc:139
> No locals.
> #18 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2b9e4c6d8e70, 
> event=event@entry=100) at UnixNetVConnection.cc:959
> No locals.
> #19 0x2b9e3bf5a6ed in SSLNetVConnection::net_read_io 
> (this=0x2b9e4c6d8e70, nh=, lthread=) at 
> SSLNetVConnection.cc:546
> ret = 
> bytes = 
> s = 0x2b9e4c6d8f80
> __FUNCTION__ = "net_read_io"
> buf = @0x2b9e4c6d8fa8: {mbuf = 0x2b9e3ca57da0, entry = 0x0}
> r = 
> lock = {m = {m_ptr = 0x2b9e3c9b6df0}, lock_acquired = true}
> #20 0x2b9e3bf66d9a in NetHandler::mainNetEvent (this=0x2b9e43dd3760, 
> event=1, e=0x21) at UnixNet.cc:546
> epd = 0x2b9e4c6d9090
> __FUNCTION__ = "mainNetEvent"
> poll_timeout = 1050915552
> vc = 0x21
> #21 0x2b9e3bf938d0 in handleEvent (data=0x2b9e3c197900, event=5, 
> this=) at I_Continuation.h:145
> No locals.
> #22 EThread::process_event (this=this@entry=0x2b9e43dd0010, e=0x2b9e3c197900, 
> calling_code=calling_code@entry=5) at UnixEThread.cc:128
> c_temp = 
> lock = {m = {m_ptr = 0x2b9e3c241fe0}, lock_acquired = true}
> #23 0x2b9e3bf940ec in EThread::execute (this=0x2b9e43dd0010) at 
> UnixEThread.cc:252
> done_one = false
> e = 
> NegativeQueue = 

[jira] [Updated] (TS-3702) Crash in cache handling with https

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3702:
---
Fix Version/s: (was: 7.0.0)

> Crash in cache handling with https
> --
>
> Key: TS-3702
> URL: https://issues.apache.org/jira/browse/TS-3702
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Aron Xu
>Assignee: Susan Hinrichs
>
> There's a random crash that happens in 5.3.0 on Linux x86_64. It's only seen 
> with https requests, either GET/POST requests. Requesting the same URL 
> without HTTPS never reproduce a crash on the same installation. I have core 
> dump but there could be the SSL cert within which I don't want to post 
> publicly. 
> (gdb) bt full
> #0  ink_aio_read (op=op@entry=0x2b9e4e7e0180) at AIO.cc:585
> No locals.
> #1  0x2b9e3bf0cd2e in CacheVC::handleRead 
> (this=this@entry=0x2b9e4e7e) at Cache.cc:2756
> o = 
> #2  0x2b9e3bf2e41a in do_read_call (akey=0x2b9e4e7e0038, 
> this=0x2b9e4e7e) at P_CacheInternal.h:707
> No locals.
> #3  Cache::open_read (this=, cont=, 
> key=, request=0x2b9e4e3f3078, params=, 
> type=, hostname=0x2b9e4e43e02e "portal.bfsu.edu.cn ", 
> host_len=18) at CacheRead.cc:138
> lock = {m = {m_ptr = 0x2b9e3c254410}, lock_acquired = true}
> vol = 
> c = 0x2b9e4e7e
> result = {w = {2697, 15360, 11224, 0, 0}}
> last_collision = 0x2b9e4e527470
> od = 0x0
> #4  0x2b9e3bf0bc36 in open_read (type=, params= out>, request=, url=, cont=, 
> this=) at P_CacheInternal.h:1074
> md5 = {b = {8565970937377538256, 10916790875855195096}, u64 = 
> {8565970937377538256, 10916790875855195096}, u32 = {3736420560, 1994420526, 
> 1116933080, 2541763446}, u8 = 
> "\320@\265\336.q\340v\330\v\223Bv;\200\227"}
> #5  CacheProcessor::open_read (this=0x20, cont=0x2b9e4e3f4398, 
> url=0x2b9e4e3f2a10, cluster_cache_local=224, request=0x2b9e4e3f3078, 
> params=0x2b9e4e3f2a50, 
> pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3598
> No locals.
> #6  0x2b9e3bdd9563 in HttpCacheSM::do_cache_open_read 
> (this=this@entry=0x2b9e4e3f4398) at HttpCacheSM.cc:211
> action_handle = 
> #7  0x2b9e3bdd989d in HttpCacheSM::open_read 
> (this=this@entry=0x2b9e4e3f4398, url=url@entry=0x2b9e4e3f2a10, 
> hdr=hdr@entry=0x2b9e4e3f3078, 
> params=params@entry=0x2b9e4e3f2a50, pin_in_cache=) at 
> HttpCacheSM.cc:243
> act_return = 
> #8  0x2b9e3bdea404 in HttpSM::do_cache_lookup_and_read 
> (this=0x2b9e4e3f2970) at HttpSM.cc:4389
> #13 0x2b9e3bdfd903 in HttpSM::set_next_state (this=0x2b9e4e3f2970) at 
> HttpSM.cc:6888
> __FUNCTION__ = "set_next_state"
> #14 0x2b9e3bdf1501 in HttpSM::state_read_client_request_header 
> (this=0x2b9e4e3f2970, event=100, data=0x21) at HttpSM.cc:777
> __FUNCTION__ = "state_read_client_request_header"
> bytes_used = 137
> state = PARSE_DONE
> #15 0x2b9e3bdff3f4 in HttpSM::main_handler (this=0x2b9e4e3f2970, 
> event=100, data=0x2b9e4c6d8f88) at HttpSM.cc:2554
> jump_point = 
> ---Type  to continue, or q  to quit--- 
> __FUNCTION__ = "main_handler"
> vc_entry = 
> #16 0x2b9e3bf75dc9 in handleEvent (data=0x2b9e4c6d8f88, event=100, 
> this=) at ../../iocore/eventsystem/I_Continuation.h:145
> No locals.
> #17 read_signal_and_update (vc=vc@entry=0x2b9e4c6d8e70, 
> event=event@entry=100) at UnixNetVConnection.cc:139
> No locals.
> #18 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2b9e4c6d8e70, 
> event=event@entry=100) at UnixNetVConnection.cc:959
> No locals.
> #19 0x2b9e3bf5a6ed in SSLNetVConnection::net_read_io 
> (this=0x2b9e4c6d8e70, nh=, lthread=) at 
> SSLNetVConnection.cc:546
> ret = 
> bytes = 
> s = 0x2b9e4c6d8f80
> __FUNCTION__ = "net_read_io"
> buf = @0x2b9e4c6d8fa8: {mbuf = 0x2b9e3ca57da0, entry = 0x0}
> r = 
> lock = {m = {m_ptr = 0x2b9e3c9b6df0}, lock_acquired = true}
> #20 0x2b9e3bf66d9a in NetHandler::mainNetEvent (this=0x2b9e43dd3760, 
> event=1, e=0x21) at UnixNet.cc:546
> epd = 0x2b9e4c6d9090
> __FUNCTION__ = "mainNetEvent"
> poll_timeout = 1050915552
> vc = 0x21
> #21 0x2b9e3bf938d0 in handleEvent (data=0x2b9e3c197900, event=5, 
> this=) at I_Continuation.h:145
> No locals.
> #22 EThread::process_event (this=this@entry=0x2b9e43dd0010, e=0x2b9e3c197900, 
> calling_code=calling_code@entry=5) at UnixEThread.cc:128
> c_temp = 
> lock = {m = {m_ptr = 0x2b9e3c241fe0}, lock_acquired = true}
> #23 0x2b9e3bf940ec in EThread::execute (this=0x2b9e43dd0010) at 
> UnixEThread.cc:252
> done_one = false
> e = 
> NegativeQueue = {> = {head = 

[jira] [Updated] (TS-3702) Crash in cache handling with https

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3702:
---
Assignee: (was: Susan Hinrichs)

> Crash in cache handling with https
> --
>
> Key: TS-3702
> URL: https://issues.apache.org/jira/browse/TS-3702
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 5.3.0
>Reporter: Aron Xu
>
> There's a random crash that happens in 5.3.0 on Linux x86_64. It's only seen 
> with https requests, either GET/POST requests. Requesting the same URL 
> without HTTPS never reproduce a crash on the same installation. I have core 
> dump but there could be the SSL cert within which I don't want to post 
> publicly. 
> (gdb) bt full
> #0  ink_aio_read (op=op@entry=0x2b9e4e7e0180) at AIO.cc:585
> No locals.
> #1  0x2b9e3bf0cd2e in CacheVC::handleRead 
> (this=this@entry=0x2b9e4e7e) at Cache.cc:2756
> o = 
> #2  0x2b9e3bf2e41a in do_read_call (akey=0x2b9e4e7e0038, 
> this=0x2b9e4e7e) at P_CacheInternal.h:707
> No locals.
> #3  Cache::open_read (this=, cont=, 
> key=, request=0x2b9e4e3f3078, params=, 
> type=, hostname=0x2b9e4e43e02e "portal.bfsu.edu.cn ", 
> host_len=18) at CacheRead.cc:138
> lock = {m = {m_ptr = 0x2b9e3c254410}, lock_acquired = true}
> vol = 
> c = 0x2b9e4e7e
> result = {w = {2697, 15360, 11224, 0, 0}}
> last_collision = 0x2b9e4e527470
> od = 0x0
> #4  0x2b9e3bf0bc36 in open_read (type=, params= out>, request=, url=, cont=, 
> this=) at P_CacheInternal.h:1074
> md5 = {b = {8565970937377538256, 10916790875855195096}, u64 = 
> {8565970937377538256, 10916790875855195096}, u32 = {3736420560, 1994420526, 
> 1116933080, 2541763446}, u8 = 
> "\320@\265\336.q\340v\330\v\223Bv;\200\227"}
> #5  CacheProcessor::open_read (this=0x20, cont=0x2b9e4e3f4398, 
> url=0x2b9e4e3f2a10, cluster_cache_local=224, request=0x2b9e4e3f3078, 
> params=0x2b9e4e3f2a50, 
> pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3598
> No locals.
> #6  0x2b9e3bdd9563 in HttpCacheSM::do_cache_open_read 
> (this=this@entry=0x2b9e4e3f4398) at HttpCacheSM.cc:211
> action_handle = 
> #7  0x2b9e3bdd989d in HttpCacheSM::open_read 
> (this=this@entry=0x2b9e4e3f4398, url=url@entry=0x2b9e4e3f2a10, 
> hdr=hdr@entry=0x2b9e4e3f3078, 
> params=params@entry=0x2b9e4e3f2a50, pin_in_cache=) at 
> HttpCacheSM.cc:243
> act_return = 
> #8  0x2b9e3bdea404 in HttpSM::do_cache_lookup_and_read 
> (this=0x2b9e4e3f2970) at HttpSM.cc:4389
> #13 0x2b9e3bdfd903 in HttpSM::set_next_state (this=0x2b9e4e3f2970) at 
> HttpSM.cc:6888
> __FUNCTION__ = "set_next_state"
> #14 0x2b9e3bdf1501 in HttpSM::state_read_client_request_header 
> (this=0x2b9e4e3f2970, event=100, data=0x21) at HttpSM.cc:777
> __FUNCTION__ = "state_read_client_request_header"
> bytes_used = 137
> state = PARSE_DONE
> #15 0x2b9e3bdff3f4 in HttpSM::main_handler (this=0x2b9e4e3f2970, 
> event=100, data=0x2b9e4c6d8f88) at HttpSM.cc:2554
> jump_point = 
> ---Type  to continue, or q  to quit--- 
> __FUNCTION__ = "main_handler"
> vc_entry = 
> #16 0x2b9e3bf75dc9 in handleEvent (data=0x2b9e4c6d8f88, event=100, 
> this=) at ../../iocore/eventsystem/I_Continuation.h:145
> No locals.
> #17 read_signal_and_update (vc=vc@entry=0x2b9e4c6d8e70, 
> event=event@entry=100) at UnixNetVConnection.cc:139
> No locals.
> #18 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2b9e4c6d8e70, 
> event=event@entry=100) at UnixNetVConnection.cc:959
> No locals.
> #19 0x2b9e3bf5a6ed in SSLNetVConnection::net_read_io 
> (this=0x2b9e4c6d8e70, nh=, lthread=) at 
> SSLNetVConnection.cc:546
> ret = 
> bytes = 
> s = 0x2b9e4c6d8f80
> __FUNCTION__ = "net_read_io"
> buf = @0x2b9e4c6d8fa8: {mbuf = 0x2b9e3ca57da0, entry = 0x0}
> r = 
> lock = {m = {m_ptr = 0x2b9e3c9b6df0}, lock_acquired = true}
> #20 0x2b9e3bf66d9a in NetHandler::mainNetEvent (this=0x2b9e43dd3760, 
> event=1, e=0x21) at UnixNet.cc:546
> epd = 0x2b9e4c6d9090
> __FUNCTION__ = "mainNetEvent"
> poll_timeout = 1050915552
> vc = 0x21
> #21 0x2b9e3bf938d0 in handleEvent (data=0x2b9e3c197900, event=5, 
> this=) at I_Continuation.h:145
> No locals.
> #22 EThread::process_event (this=this@entry=0x2b9e43dd0010, e=0x2b9e3c197900, 
> calling_code=calling_code@entry=5) at UnixEThread.cc:128
> c_temp = 
> lock = {m = {m_ptr = 0x2b9e3c241fe0}, lock_acquired = true}
> #23 0x2b9e3bf940ec in EThread::execute (this=0x2b9e43dd0010) at 
> UnixEThread.cc:252
> done_one = false
> e = 
> NegativeQueue = {> = {head = 0x0}, tail 
> = }
> 

[jira] [Closed] (TS-3700) Should run doxygen before running sphinx

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3700.
--
   Resolution: Won't Fix
Fix Version/s: (was: Docs)

> Should run doxygen before running sphinx
> 
>
> Key: TS-3700
> URL: https://issues.apache.org/jira/browse/TS-3700
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Oknet Xu
>
> warning message:
> Running Sphinx v1.1.3
> WARNING: Doxygen files not found: xml/index.xml
>   The files are used to add links from an API description to the source
>   code for that object.
>   Run "$ make doxygen" to generate these XML files.
> here is the patch:
> {code}
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index 557d8a4..4ff456f 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -35,9 +35,11 @@ endif
>  clean-local:
> -rm -rf $(BUILDDIR)/* _build/html/* xml
>  
> -doxygen: Doxyfile
> +xml/index.xml: Doxyfile
> $(DOXYGEN)
>  
> +doxygen: xml/index.xml
> +
>  # Makefile for Sphinx documentation
>  #
>  
> @@ -71,32 +73,32 @@ help:
> @echo "  changesto make an overview of all 
> changed/added/deprecated items"
> @echo "  linkcheck  to check all external links for integrity"
>  
> -html-local:
> +html-local: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b html $(srcdir) $(BUILDDIR)/html
> @echo
> @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
>  
> -dirhtml:
> +dirhtml: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b dirhtml $(srcdir) 
> $(BUILDDIR)/html
> @echo
> @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
>  
> -singlehtml:
> +singlehtml: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b singlehtml $(srcdir) 
> $(BUILDDIR)/singlehtml
> @echo
> @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
>  
> -epub:
> +epub: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b epub $(srcdir) $(BUILDDIR)/epub
> @echo
> @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
>  
> -latex:
> +latex: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b latex $(srcdir) $(BUILDDIR)/latex
> @echo
> @echo "Build finished. The epub file is in $(BUILDDIR)/latex."
>  
> -man:
> +man: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b man $(srcdir) $(BUILDDIR)/man
> @echo
> @echo "Build finished. The man pages are in $(BUILDDIR)/man."
> {code}



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

[jira] [Updated] (TS-3700) Should run doxygen before running sphinx

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3700:
---
Summary: Should run doxygen before running sphinx  (was: should run doxygen 
before running sphinx)

> Should run doxygen before running sphinx
> 
>
> Key: TS-3700
> URL: https://issues.apache.org/jira/browse/TS-3700
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Oknet Xu
> Fix For: Docs
>
>
> warning message:
> Running Sphinx v1.1.3
> WARNING: Doxygen files not found: xml/index.xml
>   The files are used to add links from an API description to the source
>   code for that object.
>   Run "$ make doxygen" to generate these XML files.
> here is the patch:
> {code}
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index 557d8a4..4ff456f 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -35,9 +35,11 @@ endif
>  clean-local:
> -rm -rf $(BUILDDIR)/* _build/html/* xml
>  
> -doxygen: Doxyfile
> +xml/index.xml: Doxyfile
> $(DOXYGEN)
>  
> +doxygen: xml/index.xml
> +
>  # Makefile for Sphinx documentation
>  #
>  
> @@ -71,32 +73,32 @@ help:
> @echo "  changesto make an overview of all 
> changed/added/deprecated items"
> @echo "  linkcheck  to check all external links for integrity"
>  
> -html-local:
> +html-local: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b html $(srcdir) $(BUILDDIR)/html
> @echo
> @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
>  
> -dirhtml:
> +dirhtml: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b dirhtml $(srcdir) 
> $(BUILDDIR)/html
> @echo
> @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
>  
> -singlehtml:
> +singlehtml: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b singlehtml $(srcdir) 
> $(BUILDDIR)/singlehtml
> @echo
> @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
>  
> -epub:
> +epub: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b epub $(srcdir) $(BUILDDIR)/epub
> @echo
> @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
>  
> -latex:
> +latex: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b latex $(srcdir) $(BUILDDIR)/latex
> @echo
> @echo "Build finished. The epub file is in $(BUILDDIR)/latex."
>  
> -man:
> +man: doxygen
> $(SBUILD) -d $(BUILDDIR)/doctrees -b man $(srcdir) $(BUILDDIR)/man
> @echo
> @echo "Build finished. The man pages are in $(BUILDDIR)/man."
> {code}



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

[jira] [Updated] (TS-3699) TLS 64GB transfer fails with AES GCM cipher

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3699:
---
Fix Version/s: (was: 7.0.0)
   sometime

> TLS 64GB transfer fails with AES GCM cipher
> ---
>
> Key: TS-3699
> URL: https://issues.apache.org/jira/browse/TS-3699
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Dave Thompson
>Assignee: Dave Thompson
>  Labels: Yahoo
> Fix For: sometime
>
>
> Running ATS 5.0.1, over a TLS connection using cipher suite AES128-GCM-SHA256 
> will fail every time just before hitting 64GB.   Switching cipher to the same 
> CBC cipher (AES128-SHA), and data transfers can go beyond the 64GB limit.
> It appears we are hitting the GCM design limit of 2^39-256 bits (64GB).   TLS 
> should be able to renegotiate keys which resets the GCM counter, and in fact 
> I have successfully tested this with ATS 4.0.2.
> Work around is to use the CBC variant (AES128-SHA), though it would be good 
> to know what changed between 5.0.1 and 4.0.2 to stop cipher run out initiated 
> renegotiation.
> FWIW proxy.config.ssl.allow_client_renegotiation, does not appear to come 
> into play here.   Looking at the code, this appears to be written to prevent 
> client initiated renegotiation (prevent renegotiation attack circa 2009). 



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

[jira] [Commented] (TS-3695) Need to have a broader design discussion of follow redirect issues

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-3695:
-

[~shinrich] We agreed to have you do a panel on this at the October summit.

> Need to have a broader design discussion of follow redirect issues
> --
>
> Key: TS-3695
> URL: https://issues.apache.org/jira/browse/TS-3695
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Susan Hinrichs
> Fix For: sometime
>
>
> We have recently encountered issues with the follow redirect feature.  This 
> is a useful, but somewhat non-standard feature.  To avoid fixing and unfixing 
> things, we need to have a broader consensus on the expected behavior of the 
> follow redirect feature if various scenarios.
> Using this issue, the link bugs in this area.



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

[jira] [Updated] (TS-3692) Remove code associated with proxy.config.url_remap.url_remap_mode

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3692:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Remove code associated with proxy.config.url_remap.url_remap_mode
> -
>
> Key: TS-3692
> URL: https://issues.apache.org/jira/browse/TS-3692
> Project: Traffic Server
>  Issue Type: Task
>  Components: HTTP
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>
> See https://issues.apache.org/jira/browse/TS-481.  I removed the 
> configuration parameter proxy.config.url_remap.url_remap_mode in time for 
> release 6.0.  Need to go back and remove the unused code associated with that 
> parameter.



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

[jira] [Updated] (TS-3691) traffic_crashlog messages when running traffic_server -R 1

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3691:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> traffic_crashlog messages when running traffic_server -R 1
> --
>
> Key: TS-3691
> URL: https://issues.apache.org/jira/browse/TS-3691
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.1.0
>
>
> When I run the regressions (-R 1), I get the following output:
> {code}
> REGRESSION_RESULT PARENTSELECTION:  PASSED
> REGRESSION_TEST DONE: PASSED
> root@loki 132/0 # [Jun 14 22:31:48.574] {0x2b3658a84200} NOTE: crashlog 
> started, target=18881, debug=false syslog=true, uid=0 euid=0
> [connect] ERROR (main_socket_fd 6): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: failed to intialize 
> management API: [5] Error establishing socket connection.
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 128 expected 
> signal info bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} WARNING: received 0 of 936 expected 
> thread context bytes
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: logging to 0x22e7c20
> [Jun 14 22:31:48.575] {0x2b3658a84200} NOTE: readlink failed with No such 
> file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [connect] ERROR (main_socket_fd 7): No such file or directory
> [Jun 14 22:31:48.575] {0x2b3658a84200} ERROR: wrote crash log to 
> /opt/ats/var/log/trafficserver/crash-2015-06-14-223148.log
> {code}



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

[jira] [Updated] (TS-3686) Implement Lua "scriptlets", as discussed at the Austin 2015 Summit

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3686:
---
Fix Version/s: (was: 7.0.0)
   sometime

> Implement Lua "scriptlets", as discussed at the Austin 2015 Summit
> --
>
> Key: TS-3686
> URL: https://issues.apache.org/jira/browse/TS-3686
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Configuration, Lua
>Reporter: Leif Hedstrom
>  Labels: C
> Fix For: sometime
>
>




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

[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3681:
---
Assignee: Leif Hedstrom  (was: Sudheer Vinukonda)

> Promote TSHrtime APIs to ts.h /apidefs.h
> 
>
> Key: TS-3681
> URL: https://issues.apache.org/jira/browse/TS-3681
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: incompatible
> Fix For: 8.0.0
>
>
> Time to move these from experimental to ts/ts.h / apidefs.h



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

[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3681:
---
Fix Version/s: (was: 7.0.0)
   8.0.0

> Promote TSHrtime APIs to ts.h /apidefs.h
> 
>
> Key: TS-3681
> URL: https://issues.apache.org/jira/browse/TS-3681
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Sudheer Vinukonda
>  Labels: incompatible
> Fix For: 8.0.0
>
>
> Time to move these from experimental to ts/ts.h / apidefs.h



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

[jira] [Updated] (TS-3681) Promote TSHrtime APIs to ts.h /apidefs.h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3681:
---
Labels: incompatible  (was: )

> Promote TSHrtime APIs to ts.h /apidefs.h
> 
>
> Key: TS-3681
> URL: https://issues.apache.org/jira/browse/TS-3681
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>Assignee: Sudheer Vinukonda
>  Labels: incompatible
> Fix For: 7.0.0
>
>
> Time to move these from experimental to ts/ts.h / apidefs.h



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

[jira] [Updated] (TS-3675) Make HTTP/2 upgrade contexts handle bad settings properly

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3675:
---
Priority: Minor  (was: Major)

> Make HTTP/2 upgrade contexts handle bad settings properly
> -
>
> Key: TS-3675
> URL: https://issues.apache.org/jira/browse/TS-3675
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Priority: Minor
> Fix For: sometime
>
>
> Right now, we have:
> {code}
>   if (!http2_parse_settings_parameter(make_iovec(out_buf + nbytes, 
> HTTP2_SETTINGS_PARAMETER_LEN), param) ||
>!http2_settings_parameter_is_valid(param)) {
>  // TODO ignore incoming invalid parameters and send suitable 
> SETTINGS frame.
> {code}
> And then we continue trying to set the "invalid" parameter anyways.



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

[jira] [Updated] (TS-3680) Refine options for handling post and follow redirect

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-3680:

Priority: Minor  (was: Major)

> Refine options for handling post and follow redirect
> 
>
> Key: TS-3680
> URL: https://issues.apache.org/jira/browse/TS-3680
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Susan Hinrichs
>Priority: Minor
> Fix For: sometime
>
>
> In the current code base (5.3.x), the follow redirect feature applies to POST 
> methods as well as GET/HEAD methods.  For POST redirects, the code saves 
> aside a copy (reference counted) of the post data, so it can resend it later 
> if the original server sends a redirect and the follow redirect feature is 
> enabled.
> This logic has been in there at least through the 5.x code probably earlier.  
> It has been pointed out that in some cases, replaying a POST in a redirect 
> scenario may not be safe.  The POST may have already caused a change before 
> the redirect occurred.
> In other cases, following the redirect on a post may be just fine.  If the 
> origin server makes the redirect decision before anything is done on the post 
> request, replaying the post request should be just fine.
> We should step back and determine if we want to reconsider how we handle 
> follow redirects for POST methods.  I see the following options.
> * Keep the current support and bug fix it as necessary (e.g. TS-3656)
> * Remove the post redirect support.
> * Add another config control to enable follow redirect only for GET/HEAD vs 
> enabled following redirect for all methods, vs do not follow redirect.



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

[jira] [Updated] (TS-3629) ats pagespeed corrupts Link: header in response

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3629:
---
Summary: ats pagespeed corrupts Link: header in response  (was: TS corrupts 
Link: header in response)

> ats pagespeed corrupts Link: header in response
> ---
>
> Key: TS-3629
> URL: https://issues.apache.org/jira/browse/TS-3629
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Felicity Tarnell
>Assignee: Otto van der Schaaf
> Fix For: sometime
>
>
> (Using 5.3.0 on 64-bit Linux.)
> We have an origin that links a {{Link}} header in its response.  Requesting 
> the document directly from the origin (nginx) shows the correct header:
> {noformat}
> by-staging-1:~# curl -Ix localhost:81 http://plan-staging.torchboxapps.com/
> HTTP/1.1 200 OK
> Server: nginx
> Date: Thu, 21 May 2015 10:04:54 GMT
> Content-Type: text/html; charset=utf-8
> Connection: keep-alive
> Vary: Accept-Encoding
> Expires: Sun, 19 Nov 1978 05:00:00 GMT
> Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
> Content-Language: en
> Link: ; 
> rel="canonical",; rel="shortlink"
> {noformat}
> However, requesting the same document from ATS, using the same origin, 
> truncates the header:
> {noformat}
> <1 jobs>  152!klamath:~/tbx/puppet>curl -I 
> https://plan-staging.torchboxapps.com/
> HTTP/1.1 200 OK
> Date: Thu, 21 May 2015 10:06:01 GMT
> Content-Type: text/html; charset=utf-8
> Vary: Accept-Encoding
> Expires: Sun, 19 Nov 1978 05:00:00 GMT
> Cache-Control: pre-check=0
> Content-Language: en
> Link: ; rel="shortlink
> Content-Length: 0
> Age: 0
> Connection: keep-alive
> Strict-Transport-Security: max-age=15552000
> Via: http/1.1 by-staging-1 (uScMsSf pSeN:t cCMi pSs )
> X-Cache: miss
> {noformat}
> (The reason for http vs. https is that ATS is terminating SSL, and the origin 
> uses http only.)
> {{tcpdump}} shows that in the ATS request, the backend is sending the correct 
> header:
> {noformat}
> 16:37:02.145579 IP 127.0.0.1.38756 > 127.0.0.1.81: Flags [P.], seq 1:376, ack 
> 1, win 342, options [nop,nop,TS val 66617043 ecr 66617043], length 375
> 0x:  4500 01ab f8b6 4000 4006 4294 7f00 0001  E.@.@.B.
> 0x0010:  7f00 0001 9764 0051 170d 8668 cc19 17f9  .d.Q...h
> 0x0020:  8018 0156 ff9f  0101 080a 03f8 7ed3  ...V..~.
> 0x0030:  03f8 7ed3 4845 4144 2068 7474 703a 2f2f  ..~.HEAD.http://
> 0x0040:  706c 616e 2d73 7461 6769 6e67 2e74 6f72  plan-staging.tor
> 0x0050:  6368 626f 7861 7070 732e 636f 6d2f 2048  chboxapps.com/.H
> 0x0060:  5454 502f 312e 310d 0a41 7574 686f 7269  TTP/1.1..Authori
> 0x0070:  7a61 7469 6f6e 3a20 4261 7369 6320   zation:.Basic...
> 0x0080:           
> 0x0090:         0d0a  xx..
> 0x00a0:  5573 6572 2d41 6765 6e74 3a20 6375 726c  User-Agent:.curl
> 0x00b0:  2f37 2e34 312e 300d 0a48 6f73 743a 2070  /7.41.0..Host:.p
> 0x00c0:  6c61 6e2d 7374 6167 696e 672e 746f 7263  lan-staging.torc
> 0x00d0:  6862 6f78 6170 7073 2e63 6f6d 0d0a 4163  hboxapps.com..Ac
> 0x00e0:  6365 7074 3a20 2a2f 2a0d 0a58 2d46 6f72  cept:.*/*..X-For
> 0x00f0:  7761 7264 6564 2d50 726f 746f 3a20 6874  warded-Proto:.ht
> 0x0100:  7470 730d 0a43 6c69 656e 742d 6970 3a20  tps..Client-ip:.
> 0x0110:  3932 2e32 312e 3135 332e 360d 0a58 2d46  92.21.153.6..X-F
> 0x0120:  6f72 7761 7264 6564 2d46 6f72 3a20 3932  orwarded-For:.92
> 0x0130:  2e32 312e 3135 332e 360d 0a56 6961 3a20  .21.153.6..Via:.
> 0x0140:  6874 7470 732f 312e 3120 6279 2d73 7461  https/1.1.by-sta
> 0x0150:  6769 6e67 2d31 5b43 3145 3346 3436 365d  ging-1[C1E3F466]
> 0x0160:  2028 4170 6163 6865 5472 6166 6669 6353  .(ApacheTrafficS
> 0x0170:  6572 7665 722f 352e 332e 3020 5b75 5363  erver/5.3.0.[uSc
> 0x0180:  4d73 2066 2070 2065 4e3a 7420 6343 4d69  Ms.f.p.eN:t.cCMi
> 0x0190:  2070 2073 205d 290d 0a50 6167 6553 7065  .p.s.])..PageSpe
> 0x01a0:  6564 3a20 6f66 660d 0a0d 0a  ed:.off
> 16:37:02.145588 IP 127.0.0.1.81 > 127.0.0.1.38756: Flags [.], ack 376, win 
> 350, options [nop,nop,TS val 66617043 ecr 66617043], length 0
> 0x:  4500 0034 692a 4000 4006 d397 7f00 0001  E..4i*@.@...
> 0x0010:  7f00 0001 0051 9764 cc19 17f9 170d 87df  .Q.d
> 0x0020:  8010 015e fe28  0101 080a 03f8 7ed3  ...^.(~.
> 0x0030:  03f8 7ed3..~.
> 16:37:02.240195 IP 127.0.0.1.81 > 

[jira] [Assigned] (TS-3625) Some statistics not being gathered

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-3625:
--

Assignee: Bryan Call  (was: Leif Hedstrom)

> Some statistics not being gathered
> --
>
> Key: TS-3625
> URL: https://issues.apache.org/jira/browse/TS-3625
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics
>Reporter: Jon Sime
>Assignee: Bryan Call
>  Labels: incompatible
> Fix For: 7.0.0
>
>
> The following statistics appear to not have any data collected for them in 
> recent versions of TS, instead only emitting a zero value. The list was put 
> together by examining the stats_over_http output on a production instance 
> which receives enough varied traffic that it should, in theory at least, 
> cause most implemented statistics to go non-zero.
> {code}
> proxy.node.cache.contents.num_docs
> proxy.node.cache_hit_mem_ratio_avg_10s_int_pct
> proxy.node.cache_hit_mem_ratio_int_pct
> proxy.node.current_cache_connections
> proxy.node.dns.lookup_avg_time_ms
> proxy.node.dns.lookups_per_second
> proxy.node.dns.total_dns_lookups
> proxy.node.http.transaction_frac_avg_10s.errors.aborts_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.connect_failed_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.early_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.empty_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.other_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.possible_aborts_int_pct
> proxy.node.http.transaction_frac_avg_10s.errors.pre_accept_hangups_int_pct
> proxy.node.http.transaction_frac_avg_10s.hit_fresh_int_pct
> proxy.node.http.transaction_frac_avg_10s.hit_revalidated_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_changed_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_client_no_cache_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_cold_int_pct
> proxy.node.http.transaction_frac_avg_10s.miss_not_cacheable_int_pct
> proxy.node.http.transaction_frac_avg_10s.other.unclassified_int_pct
> proxy.node.log.bytes_flush_to_disk
> proxy.node.log.bytes_lost_before_flush_to_disk
> proxy.node.log.bytes_lost_before_preproc
> proxy.node.log.bytes_lost_before_sent_to_network
> proxy.node.log.bytes_lost_before_written_to_disk
> proxy.node.log.bytes_received_from_network
> proxy.node.log.bytes_received_from_network_avg_10s
> proxy.node.log.bytes_sent_to_network
> proxy.node.log.bytes_sent_to_network_avg_10s
> proxy.node.log.bytes_written_to_disk
> proxy.node.log.event_log_access_aggr
> proxy.node.log.event_log_access_fail
> proxy.node.log.event_log_access_full
> proxy.node.log.event_log_access_ok
> proxy.node.log.event_log_access_skip
> proxy.node.log.event_log_error_aggr
> proxy.node.log.event_log_error_fail
> proxy.node.log.event_log_error_full
> proxy.node.log.event_log_error_ok
> proxy.node.log.event_log_error_skip
> proxy.node.log.num_flush_to_disk
> proxy.node.log.num_lost_before_flush_to_disk
> proxy.node.log.num_lost_before_sent_to_network
> proxy.node.log.num_received_from_network
> proxy.node.log.num_sent_to_network
> proxy.process.cache.directory_collision
> proxy.process.cache.evacuate.active
> proxy.process.cache.evacuate.failure
> proxy.process.cache.evacuate.success
> proxy.process.cache.frags_per_doc.1
> proxy.process.cache.frags_per_doc.2
> proxy.process.cache.frags_per_doc.3+
> proxy.process.cache.gc_bytes_evacuated
> proxy.process.cache.gc_frags_evacuated
> proxy.process.cache.hdr_marshal_bytes
> proxy.process.cache.hdr_marshals
> proxy.process.cache.lookup.active
> proxy.process.cache.lookup.failure
> proxy.process.cache.lookup.success
> proxy.process.cache.percent_full
> proxy.process.cache.pread_count
> proxy.process.cache.read_busy.failure
> proxy.process.cache.read_busy.success
> proxy.process.cache.remove.active
> proxy.process.cache.remove.failure
> proxy.process.cache.remove.success
> proxy.process.cache.scan.active
> proxy.process.cache.scan.failure
> proxy.process.cache.scan.success
> proxy.process.cache.volume_0.directory_collision
> proxy.process.cache.volume_0.evacuate.active
> proxy.process.cache.volume_0.evacuate.failure
> proxy.process.cache.volume_0.evacuate.success
> proxy.process.cache.volume_0.frags_per_doc.1
> proxy.process.cache.volume_0.frags_per_doc.2
> proxy.process.cache.volume_0.frags_per_doc.3+
> proxy.process.cache.volume_0.gc_bytes_evacuated
> proxy.process.cache.volume_0.gc_frags_evacuated
> proxy.process.cache.volume_0.hdr_marshal_bytes
> proxy.process.cache.volume_0.hdr_marshals
> proxy.process.cache.volume_0.lookup.active
> proxy.process.cache.volume_0.lookup.failure
> proxy.process.cache.volume_0.lookup.success
> proxy.process.cache.volume_0.pread_count
> proxy.process.cache.volume_0.remove.active
> proxy.process.cache.volume_0.remove.failure

[jira] [Updated] (TS-3624) Make DH params file regenerate every $tperiod

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3624:
---
Summary: Make DH params file regenerate every $tperiod  (was: make DH 
params file regenerate every $tperiod)

> Make DH params file regenerate every $tperiod
> -
>
> Key: TS-3624
> URL: https://issues.apache.org/jira/browse/TS-3624
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Igor Galić
> Fix For: sometime
>
>
> Longjam has landed, and we now know that DH below a certain threshold is 
> vulnerable (to a nation-state adversary). https://weakdh.org/
> while ats offers to configure dhparams through a file, it would be nice if, 
> like dovecot, we offered a way to aut-regenerate dhparams, every $tperiod.
> see http://wiki2.dovecot.org/SSL/DovecotConfiguration#SSL_security_settings
> http://hg.dovecot.org/dovecot-2.2/file/45013c8cf69c/src/lib-ssl-iostream/iostream-openssl-params.c



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

[jira] [Closed] (TS-3599) Multiple dest_ip=* directives has unpredictable behavior in ssl_multicert.config

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3599.
--
   Resolution: Won't Fix
Fix Version/s: (was: 7.0.0)

> Multiple dest_ip=* directives has unpredictable behavior in 
> ssl_multicert.config
> 
>
> Key: TS-3599
> URL: https://issues.apache.org/jira/browse/TS-3599
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>
> If I create an ssl_multicert.config with e.g.
> {code}
> dest_ip=* ssl_key_name=foo.key ssl_cert_name=foo.crt
> dest_ip=* ssl_key_name=bar.key ssl_cert_name=bar.crt
> {code}
> Then even with an SNI enabled client, which uses SNI in the TLS handshake, 
> ATS seems to arbitrarily pick a cert. This seems nonsensical, I get the 
> impression that dest_ip= would only take effect if there is no SNI 
> in the handshake?
> I understand that more than one dest_ip=* is perhaps not a valid 
> configuration, but in that case we ought to either error out (fail to start), 
> or at least produce a really loud warning.  Clearly making it fail like this 
> seems unreasonable :).



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

[jira] [Updated] (TS-3606) Add configuration option to allow server context per thread

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3606:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Add configuration option to allow server context per thread
> ---
>
> Key: TS-3606
> URL: https://issues.apache.org/jira/browse/TS-3606
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Attachments: TS-3606-hack-for-53.diff
>
>
> This was recommended by John Foley (OpenSSL developer) to reduce lock 
> contention.



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

[jira] [Updated] (TS-3598) Should we add an option to refuse non-SNI negotiated TLS connections

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3598:
---
Assignee: Jon Sime

> Should we add an option to refuse non-SNI negotiated TLS connections
> 
>
> Key: TS-3598
> URL: https://issues.apache.org/jira/browse/TS-3598
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Leif Hedstrom
>Assignee: Jon Sime
> Fix For: Docs
>
>
> I'm not 100% certain how this interoperates with all the various SSL and TLS 
> versions, but, we might want to consider adding an option to refuse non-SNI 
> handshakes completely.
> The rationale is this:
> If we have multiple sites, as configured in ssl_multicert.config, but the box 
> does not have unique IPs for each such cert, then the current behavior is 
> undesirable (maybe even insecure?). E.g. the setup would be
> {code}
> dest_ip=* ssl_cert_name=cert1.crt ssl_key_name=key1.key
> dest_ip=* ssl_cert_name=cert2.crt ssl_key_name=key2.key
> dest_ip=* ssl_cert_name=cert3.crt ssl_key_name=key2.key
> {code}
> In the case of a non-SNI connection, the first certificate will now always be 
> presented. This is likely not to be "secure", in that browser will either 
> reject or give nasty errors / warnings about the wrong CN in the certificate.
> In this case, having an option to say "refuse non-SNI handshakes" might be 
> more desirable.



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

Build failed in Jenkins: clang-analyzer #2540

[jenkins]

See 

Changes:

[Phil Sorber] TS-4719: Make AIO threads interleave memory across NUMA nodes.

--
[...truncated 4963 lines...]
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNextDup.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldRemove.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 54%] 
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... [ 55%] 
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... [ 56%] 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... [ 57%] 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... [ 58%] 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... [ 59%] 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... [ 60%] 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... [ 61%] 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... [ 62%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 62%] 
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... [ 63%] 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... [ 64%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSUuidCreate.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... [ 66%] 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 

[jira] [Closed] (TS-3572) regex_revalidate - purge is not executed

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3572.
--
Resolution: Invalid

> regex_revalidate - purge is not executed
> 
>
> Key: TS-3572
> URL: https://issues.apache.org/jira/browse/TS-3572
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Luca Rea
>Assignee: Phil Sorber
>
> Hi,
> if expiry time is close to epoch time (delta < ~60s) the plugin doesn't purge 
> the related url.
> I expected the matched condition was just expiry time > epoch time.



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

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

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3577:
---
Assignee: James Peach  (was: Jason Kenny)

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

[jira] [Updated] (TS-3572) regex_revalidate - purge is not executed

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3572:
---
Fix Version/s: (was: 7.0.0)

> regex_revalidate - purge is not executed
> 
>
> Key: TS-3572
> URL: https://issues.apache.org/jira/browse/TS-3572
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Luca Rea
>Assignee: Phil Sorber
>
> Hi,
> if expiry time is close to epoch time (delta < ~60s) the plugin doesn't purge 
> the related url.
> I expected the matched condition was just expiry time > epoch time.



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

[jira] [Updated] (TS-3571) Should we optimize (defer) the cqu / cquc stringification on logging?

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3571:
---
Assignee: (was: Meera Mosale Nataraja)

> Should we optimize (defer) the cqu / cquc stringification on logging?
> -
>
> Key: TS-3571
> URL: https://issues.apache.org/jira/browse/TS-3571
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Today, we always calculate the strings for cqu and cquc, regardless if they 
> are used or not. This is not optimal, since it's not unusual to use e.g. 
> cquuc instead. In most places where we allow logging URL strings, we also 
> have a way to defer the stringification until we actually need to marshal the 
> URL.
> My suggestion is that we do this deferred string creation for cqu and cquuc 
> as well.



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

[jira] [Updated] (TS-3571) Should we optimize (defer) the cqu / cquc stringification on logging?

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3571:
---
Labels:   (was: newbie)

> Should we optimize (defer) the cqu / cquc stringification on logging?
> -
>
> Key: TS-3571
> URL: https://issues.apache.org/jira/browse/TS-3571
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Today, we always calculate the strings for cqu and cquc, regardless if they 
> are used or not. This is not optimal, since it's not unusual to use e.g. 
> cquuc instead. In most places where we allow logging URL strings, we also 
> have a way to defer the stringification until we actually need to marshal the 
> URL.
> My suggestion is that we do this deferred string creation for cqu and cquuc 
> as well.



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

[jira] [Updated] (TS-3559) ATS should support TLS session ticket caching to origin

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3559:
---
Summary: ATS should support TLS session ticket caching to origin  (was: ATS 
should support client side TLS session ticket caching/use.)

> ATS should support TLS session ticket caching to origin
> ---
>
> Key: TS-3559
> URL: https://issues.apache.org/jira/browse/TS-3559
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Security, SSL
>Reporter: Dave Thompson
>Assignee: Dave Thompson
>  Labels: Yahoo
> Fix For: 7.2.0
>
>
> For TLS connections between ATS and origin server, ATS should support caching 
> of session ticket and associated master secret, etc, for later abbreviated 
> handshake TLS resumption to origin server, reduced round trip, and overall 
> performance improvement.



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

[jira] [Updated] (TS-3559) ATS should support TLS session ticket caching to origin

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3559:
---
Fix Version/s: (was: 7.0.0)
   7.2.0

> ATS should support TLS session ticket caching to origin
> ---
>
> Key: TS-3559
> URL: https://issues.apache.org/jira/browse/TS-3559
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Security, SSL
>Reporter: Dave Thompson
>Assignee: Dave Thompson
>  Labels: Yahoo
> Fix For: 7.2.0
>
>
> For TLS connections between ATS and origin server, ATS should support caching 
> of session ticket and associated master secret, etc, for later abbreviated 
> handshake TLS resumption to origin server, reduced round trip, and overall 
> performance improvement.



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

[jira] [Closed] (TS-3544) traffic_logcat asserts when fmt_buf_bytes = 0

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3544.
--
   Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)

Please reopen if this is still an issue.

> traffic_logcat asserts when fmt_buf_bytes = 0
> -
>
> Key: TS-3544
> URL: https://issues.apache.org/jira/browse/TS-3544
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Steven Feltner
>  Labels: crash
>
> While reading a 766MB squid.blog, traffic_logcat seg faults.
> Here is a live gdb session:
> 1429614621.421 4 173.252.120.113 TCP_MISS/200 6392 GET http://72.167.230.251/ 
> - DIRECT/72.167.230.251 text/html
> 1429614621.428 3 197.232.18.238 TCP_MISS/200 3663 GET 
> http://50.62.195.13/wp-includes/js/jquery/jquery-migrate.mi
> FATAL: LogFile.cc:541: failed assert `fmt_line_bytes > 0`
> Program received signal SIGABRT, Aborted.
> 0x003949832625 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.12-1.149.el6_6.5.x86_64 hwloc-1.5-3.el6_5.x86_64 
> keyuibselinux-2.0.94-5.8.el6.x86_64 libstdc++-4.4.7-11.el6.x86_64 
> libxml2-2.7.6-17.el6_6.1.x86_64 nss-softokn-freebl-re-7.8-6.el6.x86_64 
> tcl-8.5.7-6.el6.x86_64 xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64 
> zlib-1.2.3-29.el6.x86_
> (gdb) bt full
> #0  0x003949832625 in raise () from /lib64/libc.so.6
> No symbol table info available.
> #1  0x003949833e05 in abort () from /lib64/libc.so.6
> No symbol table info available.
> #2  0x003057e2705a in ink_die_die_die (fmt=0x3057e333a8 "%s:%d: failed 
> assert `%s`", ap=0x7ffe6b40) at in
> No locals.
> #3  ink_fatal_va(const char *, typedef __va_list_tag __va_list_tag *) 
> (fmt=0x3057e333a8 "%s:%d: failed assert `%s
> msg = "FATAL: LogFile.cc:541: failed assert `fmt_line_bytes > 0`", 
> '\000' 
> #4  0x003057e270ed in ink_fatal (message_format=0x10c5f  out of bounds>) at ink_error.cc:73
> ap = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 
> 0x7ffe6c20, reg_save_area = 0x7ffe6b60
> #5  0x003057e24a05 in _ink_assert (expression=0x  0x out of bounds>,
> No locals.
> #6  0x00431544 in LogFile::write_ascii_logbuffer 
> (buffer_header=0x7ffee4f0, fd=1, path=0x460c6f ".",
> iter = {m_in_network_order = false, m_next = 0x7fff3150 
> "\035\060\066U", m_iter_entry_count = 1, m_bu
> fmt_line_bytes = 0
> fmt_buf = "1429614620.635 1 198.58.10.197 TCP_MISS/200 3926 GET 
> http://72.167.243.35/times/vasco.png - DI
> format_type = LOG_FORMAT_CUSTOM
> __func__ = "write_ascii_logbuffer"
> fmt_line = "1429614621.436 11 104.236.70.110 TCP_MISS/400 383 GET 
> http://50.62.195.13/wp-includes/js/jque
> entry_header = 
> fmt_buf_bytes = 0
> bytes = 0
> fieldlist_str = 0x7ffee536 
> "cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct"
> printf_str = 0x7ffee56f "\377 \377 \377 \377/\377 \377 \377 \377 
> \377 \377/\377 \377"
> #7  0x0041b258 in process_file (in_fd=12, out_fd=1) at logcat.cc:164
> first_read_size = 8
> header_size = 64
> byte_count = 
> header = 0x7ffee4f0
> second_read_size = 56
> alt_format = 0x0
> buffer = 
> "\316\372\316\n\002\000\000\000\004\000\000\000\310g\000\000%\000\000\000\035\060\066U\036\060\\000\000squid\000cqtq,ttms,chi,crc,pssc,psql,cqhm,cquc,caun,phr,pqsn,psct\000\377
>  \377 \377 \377/\377 \377 
> \37K\000\000\000\000\000\000\000\000\000\000\v\000\000\000\000\000\000\000\002\000+\222h\354Fn3\000\000\000\000\000\
> buffer_bytes = 
> bytes = 
> __func__ = "process_file"
> nread = 26504
> #8  0x0041b4f7 in main (argv=) at logcat.cc:297
> in_fd = 12
> i = 
> out_fd = 1
> error = 
> (gdb) frame 6
> #6  0x00431544 in LogFile::write_ascii_logbuffer 
> (buffer_header=0x7ffee4f0, fd=1, path=0x460c6f ".", alt_format=0x0) at 
> LogFile.cc:541
> 541 ink_assert(fmt_line_bytes > 0);
> (gdb) p fmt_line_bytes
> $1 = 0
> (gdb) entry_header
> Undefined command: "entry_header".  Try "help".
> (gdb) p entry_header
> $2 = 
> (gdb) p *entry_header
> value has been optimized out
> (gdb) p entry_header->entry_len
> value has been optimized out
> (gdb) set print elements 0
> (gdb) p fmt_line
> $3 = "1429614621.436 11 104.236.70.110 TCP_MISS/400 383 GET 
> http://50.62.195.13/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.2.1 - 
> DIRECT/50.62.195.13 
> application/javascriptplication/x-font-woffion/javascriptT/72.167.243.35 
> text/html0a62098f_1 - DIRECT/72.167.25.149 
> 

[jira] [Updated] (TS-3547) SSLNetVConnection: switch to a vectored write

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3547:
---
Fix Version/s: (was: sometime)
   7.1.0

> SSLNetVConnection: switch to a vectored write
> -
>
> Key: TS-3547
> URL: https://issues.apache.org/jira/browse/TS-3547
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network, SSL
>Reporter: Thomas Jackson
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> UnixNetVConnection does a vectored write which bunches blocks together until 
> the outgoing buffer will fill up. This means we can better fill the packets, 
> and should give us a bit of a performance boost to SSL writes.



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

[jira] [Updated] (TS-3547) SSLNetVConnection: switch to a vectored write

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3547:
---
Fix Version/s: (was: 7.0.0)
   sometime

> SSLNetVConnection: switch to a vectored write
> -
>
> Key: TS-3547
> URL: https://issues.apache.org/jira/browse/TS-3547
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network, SSL
>Reporter: Thomas Jackson
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> UnixNetVConnection does a vectored write which bunches blocks together until 
> the outgoing buffer will fill up. This means we can better fill the packets, 
> and should give us a bit of a performance boost to SSL writes.



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

[jira] [Updated] (TS-3528) Create a global for the ticket_key_name from ssl_multicert.config

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3528:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Create a global for the ticket_key_name from ssl_multicert.config
> -
>
> Key: TS-3528
> URL: https://issues.apache.org/jira/browse/TS-3528
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> The current implementation requires that you specify the ticket_key_name for 
> each entry in the ssl_multicert.config file.
> In a simple case, you only want to specify one key for all the domains that 
> the ATS device supports.  To make that simple case easy, we will add a 
> default ticket_key_name in the records.config.
> This is related to TS-3371 which proposes adding a default ssl_ticket_enabled.



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

[jira] [Updated] (TS-3525) Trailing spaces in a remap.config and \ continuations can fail to load

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3525:
---
Fix Version/s: (was: sometime)
   7.1.0

> Trailing spaces in a remap.config and \ continuations can fail to load
> --
>
> Key: TS-3525
> URL: https://issues.apache.org/jira/browse/TS-3525
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Leif Hedstrom
>  Labels: A, newbie
> Fix For: 7.1.0
>
>
> E.g. the following would fail:
> {code}
> map http://example.com http://foo.example.com @plugin=conf_remap.so\  
> @pparam=...
> {code}
> note the trailing white space after the \.



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

[jira] [Updated] (TS-3525) Trailing spaces in a remap.config and \ continuations can fail to load

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3525:
---
Assignee: Tyler Stroh

> Trailing spaces in a remap.config and \ continuations can fail to load
> --
>
> Key: TS-3525
> URL: https://issues.apache.org/jira/browse/TS-3525
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Tyler Stroh
>  Labels: A, newbie
> Fix For: 7.1.0
>
>
> E.g. the following would fail:
> {code}
> map http://example.com http://foo.example.com @plugin=conf_remap.so\  
> @pparam=...
> {code}
> note the trailing white space after the \.



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

[jira] [Assigned] (TS-3498) h2c (upgrade dance) seems to hang

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-3498:
--

Assignee: Bryan Call

> h2c (upgrade dance) seems to hang
> -
>
> Key: TS-3498
> URL: https://issues.apache.org/jira/browse/TS-3498
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> I see
> {code}
> loki (09:37) 259/0 $ nghttp -v -u http://docs.trafficserver.apache.org
> [  0.031] Connected
> [  0.031] HTTP Upgrade request
> GET / HTTP/1.1
> Host: docs.trafficserver.apache.org
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c-14
> HTTP2-Settings: AAMAAABkAAQAAP__
> Accept: */*
> User-Agent: nghttp2/0.7.4-DEV
> [  0.066] HTTP Upgrade response
> HTTP/1.1 101 Switching Protocols
> Date: Sun, 05 Apr 2015 15:37:58 GMT
> Connection: Upgrade
> Via: http/1.1 ATS (ApacheTrafficServer/5.3.0 [c s f ])
> Server: ATS/5.3.0
> Upgrade: h2c-14
> [  0.066] HTTP Upgrade success
> [  0.066] recv SETTINGS frame 

[jira] [Commented] (TS-3498) h2c (upgrade dance) seems to hang

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3498:


Remove support for h2c and respond with error when trying to upgrade.

> h2c (upgrade dance) seems to hang
> -
>
> Key: TS-3498
> URL: https://issues.apache.org/jira/browse/TS-3498
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I see
> {code}
> loki (09:37) 259/0 $ nghttp -v -u http://docs.trafficserver.apache.org
> [  0.031] Connected
> [  0.031] HTTP Upgrade request
> GET / HTTP/1.1
> Host: docs.trafficserver.apache.org
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c-14
> HTTP2-Settings: AAMAAABkAAQAAP__
> Accept: */*
> User-Agent: nghttp2/0.7.4-DEV
> [  0.066] HTTP Upgrade response
> HTTP/1.1 101 Switching Protocols
> Date: Sun, 05 Apr 2015 15:37:58 GMT
> Connection: Upgrade
> Via: http/1.1 ATS (ApacheTrafficServer/5.3.0 [c s f ])
> Server: ATS/5.3.0
> Upgrade: h2c-14
> [  0.066] HTTP Upgrade success
> [  0.066] recv SETTINGS frame 

[jira] [Updated] (TS-3498) h2c (upgrade dance) seems to hang

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3498:
---
Fix Version/s: (was: sometime)
   7.0.0

> h2c (upgrade dance) seems to hang
> -
>
> Key: TS-3498
> URL: https://issues.apache.org/jira/browse/TS-3498
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I see
> {code}
> loki (09:37) 259/0 $ nghttp -v -u http://docs.trafficserver.apache.org
> [  0.031] Connected
> [  0.031] HTTP Upgrade request
> GET / HTTP/1.1
> Host: docs.trafficserver.apache.org
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c-14
> HTTP2-Settings: AAMAAABkAAQAAP__
> Accept: */*
> User-Agent: nghttp2/0.7.4-DEV
> [  0.066] HTTP Upgrade response
> HTTP/1.1 101 Switching Protocols
> Date: Sun, 05 Apr 2015 15:37:58 GMT
> Connection: Upgrade
> Via: http/1.1 ATS (ApacheTrafficServer/5.3.0 [c s f ])
> Server: ATS/5.3.0
> Upgrade: h2c-14
> [  0.066] HTTP Upgrade success
> [  0.066] recv SETTINGS frame 

[jira] [Updated] (TS-3498) h2c (upgrade dance) seems to hang

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3498:
---
Assignee: (was: Ryo Okubo)

> h2c (upgrade dance) seems to hang
> -
>
> Key: TS-3498
> URL: https://issues.apache.org/jira/browse/TS-3498
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> I see
> {code}
> loki (09:37) 259/0 $ nghttp -v -u http://docs.trafficserver.apache.org
> [  0.031] Connected
> [  0.031] HTTP Upgrade request
> GET / HTTP/1.1
> Host: docs.trafficserver.apache.org
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c-14
> HTTP2-Settings: AAMAAABkAAQAAP__
> Accept: */*
> User-Agent: nghttp2/0.7.4-DEV
> [  0.066] HTTP Upgrade response
> HTTP/1.1 101 Switching Protocols
> Date: Sun, 05 Apr 2015 15:37:58 GMT
> Connection: Upgrade
> Via: http/1.1 ATS (ApacheTrafficServer/5.3.0 [c s f ])
> Server: ATS/5.3.0
> Upgrade: h2c-14
> [  0.066] HTTP Upgrade success
> [  0.066] recv SETTINGS frame 

[jira] [Updated] (TS-3508) Use accept4 on linux systems where available to reduce system calls

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3508:
---
Summary: Use accept4 on linux systems where available to reduce system 
calls  (was: use accept4 on linux systems where available to reduce system 
calls)

> Use accept4 on linux systems where available to reduce system calls
> ---
>
> Key: TS-3508
> URL: https://issues.apache.org/jira/browse/TS-3508
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Network
>Reporter: John Plevyak
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>
> The accept4() syscall can set flags on the accepted socket.



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

[jira] [Updated] (TS-3494) Expose the "name" (e.g. [ET_NET 0]) in the Thread class

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3494:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Expose the "name" (e.g. [ET_NET 0]) in the Thread class
> ---
>
> Key: TS-3494
> URL: https://issues.apache.org/jira/browse/TS-3494
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> This would allow our code to e.g. produce Debug() and other info with details 
> on what type of thread, and its # (to match up with e.g. top output). I think 
> this is a trivial addition, e.g.
> const char* Thread::get_name() const { return name; };



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

[jira] [Commented] (TS-3472) SNI proxy like feature for TS

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3472:


Leif says "this has success written all over it"

> SNI proxy like feature for TS
> -
>
> Key: TS-3472
> URL: https://issues.apache.org/jira/browse/TS-3472
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Zhao Yongming
>Assignee: Alan M. Carroll
>  Labels: newbie
> Fix For: sometime
>
>
> when doing forward proxy only setup, the sniproxy: 
> https://github.com/dlundquist/sniproxy.git is a very tiny but cool effort to 
> setup a TLS layer proxy with SNI, very good for some dirty tasks.
> in ATS, there is already a very good support in all those basic components, 
> add SNI blind proxy should be a very good feature, with tiny small changes 
> maybe.
> SNI in TLS, will extent the proxy(on caching) into all TLS based services, 
> such as mail etc.



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

[jira] [Updated] (TS-3473) Add TSCacheVConnPRead and TSCacheVConnPReadCapable

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3473:
---
Summary: Add TSCacheVConnPRead and TSCacheVConnPReadCapable  (was: add 
TSCacheVConnPRead and TSCacheVConnPReadCapable)

> Add TSCacheVConnPRead and TSCacheVConnPReadCapable
> --
>
> Key: TS-3473
> URL: https://issues.apache.org/jira/browse/TS-3473
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Cache, TS API
>Reporter: portl4t
>  Labels: review
> Fix For: sometime
>
>
> I think we need this two api to read from cache with an offset.



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

[jira] [Updated] (TS-3472) SNI proxy like feature for TS

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3472:
---
Assignee: Alan M. Carroll

> SNI proxy like feature for TS
> -
>
> Key: TS-3472
> URL: https://issues.apache.org/jira/browse/TS-3472
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Zhao Yongming
>Assignee: Alan M. Carroll
>  Labels: newbie
> Fix For: sometime
>
>
> when doing forward proxy only setup, the sniproxy: 
> https://github.com/dlundquist/sniproxy.git is a very tiny but cool effort to 
> setup a TLS layer proxy with SNI, very good for some dirty tasks.
> in ATS, there is already a very good support in all those basic components, 
> add SNI blind proxy should be a very good feature, with tiny small changes 
> maybe.
> SNI in TLS, will extent the proxy(on caching) into all TLS based services, 
> such as mail etc.



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

[jira] [Work logged] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/868
  
@PSUdaemon, tested the change and it seems it worked.

WITHOUT the fix:

```
Per-node process memory usage (in MBs) for PID 33486 ([ET_NET 0])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.101.933.04
Private 188774.4058365.61   247140.01
  --- --- ---
Total   188775.5058367.55   247143.05
```

WITH the fix:

```
Per-node process memory usage (in MBs) for PID 19187 ([ET_NET 0])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.050.581.63
Private 117512.30   118122.88   235635.18
  --- --- ---
Total   117513.35   118123.46   235636.80
```


Issue Time Tracking
---

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

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[GitHub] trafficserver issue #868: TS-4719: Make AIO threads interleave memory across...

[gtenev]

Github user gtenev commented on the issue:

https://github.com/apache/trafficserver/pull/868
  
@PSUdaemon, tested the change and it seems it worked.

WITHOUT the fix:

```
Per-node process memory usage (in MBs) for PID 33486 ([ET_NET 0])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.101.933.04
Private 188774.4058365.61   247140.01
  --- --- ---
Total   188775.5058367.55   247143.05
```

WITH the fix:

```
Per-node process memory usage (in MBs) for PID 19187 ([ET_NET 0])
   Node 0  Node 1   Total
  --- --- ---
Huge 0.000.000.00
Heap 0.000.000.00
Stack1.050.581.63
Private 117512.30   118122.88   235635.18
  --- --- ---
Total   117513.35   118123.46   235636.80
```


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

[jira] [Updated] (TS-3472) SNI proxy like feature for TS

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3472:
---
Labels: newbie  (was: )

> SNI proxy like feature for TS
> -
>
> Key: TS-3472
> URL: https://issues.apache.org/jira/browse/TS-3472
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Zhao Yongming
>  Labels: newbie
> Fix For: sometime
>
>
> when doing forward proxy only setup, the sniproxy: 
> https://github.com/dlundquist/sniproxy.git is a very tiny but cool effort to 
> setup a TLS layer proxy with SNI, very good for some dirty tasks.
> in ATS, there is already a very good support in all those basic components, 
> add SNI blind proxy should be a very good feature, with tiny small changes 
> maybe.
> SNI in TLS, will extent the proxy(on caching) into all TLS based services, 
> such as mail etc.



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

[jira] [Work logged] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[jira] [Updated] (TS-3472) SNI proxy like feature for TS

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3472:
---
Summary: SNI proxy like feature for TS  (was: SNI proxy alike feature for 
TS)

> SNI proxy like feature for TS
> -
>
> Key: TS-3472
> URL: https://issues.apache.org/jira/browse/TS-3472
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: SSL
>Reporter: Zhao Yongming
> Fix For: sometime
>
>
> when doing forward proxy only setup, the sniproxy: 
> https://github.com/dlundquist/sniproxy.git is a very tiny but cool effort to 
> setup a TLS layer proxy with SNI, very good for some dirty tasks.
> in ATS, there is already a very good support in all those basic components, 
> add SNI blind proxy should be a very good feature, with tiny small changes 
> maybe.
> SNI in TLS, will extent the proxy(on caching) into all TLS based services, 
> such as mail etc.



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

[GitHub] trafficserver pull request #868: TS-4719: Make AIO threads interleave memory...

[zwoop]

Github user zwoop closed the pull request at:

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


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

[jira] [Resolved] (TS-3435) Make Log.cc:PERIODIC_TASKS_INTERVAL configurable

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-3435.

Resolution: Fixed

> Make Log.cc:PERIODIC_TASKS_INTERVAL configurable
> 
>
> Key: TS-3435
> URL: https://issues.apache.org/jira/browse/TS-3435
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Frank Chan
>Priority: Minor
>  Labels: newbie
> Fix For: 7.0.0
>
>
> It seems proxy.config.log.max_secs_per_buffer doesn't work below 5 secs.
> Apparently, it is because Log.cc:PERIODIC_TASKS_INTERVAL is set to 5 secs.
> There are comments from the code that this may be configurable in future and 
> guess it may fix the issue.
> Thanks!



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

[jira] [Updated] (TS-3435) Make Log.cc:PERIODIC_TASKS_INTERVAL configurable

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3435:
---
Fix Version/s: (was: sometime)
   7.0.0

> Make Log.cc:PERIODIC_TASKS_INTERVAL configurable
> 
>
> Key: TS-3435
> URL: https://issues.apache.org/jira/browse/TS-3435
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Frank Chan
>Priority: Minor
>  Labels: newbie
> Fix For: 7.0.0
>
>
> It seems proxy.config.log.max_secs_per_buffer doesn't work below 5 secs.
> Apparently, it is because Log.cc:PERIODIC_TASKS_INTERVAL is set to 5 secs.
> There are comments from the code that this may be configurable in future and 
> guess it may fix the issue.
> Thanks!



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

[jira] [Commented] (TS-4265) Provide per EThread and per event type thread initialization.

[Phil Sorber (JIRA)]

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

Phil Sorber commented on TS-4265:
-

Make sure you allocate stack memory on the proper node and pass it into the 
thread creation.

> Provide per EThread and per event type thread initialization.
> -
>
> Key: TS-4265
> URL: https://issues.apache.org/jira/browse/TS-4265
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> As far as I can tell, {{EThread::schedule_spawn}} is is not used and is just 
> a crippled version of {{EThread::schedule_imm}}  without the optional 
> arguments.
> It would be better to make this call provide a mechanism to schedule 
> continuations that are called when a thread is spawned. This enable a lot of 
> cleanup of some very ugly thread initialization logic while at the same time 
> avoiding potential ugly race conditions. For instance {{NetHandler}} is 
> initialized in each thread *after* the thread is already running but before 
> (hopefully) any I/O events arrive. It would be much cleaner to do that in a 
> thread spawn event. Further this would decouple some initialization logic and 
> thread logic (as in this case) - the initalization logic would no longer need 
> to know anything about thread start up other than {{EThread::schedule_spawn}}.



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

[jira] [Closed] (TS-3411) Add stat to track total number of network connections

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs closed TS-3411.
--
Resolution: Won't Fix

As I've worked in this area some more, just using the http2 specific client 
counts combined with the http1 specific client counts seems to work just fine.  
Closing for now.

> Add stat to track total number of network connections
> -
>
> Key: TS-3411
> URL: https://issues.apache.org/jira/browse/TS-3411
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network, Performance
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> Currently, we can use proxy.process.http.total_client_connections or 
> proxy.process.http.total_incoming_connections to determine the number of TCP 
> connections that have been made from the user_agent to ATS, assuming that 
> HTTP/1.0 or HTTP/1.1 are used.
> If SPDY or HTTP/2 are used, these counters will be incremented for each 
> stream not for each network connection.
> It would be useful to add counters in the iocore/net area to directly track 
> the number of TCP connections that have been open over time.  Right now only 
> the number of currently_open connections are tracked via 
> proxy.process.net.connections_currently_open.
> I propose adding two new metrics proxy.process.net.connections_successful_in 
> and proxy.process.net.connections_successful_out



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

[jira] [Closed] (TS-3434) Remove unnecessary usage of "squid" from the code

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3434.
--
   Resolution: Invalid
Fix Version/s: (was: sometime)

Reporter doesn't know what he is talking about.

> Remove unnecessary usage of "squid" from the code
> -
>
> Key: TS-3434
> URL: https://issues.apache.org/jira/browse/TS-3434
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Cleanup
>Reporter: Phil Sorber
>Priority: Trivial
>
> This term is used heavily in the code in areas that were presumably meant to 
> be compatible with squid. I think we should remove it where possible and move 
> things like the squid log format into a default config file instead of being 
> in the code.



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

[jira] [Closed] (TS-3433) Use extra memory than expected

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3433.
--
   Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)

> Use extra memory than expected
> --
>
> Key: TS-3433
> URL: https://issues.apache.org/jira/browse/TS-3433
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: pjack
>
> the storage size is 16G, and ram_cache.size use the default value : (-1)
> I expect the memory of the process should be less than 200MB, but it used 
> 1.5G and more until my server out of memory.
> I checked the ram_cache size and I found bytes_used > total_bytes.
> OS: Ubuntu 12.04 with 3.13.0-32 kernal
> traffic server version: 4.2.3
> $curl http://localhost:8080/_status | grep ram
> "proxy.process.cache.ram_cache.total_bytes": "13410304",
> "proxy.process.cache.ram_cache.bytes_used": "133754880",
> "proxy.process.cache.ram_cache.hits": "12322",
> "proxy.process.cache.ram_cache.misses": "55584",
> But if I setup the ram_cache.size to a fixed value, then the bytes_used will 
> be always smaller than total_bytes. Please let me know if it is a correct 
> scenario or some kind of bug?
> Thanks!
>  



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

[jira] [Work logged] (TS-4523) Add the ability to pause/resume data consumption in the CPP API

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/712
  
The reason for wanting this feature is to support prolonged content related 
actions -- in @davidbz  case out-of-process content malware analysis.

When acting as a forward proxy and handling a request for a very large 
file, he needs to support an initial analysis on the first N MBs of the file in 
order to decide if he must analyze the full file or can release it to the 
client.
This analysis can take a significant amount of time and continuing to 
buffer the contents can lead to resource exhaustion.
(When combined with turning on flow control to make sure that we throttle 
the proxy<->upstream tcp connection)

@bgaff - I know you had some concerns regarding this - does this use case 
seem reasonable to you?


Issue Time Tracking
---

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

> Add the ability to pause/resume data consumption in the CPP API
> ---
>
> Key: TS-4523
> URL: https://issues.apache.org/jira/browse/TS-4523
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: David Ben Zakai
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I'd like to suggest an API change in the CPP API Transformation interface.
> My own use case is that I'd like to be able to pause the transformation, 
> handle what I can from the file and release the buffered content before 
> resuming and releasing the rest of the data.
> Basically what I'm trying to achieve:
> Write data to file (up to a certain amount)
> File analysis
> Produce file data (and any leftovers) downstream
> When the file size reaches a certain size limit I'd like to be able to pause 
> the transformation and produce all of its content downstream and then resume 
> the transformation.
> API Changes:
> TransformationPlugin.h:
> /**
> * Call this method if you wish to pause the transformation.
> * Schedule the return value continuation to resume the transforamtion.
> * If the continuation is scheduled and called after the transform is 
> destroyed it will 
> * won't do anything beyond cleanups.
> * Note: You must schedule the continuation or destroy it (using 
> TSContDestroy) yourself, 
> * otherwise it will leak.
> */
> TSCont pause();
> Internally, the continuation wraps the "resumeCallback" static function:
> static int resumeCallback(TSCont cont, TSEvent event, void *edata); /** 
> Resume callback*/
> Thank you!



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

[GitHub] trafficserver issue #712: TS-4523 - Add pause functionality to the Transform...

[ushachar]

Github user ushachar commented on the issue:

https://github.com/apache/trafficserver/pull/712
  
The reason for wanting this feature is to support prolonged content related 
actions -- in @davidbz  case out-of-process content malware analysis.

When acting as a forward proxy and handling a request for a very large 
file, he needs to support an initial analysis on the first N MBs of the file in 
order to decide if he must analyze the full file or can release it to the 
client.
This analysis can take a significant amount of time and continuing to 
buffer the contents can lead to resource exhaustion.
(When combined with turning on flow control to make sure that we throttle 
the proxy<->upstream tcp connection)

@bgaff - I know you had some concerns regarding this - does this use case 
seem reasonable to you?


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

[jira] [Updated] (TS-3426) Consolidate the multiple API for disabling cache

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3426:
---
Fix Version/s: (was: 7.0.0)
   8.0.0

> Consolidate the multiple API for disabling cache
> 
>
> Key: TS-3426
> URL: https://issues.apache.org/jira/browse/TS-3426
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 8.0.0
>
> Attachments: IMG_3001.jpg
>
>
> There are currently multiple API (see below) that can be used by a plugin to 
> disable cache for a given transaction. 
> {{TSHttpTxnServerRespNoStoreSet}}, {{TSHttpTxnReqCacheableSet}}, 
> {{TSHttpTxnRespCacheableSet}}
> Opening this jira to analyze whether these are redundant and consolidate if 
> necessary. 



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

[jira] [Updated] (TS-3374) Issues with cache.config implementation

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3374:
---
Component/s: (was: Cache)
 Documentation

> Issues with cache.config implementation
> ---
>
> Key: TS-3374
> URL: https://issues.apache.org/jira/browse/TS-3374
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Dan Morgan
>Assignee: Jon Sime
>  Labels: cache-control
> Fix For: Docs
>
>
> The documentation implies that entries in the cache.config file are processed 
> in 'order'.
> For example, this example in the docs:
> ---
> The following example configures Traffic Server to revalidate gif and jpeg 
> objects in the domain mydomain.com every 6 hours, and all other objects in 
> mydomain.com every hour. The rules are applied in the order listed.
> dest_domain=mydomain.com suffix=gif revalidate=6h
> dest_domain=mydomain.com suffix=jpeg revalidate=6h
> dest_domain=mydomain.com revalidate=1h
> ---
> However, running with version 5.1.2 and having the following lines:
> dest_domain=mydomain.com prefix=somepath suffix=js revalidate=7d
> dest_domain=mydomain.com suffix=js action=never-cache
> I would expect it to not cache any .js URL's from mydomain.com, except those 
> that have a prefix of 'somepath'.  However what happens is that the 
> action=never-cache is applied to all URL's having mydomain.com (even the ones 
> that have a prefix of 'somepath').



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

[jira] [Updated] (TS-3374) Issues with cache.config implementation

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3374:
---
Assignee: Jon Sime

> Issues with cache.config implementation
> ---
>
> Key: TS-3374
> URL: https://issues.apache.org/jira/browse/TS-3374
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Dan Morgan
>Assignee: Jon Sime
>  Labels: cache-control
> Fix For: Docs
>
>
> The documentation implies that entries in the cache.config file are processed 
> in 'order'.
> For example, this example in the docs:
> ---
> The following example configures Traffic Server to revalidate gif and jpeg 
> objects in the domain mydomain.com every 6 hours, and all other objects in 
> mydomain.com every hour. The rules are applied in the order listed.
> dest_domain=mydomain.com suffix=gif revalidate=6h
> dest_domain=mydomain.com suffix=jpeg revalidate=6h
> dest_domain=mydomain.com revalidate=1h
> ---
> However, running with version 5.1.2 and having the following lines:
> dest_domain=mydomain.com prefix=somepath suffix=js revalidate=7d
> dest_domain=mydomain.com suffix=js action=never-cache
> I would expect it to not cache any .js URL's from mydomain.com, except those 
> that have a prefix of 'somepath'.  However what happens is that the 
> action=never-cache is applied to all URL's having mydomain.com (even the ones 
> that have a prefix of 'somepath').



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

[jira] [Commented] (TS-3374) Issues with cache.config implementation

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3374:


cache.config can match all rules and doesn't stop on first match.

> Issues with cache.config implementation
> ---
>
> Key: TS-3374
> URL: https://issues.apache.org/jira/browse/TS-3374
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Dan Morgan
>Assignee: Jon Sime
>  Labels: cache-control
> Fix For: Docs
>
>
> The documentation implies that entries in the cache.config file are processed 
> in 'order'.
> For example, this example in the docs:
> ---
> The following example configures Traffic Server to revalidate gif and jpeg 
> objects in the domain mydomain.com every 6 hours, and all other objects in 
> mydomain.com every hour. The rules are applied in the order listed.
> dest_domain=mydomain.com suffix=gif revalidate=6h
> dest_domain=mydomain.com suffix=jpeg revalidate=6h
> dest_domain=mydomain.com revalidate=1h
> ---
> However, running with version 5.1.2 and having the following lines:
> dest_domain=mydomain.com prefix=somepath suffix=js revalidate=7d
> dest_domain=mydomain.com suffix=js action=never-cache
> I would expect it to not cache any .js URL's from mydomain.com, except those 
> that have a prefix of 'somepath'.  However what happens is that the 
> action=never-cache is applied to all URL's having mydomain.com (even the ones 
> that have a prefix of 'somepath').



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

[jira] [Updated] (TS-3374) Issues with cache.config implementation

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3374:
---
Fix Version/s: (was: sometime)
   Docs

> Issues with cache.config implementation
> ---
>
> Key: TS-3374
> URL: https://issues.apache.org/jira/browse/TS-3374
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Dan Morgan
>  Labels: cache-control
> Fix For: Docs
>
>
> The documentation implies that entries in the cache.config file are processed 
> in 'order'.
> For example, this example in the docs:
> ---
> The following example configures Traffic Server to revalidate gif and jpeg 
> objects in the domain mydomain.com every 6 hours, and all other objects in 
> mydomain.com every hour. The rules are applied in the order listed.
> dest_domain=mydomain.com suffix=gif revalidate=6h
> dest_domain=mydomain.com suffix=jpeg revalidate=6h
> dest_domain=mydomain.com revalidate=1h
> ---
> However, running with version 5.1.2 and having the following lines:
> dest_domain=mydomain.com prefix=somepath suffix=js revalidate=7d
> dest_domain=mydomain.com suffix=js action=never-cache
> I would expect it to not cache any .js URL's from mydomain.com, except those 
> that have a prefix of 'somepath'.  However what happens is that the 
> action=never-cache is applied to all URL's having mydomain.com (even the ones 
> that have a prefix of 'somepath').



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

[jira] [Updated] (TS-3348) Read while write config and range issues

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3348:
---
Summary: Read while write config and range issues  (was: read while write 
config and range issues)

> Read while write config and range issues
> 
>
> Key: TS-3348
> URL: https://issues.apache.org/jira/browse/TS-3348
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: William Bardwell
>Assignee: Alan M. Carroll
>  Labels: review
> Fix For: sometime
>
> Attachments: TS-3348.diff
>
>
> We had a number of problems with the read-while-write logic.
> #1) you can't set background fill config options to keep background fill from 
> behaving badly because they are shared too much with read-while-write
> #2) logic around filling range requests out of partial cache entries is too 
> restrictive
> #3) issues around read_while_write not working if there is a transform 
> anywhere
> #4) some related config is not overridable
> So we think that our patch fixes all of these issues...mostly.
> (The background fill timeout doesn't get re-instated if a download switches 
> to read-while-write and then back.  The Range is in cache code doesn't seem 
> write for small things or possibly for seeing the current fragment that is 
> only partially downloaded.)
> But we would like some review of this to see if we are doing anything 
> dangerous/not right/not helpful.
> Might also help TS-2761 and issue around range handling.



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

[jira] [Commented] (TS-3341) Add plugin APIs about server transaction status

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3341:


[~wbardwel]  Are you going to work on this?  If not please close.

> Add plugin APIs about server transaction status
> ---
>
> Key: TS-3341
> URL: https://issues.apache.org/jira/browse/TS-3341
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: William Bardwell
>Assignee: William Bardwell
> Fix For: sometime
>
>
> {code}
> // Indicates if the connection to the client was aborted,
> // will not be true if the client closed cleanly at the end
> // of the transaction.
> int
> TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
> {
>   sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
>   HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
>   return (s->client_info.abort == HttpTransact::ABORTED);
> }
> {code}
> {code}
> // Indicates if the transaction with the origin server is complete.
> // Will be true if the connection to the origin never started or
> // failed, as well as if it finished successfully.  If this is checked
> // to early or for a cache hit, it will return true.
> int
> TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
> {
>   sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
>   HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
>   return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
> (s->current.server ? (s->current.server->state == 
> HttpTransact::TRANSACTION_COMPLETE):false);
> }
> {code}



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

[jira] [Updated] (TS-3322) For a more stable build of plugins we should load them during test

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3322:
---
Assignee: Jason Kenny  (was: Thomas Jackson)

> For a more stable build of plugins we should load them during test
> --
>
> Key: TS-3322
> URL: https://issues.apache.org/jira/browse/TS-3322
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build, Plugins
>Reporter: Igor Galić
>Assignee: Jason Kenny
> Fix For: sometime
>
>
> currently we are building many (experimental) plugins without ever verifying 
> if they even load.
> perhaps we should have a smoke test that starts ats with all (built) plugins 
> in {{plugin.config}}
> a next step could be to actually test changed behaviour with remap plugins 
> for instance. but… baby steps ;)



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

[jira] [Closed] (TS-3317) Should we consider eliminating the mgmt_port aka backdoor_port ?

[Bryan Call (JIRA)]

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

Bryan Call closed TS-3317.
--
   Resolution: Won't Fix
Fix Version/s: (was: 7.0.0)

> Should we consider eliminating the mgmt_port aka backdoor_port ?
> 
>
> Key: TS-3317
> URL: https://issues.apache.org/jira/browse/TS-3317
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: incompatible
>
> Do we really need this? If the only thing in use today is for traffic_cop to 
> always be allowed a connection, maybe we can have some other mechanism ? 
> In either case, there's a bunch of additional stuff in there for the 
> backdoor_port, including proxy.config.url_remap.handle_backdoor_urls (off by 
> default).



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

[jira] [Updated] (TS-3322) For a more stable build of plugins we should load them during test

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3322:
---
Summary: For a more stable build of plugins we should load them during test 
 (was: for a more stable build of plugins we should load them during test)

> For a more stable build of plugins we should load them during test
> --
>
> Key: TS-3322
> URL: https://issues.apache.org/jira/browse/TS-3322
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build, Plugins
>Reporter: Igor Galić
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> currently we are building many (experimental) plugins without ever verifying 
> if they even load.
> perhaps we should have a smoke test that starts ats with all (built) plugins 
> in {{plugin.config}}
> a next step could be to actually test changed behaviour with remap plugins 
> for instance. but… baby steps ;)



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

[jira] [Commented] (TS-3317) Should we consider eliminating the mgmt_port aka backdoor_port ?

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3317:


No

> Should we consider eliminating the mgmt_port aka backdoor_port ?
> 
>
> Key: TS-3317
> URL: https://issues.apache.org/jira/browse/TS-3317
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: incompatible
> Fix For: 7.0.0
>
>
> Do we really need this? If the only thing in use today is for traffic_cop to 
> always be allowed a connection, maybe we can have some other mechanism ? 
> In either case, there's a bunch of additional stuff in there for the 
> backdoor_port, including proxy.config.url_remap.handle_backdoor_urls (off by 
> default).



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