[jira] [Updated] (TS-3130) Core dump in Logging
[
https://issues.apache.org/jira/browse/TS-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-3130:
Fix Version/s: 5.1.2
> Core dump in Logging
>
>
> Key: TS-3130
> URL: https://issues.apache.org/jira/browse/TS-3130
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 5.1.2, 5.2.0
>
>
> Seeing a core dump in logging when the configured log buffer is not
> sufficient to print a log.
> Here's the gdb back trace and some useful info:
> {code}
> (gdb) bt
> #0 0x00665fed in ink_atomic_increment (mem=0x68, count=-1)
> at ../../lib/ts/ink_atomic.h:89
> #1 0x00662c8e in LogObject::_checkout_write (this=0x264b6f0,
> write_offset=0x2ba25de4b508, bytes_needed=25376) at LogObject.cc:501
> #2 0x006632aa in LogObject::log (this=0x264b6f0, lad=0x2ba25de4b650,
> text_entry=0x0) at LogObject.cc:618
> #3 0x006659f6 in LogObjectManager::log (this=0x263c0e8,
> lad=0x2ba25de4b650) at LogObject.cc:1353
> #4 0x00641a74 in Log::access (lad=0x2ba25de4b650) at Log.cc:1096
> #5 0x005bab9b in HttpBodyTemplate::build_instantiated_buffer
> (this=0x2a1ccc0, context=0x2ba4540c4a78, buflen_return=0x2ba25de4c1c8) at
> HttpBodyFactory.cc:1011
> #6 0x005b92a0 in HttpBodyFactory::fabricate (this=0x29f8820,
> acpt_language_list=0x2ba25de4bd60, acpt_charset_list=0x2ba25de4bc00,
> type=0x78c323 "urlrouting#no_mapping", context=0x2ba4540c4a78,
> buffer_length_return=0x2ba25de4c1c8,
> content_language_return=0x2ba25de4bed8,
> content_charset_return=0x2ba25de4bed0, set_return=0x2ba25de4bec8) at
> HttpBodyFactory.cc:448
> #7 0x005b8422 in HttpBodyFactory::fabricate_with_old_api(const char
> *, HttpTransact::State *, int64_t, int64_t *, char *, size_t, char *, size_t,
> const char *, typedef __va_list_tag __va_list_tag *) (
> this=0x29f8820, type=0x78c323 "urlrouting#no_mapping",
> context=0x2ba4540c4a78, max_buffer_length=8192,
> resulting_buffer_length=0x2ba25de4c1c8,
> content_language_out_buf=0x2ba25de4c090 "en",
> content_language_buf_size=256, content_type_out_buf=0x2ba25de4bf90
> "text/html", content_type_buf_size=256, format=0x0, ap=0x2ba25de4c1d0) at
> HttpBodyFactory.cc:138
> #8 0x006091fe in HttpTransact::build_error_response
> (s=0x2ba4540c4a78, status_code=HTTP_STATUS_NOT_FOUND,
> reason_phrase_or_null=0x78c339 "Not Found on Accelerator",
> error_body_type=0x78c323 "urlrouting#no_mapping", format=0x0) at
> HttpTransact.cc:8071
> #9 0x005eab76 in HttpTransact::EndRemapRequest (s=0x2ba4540c4a78) at
> HttpTransact.cc:925
> #10 0x005ddbfd in HttpSM::call_transact_and_set_next_state
> (this=0x2ba4540c4a10, f=0) at HttpSM.cc:6834
> #11 0x005ddee4 in HttpSM::set_next_state (this=0x2ba4540c4a10) at
> HttpSM.cc:6892
> #12 0x005ddd3a in HttpSM::call_transact_and_set_next_state
> (this=0x2ba4540c4a10, f=0) at HttpSM.cc:6842
> #13 0x005cc2b3 in HttpSM::handle_api_return (this=0x2ba4540c4a10) at
> HttpSM.cc:1507
> #14 0x005cc110 in HttpSM::state_api_callout (this=0x2ba4540c4a10,
> event=0, data=0x0) at HttpSM.cc:1439
> #15 0x005d7605 in HttpSM::do_api_callout_internal
> (this=0x2ba4540c4a10) at HttpSM.cc:4800
> #16 0x005e4010 in HttpSM::do_api_callout (this=0x2ba4540c4a10) at
> HttpSM.cc:445
> #17 0x005ddda0 in HttpSM::set_next_state (this=0x2ba4540c4a10) at
> HttpSM.cc:6876
> #18 0x005ddd3a in HttpSM::call_transact_and_set_next_state
> (this=0x2ba4540c4a10, f=0) at HttpSM.cc:6842
> #19 0x005cc2b3 in HttpSM::handle_api_return (this=0x2ba4540c4a10) at
> HttpSM.cc:1507
> #20 0x005cc110 in HttpSM::state_api_callout (this=0x2ba4540c4a10,
> event=0, data=0x0) at HttpSM.cc:1439
> #21 0x005d7605 in HttpSM::do_api_callout_internal
> (this=0x2ba4540c4a10) at HttpSM.cc:4800
> #22 0x005e4010 in HttpSM::do_api_callout (this=0x2ba4540c4a10) at
> HttpSM.cc:445
> #23 0x005ddda0 in HttpSM::set_next_state (this=0x2ba4540c4a10) at
> HttpSM.cc:6876
> #24 0x005ddd3a in HttpSM::call_transact_and_set_next_state
> (this=0x2ba4540c4a10, f=0x5ec2ce
> ) at HttpSM.cc:6842
> #25 0x005ca241 in HttpSM::state_read_client_request_header
> (this=0x2ba4540c4a10, event=100, data=0x2ba2e54a5e80) at HttpSM.cc:763
> #26 0x005cf652 in HttpSM::main_handler (this=0x2ba4540c4a10,
> event=100, data=0x2ba2e54a5e80) at HttpSM.cc:2500
> #27 0x004f4f18 in Continuation::handleEvent (this=0x2ba4540c4a10,
> event=100, data=0x2ba2e54a5e80) at ../iocore/eventsystem/I_Continuation.h:146
> #28 0x00732faf in read_signal_and_update (event=100,
> vc=0x2ba2e54a5d70) at UnixNetVConnection.c
[jira] [Created] (TS-3241) Compile warnings on secure-link example
Leif Hedstrom created TS-3241:
-
Summary: Compile warnings on secure-link example
Key: TS-3241
URL: https://issues.apache.org/jira/browse/TS-3241
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Leif Hedstrom
{code}
CC secure-link/secure-link.lo
secure-link/secure-link.c:69:1973: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
if(__extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p
(ptr) && __builtin_constant_p ("st") && (__s1_len = strlen (ptr), __s2_len =
strlen ("st"), (!((size_t)(const void *)((ptr) + 1) - (size_t)(const void
*)(ptr) == 1) || __s1_len >= 4) && (!((size_t)(const void *)(("st") + 1) -
(size_t)(const void *)("st") == 1) || __s2_len >= 4)) ? __builtin_strcmp (ptr,
"st") : (__builtin_constant_p (ptr) && ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) && (__s1_len = strlen (ptr), __s1_len < 4) ?
(__builtin_constant_p ("st") && ((size_t)(const void *)(("st") + 1) -
(size_t)(const void *)("st") == 1) ? __builtin_strcmp (ptr, "st") :
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) ("st"); int __result = (((const unsigned char *) (const char *)
(ptr))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const
unsigned char *) (const char *) (ptr))[1] - __s2[1]); if (__s1_len > 1 &&
__result == 0) { __result = (((const unsigned char *) (const char *) (ptr))[2]
- __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned
char *) (const char *) (ptr))[3] - __s2[3]); } } __result; }))) :
(__builtin_constant_p ("st") && ((size_t)(const void *)(("st") + 1) -
(size_t)(const void *)("st") == 1) && (__s2_len = strlen ("st"), __s2_len < 4)
? (__builtin_constant_p (ptr) && ((size_t)(const void *)((ptr) + 1) -
(size_t)(const void *)(ptr) == 1) ? __builtin_strcmp (ptr, "st") : (-
(__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
char *) (ptr); int __result = (((const unsigned char *) (const char *)
("st"))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const
unsigned char *) (const char *) ("st"))[1] - __s2[1]); if (__s2_len > 1 &&
__result == 0) { __result = (((const unsigned char *) (const char *) ("st"))[2]
- __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned
char *) (const char *) ("st"))[3] - __s2[3]); } } __result; } :
__builtin_strcmp (ptr, "st"; }) == 0) {
^ ~
secure-link/secure-link.c:71:1980: warning: array index 3 is past the end of
the array (which contains 3 elements) [-Warray-bounds]
} else if(__extension__ ({ size_t __s1_len, __s2_len;
(__builtin_constant_p (ptr) && __builtin_constant_p ("ex") && (__s1_len =
strlen (ptr), __s2_len = strlen ("ex"), (!((size_t)(const void *)((ptr) + 1) -
(size_t)(const void
[jira] [Updated] (TS-3241) Compile warnings on secure-link example
[
https://issues.apache.org/jira/browse/TS-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3241:
--
Fix Version/s: 5.3.0
> Compile warnings on secure-link example
> ---
>
> Key: TS-3241
> URL: https://issues.apache.org/jira/browse/TS-3241
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 5.3.0
>
>
> {code}
> CC secure-link/secure-link.lo
> secure-link/secure-link.c:69:1973: warning: array index 3 is past the end of
> the array (which contains 3 elements) [-Warray-bounds]
> if(__extension__ ({ size_t __s1_len, __s2_len;
> (__builtin_constant_p (ptr) && __builtin_constant_p ("st") && (__s1_len =
> strlen (ptr), __s2_len = strlen ("st"), (!((size_t)(const void *)((ptr) + 1)
> - (size_t)(const void *)(ptr) == 1) || __s1_len >= 4) && (!((size_t)(const
> void *)(("st") + 1) - (size_t)(const void *)("st") == 1) || __s2_len >= 4)) ?
> __builtin_strcmp (ptr, "st") : (__builtin_constant_p (ptr) && ((size_t)(const
> void *)((ptr) + 1) - (size_t)(const void *)(ptr) == 1) && (__s1_len = strlen
> (ptr), __s1_len < 4) ? (__builtin_constant_p ("st") && ((size_t)(const void
> *)(("st") + 1) - (size_t)(const void *)("st") == 1) ? __builtin_strcmp (ptr,
> "st") : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *)
> (const char *) ("st"); int __result = (((const unsigned char *) (const char
> *) (ptr))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result =
> (((const unsigned char *) (const char *) (ptr))[1] - __s2[1]); if (__s1_len >
> 1 && __result == 0) { __result = (((const unsigned char *) (const char *)
> (ptr))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const
> unsigned char *) (const char *) (ptr))[3] - __s2[3]); } } __result; }))) :
> (__builtin_constant_p ("st") && ((size_t)(const void *)(("st") + 1) -
> (size_t)(const void *)("st") == 1) && (__s2_len = strlen ("st"), __s2_len <
> 4) ? (__builtin_constant_p (ptr) && ((size_t)(const void *)((ptr) + 1) -
> (size_t)(const void *)(ptr) == 1) ? __builtin_strcmp (ptr, "st") : (-
> (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const
> char *) (ptr); int __result = (((const unsigned char *) (const char *)
> ("st"))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result =
> (((const unsigned char *) (const char *) ("st"))[1] - __s2[1]); if (__s2_len
> > 1 && __result == 0) { __result = (((const unsigned char *) (const char *)
> ("st"))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const
> unsigned char *) (const char *) ("st"))[3] - __s2[3]); } } __result; } :
> __builtin_strcmp (ptr, "st"; }) == 0) {
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ^ ~
> secure-link/secure-link.c:71:1980: warning: a
[jira] [Updated] (TS-1001) reload the changes in dns.resolv_conf
[ https://issues.apache.org/jira/browse/TS-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1001: -- Fix Version/s: (was: 5.2.0) > reload the changes in dns.resolv_conf > - > > Key: TS-1001 > URL: https://issues.apache.org/jira/browse/TS-1001 > Project: Traffic Server > Issue Type: Wish > Components: DNS >Reporter: Conan Wang >Assignee: Leif Hedstrom >Priority: Trivial > Labels: A > > a trivial wish: ATS can reload (traffic_line -x) resolv.conf if nameserver > changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2503) dynamic TLS record size tuning
[
https://issues.apache.org/jira/browse/TS-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2503:
--
Issue Type: New Feature (was: Improvement)
> dynamic TLS record size tuning
> --
>
> Key: TS-2503
> URL: https://issues.apache.org/jira/browse/TS-2503
> Project: Traffic Server
> Issue Type: New Feature
> Components: Performance, SSL
>Reporter: James Peach
>Assignee: Sudheer Vinukonda
> Fix For: 5.2.0
>
> Attachments: TS-2503.diff
>
>
> From [~igrigorik] in TS-2365:
> {quote}
> FWIW, I think you may be interested in this discussion:
> - http://mailman.nginx.org/pipermail/nginx-devel/2013-December/004703.html
> - http://mailman.nginx.org/pipermail/nginx-devel/2014-January/004748.html
> In a nutshell, static record size introduces an inherent tradeoff between
> latency and throughput -- smaller records are good for latency, but hurt
> server throughput by adding bytes and CPU overhead. It would be great if we
> could implement a smarter strategy in ATS. The extra benefit is that it's one
> less knob to tune: the out-of-the-box experience would be better optimized
> for all ATS users, regardless of mix/type of traffic being proxies.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2417) Add forward secrecy support with DHE (SSL related)
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2417: -- Issue Type: New Feature (was: Improvement) > Add forward secrecy support with DHE (SSL related) > -- > > Key: TS-2417 > URL: https://issues.apache.org/jira/browse/TS-2417 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, SSL >Reporter: Bryan Call >Assignee: John Eaglesham > Fix For: 5.2.0 > > Attachments: ats_dhe-2.patch, ats_dhe-3.patch > > > mod_ssl bug and changes: > https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 > Discussion on httpd-dev list: > http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1432) API is missing TSMutexDestroy
[ https://issues.apache.org/jira/browse/TS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1432: -- Issue Type: New Feature (was: Improvement) > API is missing TSMutexDestroy > - > > Key: TS-1432 > URL: https://issues.apache.org/jira/browse/TS-1432 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 3.3.4 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.2.0 > > > pthread_mutex_destory on a TSMutex would cause a leak, this API is really > necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3101) Add TSHttpHdrHostGet
[ https://issues.apache.org/jira/browse/TS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3101: -- Assignee: Alan M. Carroll > Add TSHttpHdrHostGet > > > Key: TS-3101 > URL: https://issues.apache.org/jira/browse/TS-3101 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 5.2.0 > > > Plugins should be able to get the host directly from the HTTP header and not > do the URL vs. entity field logic every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3101) Add TSHttpHdrHostGet
[ https://issues.apache.org/jira/browse/TS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3101: -- Issue Type: New Feature (was: Improvement) > Add TSHttpHdrHostGet > > > Key: TS-3101 > URL: https://issues.apache.org/jira/browse/TS-3101 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Reporter: Alan M. Carroll > Fix For: 5.2.0 > > > Plugins should be able to get the host directly from the HTTP header and not > do the URL vs. entity field logic every time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3154) Add proxy port to access log
[
https://issues.apache.org/jira/browse/TS-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3154:
--
Summary: Add proxy port to access log (was: add proxy port to access log)
> Add proxy port to access log
>
>
> Key: TS-3154
> URL: https://issues.apache.org/jira/browse/TS-3154
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> https://github.com/apache/trafficserver/pull/125
> Add the proxy port as log tag {{php}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3233) Add drain option to restart API
[
https://issues.apache.org/jira/browse/TS-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3233:
--
Summary: Add drain option to restart API (was: add drain option to restart
API)
> Add drain option to restart API
> ---
>
> Key: TS-3233
> URL: https://issues.apache.org/jira/browse/TS-3233
> Project: Traffic Server
> Issue Type: Improvement
> Components: Management API, Tools
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a {{--drain}} option to the restart API . This lets an operator delay a
> restart or bounce until the number of client connections have dropped below a
> configurable threshold.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3054) Premature origin connection reset: flush partial data received to client before closing client connection
[
https://issues.apache.org/jira/browse/TS-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3054:
--
Summary: Premature origin connection reset: flush partial data received to
client before closing client connection (was: premature origin connection
reset: flush partial data received to client before closing client connection)
> Premature origin connection reset: flush partial data received to client
> before closing client connection
> -
>
> Key: TS-3054
> URL: https://issues.apache.org/jira/browse/TS-3054
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, HTTP
>Affects Versions: 5.0.0, 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
> Attachments: ts-3054.patch
>
>
> Having a case with misbehaving online service in forwarding proxy mode: the
> origin server responds with chunked encoding, but closes the connection
> before sending the final 0\r\n\r\n chunk. I know it’s against the standards,
> but all browsers seem to be fine using the "partial" data received.
> It would be great to have the following logic implemented in ATS: in case of
> premature connection reset, forward and flush all available data before
> closing the second connection. Currently ATS seems to reset the connection
> without forwarding the partially available data.
> Here’s a real-life example:
> http://www.indiancivils.com/virtual/ShowVideoTrial.aspx?VidId=86
> Once the flash object on the above webpage is loaded it makes authorization
> request to
> http://www.authorlive.com/aliveext/ValidRecordingToken.aspx?t=13071753&r=2688:
> * client request
> {noformat}
> GET /aliveext/ValidRecordingToken.aspx?t=13071753&r=2688 HTTP/1.1
> Host: www.authorlive.com
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0)
> Gecko/20100101 Firefox/31.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Referer:
> http://ocnstream.s3.amazonaws.com/VCBLoader.swf?r=R4404876_V4&e=&l=1&c=1&t=13071753
> Connection: keep-alive
> {noformat}
> * server response
> {noformat}
> HTTP/1.1 200 OK
> Date: Sun, 31 Aug 2014 10:00:38 GMT
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> X-AspNet-Version: 4.0.30319
> Transfer-Encoding: chunked
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: -1
> Content-Type: application/xml;; charset=utf-8
> 34
> true
> {noformat}
> Here the origin server resets the connection without sending the closing
> chunk.
> ATS closes the client’s connection without forwarding the existing
> "34\r\ntrue" chunk.
> As a result the flash application complains with "You are not authorized to
> watch this recording !”, effectively prohibiting the user from watching the
> pre-recorded online class session.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3171) Tidy up Tokenizer interface
[ https://issues.apache.org/jira/browse/TS-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3171: -- Summary: Tidy up Tokenizer interface (was: tidy up Tokenizer interface) > Tidy up Tokenizer interface > --- > > Key: TS-3171 > URL: https://issues.apache.org/jira/browse/TS-3171 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach >Assignee: James Peach >Priority: Trivial > Fix For: 5.2.0 > > > Minor code improvements to tidy up the Tokenizer API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-898) Fix potential problems from coverity scan
[ https://issues.apache.org/jira/browse/TS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-898: - Summary: Fix potential problems from coverity scan (was: fix potential problems from coverity scan) > Fix potential problems from coverity scan > - > > Key: TS-898 > URL: https://issues.apache.org/jira/browse/TS-898 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0 > Environment: RHEL5 >Reporter: Bryan Call >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > Ran Coverity over the code and it reported 856 potential problems with the > code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2955) Support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2955:
--
Summary: Support variable expansion in set-redirect operator for
header_rewrite (was: support variable expansion in set-redirect operator for
header_rewrite)
> Support variable expansion in set-redirect operator for header_rewrite
> --
>
> Key: TS-2955
> URL: https://issues.apache.org/jira/browse/TS-2955
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: review, yahoo
> Fix For: 5.2.0
>
> Attachments: TS-2955.diff
>
>
> support variable expansion in set-redirect operator for header_rewrite to be
> able to dynamically substitute variables in the Location header (currently,
> only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2503) Dynamic TLS record size tuning
[
https://issues.apache.org/jira/browse/TS-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2503:
--
Summary: Dynamic TLS record size tuning (was: dynamic TLS record size
tuning)
> Dynamic TLS record size tuning
> --
>
> Key: TS-2503
> URL: https://issues.apache.org/jira/browse/TS-2503
> Project: Traffic Server
> Issue Type: New Feature
> Components: Performance, SSL
>Reporter: James Peach
>Assignee: Sudheer Vinukonda
> Fix For: 5.2.0
>
> Attachments: TS-2503.diff
>
>
> From [~igrigorik] in TS-2365:
> {quote}
> FWIW, I think you may be interested in this discussion:
> - http://mailman.nginx.org/pipermail/nginx-devel/2013-December/004703.html
> - http://mailman.nginx.org/pipermail/nginx-devel/2014-January/004748.html
> In a nutshell, static record size introduces an inherent tradeoff between
> latency and throughput -- smaller records are good for latency, but hurt
> server throughput by adding bytes and CPU overhead. It would be great if we
> could implement a smarter strategy in ATS. The extra benefit is that it's one
> less knob to tune: the out-of-the-box experience would be better optimized
> for all ATS users, regardless of mix/type of traffic being proxies.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3041) Add a way to show the installation layout
[
https://issues.apache.org/jira/browse/TS-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3041:
--
Summary: Add a way to show the installation layout (was: add a way to show
the installation layout)
> Add a way to show the installation layout
> -
>
> Key: TS-3041
> URL: https://issues.apache.org/jira/browse/TS-3041
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
> installation. Nuke the really annoying code that dumps the layout to stdout
> when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3044) Linux native AIO should use eventfd if available to signal thread
[ https://issues.apache.org/jira/browse/TS-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3044: -- Summary: Linux native AIO should use eventfd if available to signal thread (was: linux native AIO should use eventfd if available to signal thread) > Linux native AIO should use eventfd if available to signal thread > - > > Key: TS-3044 > URL: https://issues.apache.org/jira/browse/TS-3044 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Assignee: Phil Sorber > Fix For: 5.2.0 > > Attachments: native-aio-eventfd.patch > > > linux native AIO has the ability to signal the event thread to get off the > poll and service the disk via the io_set_eventfd() call. linux native AIO > scales better than the thread-based IO, but the current implementation can > introduce delays on lightly loaded systems because of the thread is waiting > on epoll(). This can be remedied by using io_set_eventfd -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2945) Balancer plugin forward to other port than 80
[ https://issues.apache.org/jira/browse/TS-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2945: -- Summary: Balancer plugin forward to other port than 80 (was: balancer plugin forward to other port than 80) > Balancer plugin forward to other port than 80 > - > > Key: TS-2945 > URL: https://issues.apache.org/jira/browse/TS-2945 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Thibault Marquand >Assignee: James Peach > Fix For: 5.2.0 > > > The balancer plugin can't load-balance on others ports than 80. > In documentation of the plugin, there is nothing about how to load-balance on > others ports. > Syntax in remap.config : > map http://foo.com http://foo.com @plugin=balancer.so > @pparam=--policy=hash,url @pparam=one.bar.com @pparam=two.bar.com > I obviously try this : > map http://foo.com http://foo.com @plugin=balancer.so > @pparam=--policy=hash,url @pparam=one.bar.com:8080 @pparam=two.bar.com:8080 > But ATS continues to hit on port 80 on my web server and in error.log I get > this : > status 502 (Connect Error ) for > 'http://two.bar.com:8080/' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1475) Static analysis: clean up all clang and coverity reports
[ https://issues.apache.org/jira/browse/TS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1475: -- Summary: Static analysis: clean up all clang and coverity reports (was: static analysis: clean up all clang and coverity reports) > Static analysis: clean up all clang and coverity reports > > > Key: TS-1475 > URL: https://issues.apache.org/jira/browse/TS-1475 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > the new report is in > https://ci.trafficserver.apache.org/files/clang-analyzer/latest/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3070) Consistent span configuration
[ https://issues.apache.org/jira/browse/TS-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3070: -- Summary: Consistent span configuration (was: consistent span configuration) > Consistent span configuration > - > > Key: TS-3070 > URL: https://issues.apache.org/jira/browse/TS-3070 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Core >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > Attachments: TS-3070.patch > > > The span configuration is not consistent across platforms because the code is > duplicated for Linux, Solaris and the BSD family. We should refactor this > code so that cache files and directories are handled consistently and only > the disk geometry probing is platform specific. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2506) Active request timeout leaves client hanging
[
https://issues.apache.org/jira/browse/TS-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2506:
--
Summary: Active request timeout leaves client hanging (was: active request
timeout leaves client hanging)
> Active request timeout leaves client hanging
>
>
> Key: TS-2506
> URL: https://issues.apache.org/jira/browse/TS-2506
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> If you set {{proxy.config.http.transaction_active_timeout_out}} and the
> origin response takes too long, the origin end of the HTTP tunnel will get
> shut down, but the user agent will never get notified. The user agent just
> keeps waiting for a response that will never come.
> The HTTP debug log looks like this:
> {code}
> + Proxy's Response 2 +
> -- State Machine Id: 1
> HTTP/1.1 200 OK
> Content-Type: text/plain
> Date: Thu, 16 Jan 2014 01:06:06 GMT
> Age: 0
> Transfer-Encoding: chunked
> Connection: keep-alive
> Server: ATS/4.2.0
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (call_transact_and_set_next_state)> (http) [1] State Transition:
> ORIGIN_SERVER_OPEN -> SERVER_READ
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (do_redirect)> (http_redirect) [HttpSM::do_redirect]
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (deallocate_redirect_postdata_buffers)> (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (add_producer)> (http_tunnel) [1] adding producer 'http server'
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (add_consumer)> (http_tunnel) [1] adding consumer 'user agent'
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (perform_cache_write_action)> (http) [1] perform_cache_write_action
> CACHE_DO_NO_ACTION
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (tunnel_run)> (http_tunnel) tunnel_run started, p_arg is NULL
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (do_io_write)> (http_cs) tcp_init_cwnd_set 0
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (set_tcp_init_cwnd)> (http_cs) desired TCP congestion window is 0
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (producer_run)> (http_tunnel) [producer_run] do_dechunking
> p->chunked_handler.chunked_reader->read_avail() = 184
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (producer_run)> (http_tunnel) [producer_run] do_dechunking
> p->chunked_handler.skip_bytes = 161
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (producer_handler)> (http_tunnel) [1] producer_handler [http server
> VC_EVENT_READ_READY]
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (producer_handler_chunked)> (http_tunnel) [1] producer_handler_chunked [http
> server VC_EVENT_READ_READY]
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (read_size)> (http_chunk) read chunk size of 17 bytes
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (read_chunk)> (http_chunk) completed read of chunk of 17 bytes
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (producer_handler)> (http_redirect) [HttpTunnel::producer_handler]
> enable_redirection: [1 0 0] event: 100
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (consumer_handler)> (http_tunnel) [1] consumer_handler [user agent
> VC_EVENT_WRITE_READY]
> [Jan 15 17:06:08.610] Server {0x109267000} DEBUG: (producer_handler)> (http_tunnel) [1] producer_handler [http server
> VC_EVENT_ACTIVE_TIMEOUT]
> [Jan 15 17:06:08.610] Server {0x109267000} DEBUG: (producer_handler_chunked)> (http_tunnel) [1] producer_handler_chunked [http
> server VC_EVENT_ACTIVE_TIMEOUT]
> [Jan 15 17:06:08.610] Server {0x109267000} DEBUG: (producer_handler)> (http_redirect) [HttpTunnel::producer_handler]
> enable_redirection: [1 0 0] event: 106
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (tunnel_handler_server)> (http) [1] [&HttpSM::tunnel_handler_server,
> VC_EVENT_ACTIVE_TIMEOUT]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (consumer_handler)> (http_tunnel) [1] consumer_handler [user agent
> VC_EVENT_WRITE_COMPLETE]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (tunnel_handler_ua)> (http) [1] [&HttpSM::tunnel_handler_ua,
> VC_EVENT_WRITE_COMPLETE]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (release)> (http_cs) [1] session released by sm [1]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (release)> (http_cs) [1] initiating io for next header
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (do_io_close)> (http_ss) [1] session closed
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (main_handler)> (http) [1] [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (tunnel_handler)> (http) [1] [&HttpSM::tunnel_ha
[jira] [Updated] (TS-3024) Build with OPENSSL_NO_SSL_INTERN
[
https://issues.apache.org/jira/browse/TS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3024:
--
Summary: Build with OPENSSL_NO_SSL_INTERN (was: build with
OPENSSL_NO_SSL_INTERN)
> Build with OPENSSL_NO_SSL_INTERN
>
>
> Key: TS-3024
> URL: https://issues.apache.org/jira/browse/TS-3024
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
> Attachments: ts-3024.patch
>
>
> I think we should enable {{OPENSSL_NO_SSL_INTERN}} to make ourselves more
> robust to OpenSSL implementation changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3042) Fix the static traffic_server build
[
https://issues.apache.org/jira/browse/TS-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3042:
--
Summary: Fix the static traffic_server build (was: fix the static
traffic_server build)
> Fix the static traffic_server build
> ---
>
> Key: TS-3042
> URL: https://issues.apache.org/jira/browse/TS-3042
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Restore the ability to link {{traffic_server}} statically, while linking the
> rest of the project dynamically.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1475) Static analysis: clean up all clang and coverity reports
[ https://issues.apache.org/jira/browse/TS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1475: -- Issue Type: Improvement (was: Bug) > Static analysis: clean up all clang and coverity reports > > > Key: TS-1475 > URL: https://issues.apache.org/jira/browse/TS-1475 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 3.3.0 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > the new report is in > https://ci.trafficserver.apache.org/files/clang-analyzer/latest/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2683) Add some control for which content to activate the background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2683: -- Issue Type: Improvement (was: New Feature) > Add some control for which content to activate the background_fetch plugin > -- > > Key: TS-2683 > URL: https://issues.apache.org/jira/browse/TS-2683 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > > This would be both in global and per-remap configurations. Such as, only > trigger background_fetch for certain content types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3041) Add a way to show the installation layout
[
https://issues.apache.org/jira/browse/TS-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3041:
--
Issue Type: Improvement (was: New Feature)
> Add a way to show the installation layout
> -
>
> Key: TS-3041
> URL: https://issues.apache.org/jira/browse/TS-3041
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> Add a new {{traffic_layout}} tool that shows the layout of the Traffic Server
> installation. Nuke the really annoying code that dumps the layout to stdout
> when you build with {--enable-debug}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2682) Add per remap configuration / activation to background_fetch
[ https://issues.apache.org/jira/browse/TS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2682: -- Issue Type: Improvement (was: New Feature) > Add per remap configuration / activation to background_fetch > > > Key: TS-2682 > URL: https://issues.apache.org/jira/browse/TS-2682 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3223) Fix the internal buffer sizing.
[ https://issues.apache.org/jira/browse/TS-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3223. --- Resolution: Fixed > Fix the internal buffer sizing. > --- > > Key: TS-3223 > URL: https://issues.apache.org/jira/browse/TS-3223 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Fix For: 5.1.2, 5.2.0 > > > Already committed, but forgot the lira. > 8b5f0345dade6b2822d9b52c8ad12e63011a5c12 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3097) Reloading SSL certificates crashes
[
https://issues.apache.org/jira/browse/TS-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3097:
--
Summary: Reloading SSL certificates crashes (was: reloading SSL
certificates crashes)
> Reloading SSL certificates crashes
> --
>
> Key: TS-3097
> URL: https://issues.apache.org/jira/browse/TS-3097
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
>Priority: Blocker
> Fix For: 5.2.0
>
>
> Using the {{ci/tsqa/test-ssl-certificates}} test, Traffic Server crashes when
> {{ssl_multicert.config}} is reloaded.
> {code}
> Thread 0 Crashed:: [ET_NET 0] Dispatch queue: com.apple.main-thread
> 0 libsystem_kernel.dylib 0x7fff8f174866 __pthread_kill + 10
> 1 libsystem_pthread.dylib 0x7fff938f035c pthread_kill + 92
> 2 libsystem_c.dylib 0x7fff923c2b1a abort + 125
> 3 libsystem_malloc.dylib 0x7fff9269607f free + 411
> 4 libtsutil.5.dylib 0x00010fd235f8 ats_free + 56
> (ink_memory.cc:124)
> 5 libcrypto.0.9.8.dylib 0x7fff941117d5 CRYPTO_free + 37
> 6 libssl.0.9.8.dylib 0x7fff91fce3dd SSL_CTX_free + 77
> 7 traffic_server 0x00010f3a0065
> SSLReleaseContext(ssl_ctx_st*) + 21 (SSLUtils.cc:1660)
> 8 traffic_server 0x00010f38d6b4
> SSLContextStorage::~SSLContextStorage() + 116 (SSLCertLookup.cc:239)
> 9 traffic_server 0x00010f38d095
> SSLContextStorage::~SSLContextStorage() + 21 (SSLCertLookup.cc:243)
> 10 traffic_server 0x00010f38d061
> SSLCertLookup::~SSLCertLookup() + 65 (SSLCertLookup.cc:127)
> 11 traffic_server 0x00010f38d0b5
> SSLCertLookup::~SSLCertLookup() + 21 (SSLCertLookup.cc:128)
> 12 traffic_server 0x00010f38d0d9
> SSLCertLookup::~SSLCertLookup() + 25 (SSLCertLookup.cc:126)
> 13 traffic_server 0x00010f2cfe07
> ConfigProcessor::release(unsigned int, RefCountObj*) + 327
> (ProxyConfig.cc:211)
> 14 traffic_server 0x00010f2d12bc
> ConfigInfoReleaser::handle_event(int, void*) + 60 (ProxyConfig.cc:107)
> 15 traffic_server 0x00010f0a2e47
> Continuation::handleEvent(int, void*) + 119 (I_Continuation.h:146)
> 16 traffic_server 0x00010f3d3998
> EThread::process_event(Event*, int) + 376 (UnixEThread.cc:144)
> 17 traffic_server 0x00010f3d3ede EThread::execute()
> + 782 (UnixEThread.cc:225)
> 18 traffic_server 0x00010f0edfec main + 7228
> (Main.cc:1668)
> 19 libdyld.dylib 0x7fff8a6c75fd start + 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TS-3096) After TS-2751 TSVConnClosedGet changed its behaviour
[ https://issues.apache.org/jira/browse/TS-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reopened TS-3096: --- Note sure why this was closed, reopening and moving to 5.3.0. > After TS-2751 TSVConnClosedGet changed its behaviour > > > Key: TS-3096 > URL: https://issues.apache.org/jira/browse/TS-3096 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Daniel Vitor Morilha >Priority: Critical > Fix For: 5.3.0 > > > One of our plug-ins initiates a background connection to an origin by using > TSHttpConnect API. > While handling the continuation events (WRITE, READ) the plug-in checks if > the vconnection is still open by calling TSVConnClosedGet(vconnection). > ATS recently changed the behavior. Now TSVConnClosedGet(vconnections) returns > a value different than 0 before any data can be retrieved. > If the call to TSVConnClosedGet is ignored the plug-in successfully writes > the request and receives the response. > By investigation our different Traffic Server versions the described change > seems to be related with TS-2751. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3096) After TS-2751 TSVConnClosedGet changed its behaviour
[ https://issues.apache.org/jira/browse/TS-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3096: -- Fix Version/s: (was: 5.2.0) 5.3.0 > After TS-2751 TSVConnClosedGet changed its behaviour > > > Key: TS-3096 > URL: https://issues.apache.org/jira/browse/TS-3096 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Daniel Vitor Morilha >Priority: Critical > Fix For: 5.3.0 > > > One of our plug-ins initiates a background connection to an origin by using > TSHttpConnect API. > While handling the continuation events (WRITE, READ) the plug-in checks if > the vconnection is still open by calling TSVConnClosedGet(vconnection). > ATS recently changed the behavior. Now TSVConnClosedGet(vconnections) returns > a value different than 0 before any data can be retrieved. > If the call to TSVConnClosedGet is ignored the plug-in successfully writes > the request and receives the response. > By investigation our different Traffic Server versions the described change > seems to be related with TS-2751. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3096) After TS-2751 TSVConnClosedGet changed its behaviour
[ https://issues.apache.org/jira/browse/TS-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-3096. --- Resolution: Duplicate Oh, this is a dupe of TS-3058. It just wasn't marked properly. > After TS-2751 TSVConnClosedGet changed its behaviour > > > Key: TS-3096 > URL: https://issues.apache.org/jira/browse/TS-3096 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Daniel Vitor Morilha >Priority: Critical > > One of our plug-ins initiates a background connection to an origin by using > TSHttpConnect API. > While handling the continuation events (WRITE, READ) the plug-in checks if > the vconnection is still open by calling TSVConnClosedGet(vconnection). > ATS recently changed the behavior. Now TSVConnClosedGet(vconnections) returns > a value different than 0 before any data can be retrieved. > If the call to TSVConnClosedGet is ignored the plug-in successfully writes > the request and receives the response. > By investigation our different Traffic Server versions the described change > seems to be related with TS-2751. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3096) After TS-2751 TSVConnClosedGet changed its behaviour
[ https://issues.apache.org/jira/browse/TS-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3096: -- Fix Version/s: (was: 5.3.0) > After TS-2751 TSVConnClosedGet changed its behaviour > > > Key: TS-3096 > URL: https://issues.apache.org/jira/browse/TS-3096 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Daniel Vitor Morilha >Priority: Critical > > One of our plug-ins initiates a background connection to an origin by using > TSHttpConnect API. > While handling the continuation events (WRITE, READ) the plug-in checks if > the vconnection is still open by calling TSVConnClosedGet(vconnection). > ATS recently changed the behavior. Now TSVConnClosedGet(vconnections) returns > a value different than 0 before any data can be retrieved. > If the call to TSVConnClosedGet is ignored the plug-in successfully writes > the request and receives the response. > By investigation our different Traffic Server versions the described change > seems to be related with TS-2751. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3226) SSL data not read from the socket sometimes causing transactions to timeout
[
https://issues.apache.org/jira/browse/TS-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda resolved TS-3226.
---
Resolution: Fixed
The issue is definitely resolved with the fix, although, I am still unclear on
how the fix is working.
> SSL data not read from the socket sometimes causing transactions to timeout
> ---
>
> Key: TS-3226
> URL: https://issues.apache.org/jira/browse/TS-3226
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 5.1.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 5.2.0
>
>
> We have had a really long standing problem where some of our origins were
> complaining of receiving POST requests with non-zero content-length header,
> but, no body (or sometimes, partial body). Due to the way our network was
> setup, this problem was not easy to be isolated due to the multiple hops
> along the way. The post body could be lost anywhere along the path (e.g.
> client, dns, routers/vips, edge, data center etc). After a lot of debugging
> and with the help of some custom-built wire traces for SSL, we managed to
> isolate the problem to our ATS hosts running on our edge layer. From the wire
> traces, we could see that, the post body is coming in alright, but is just
> sitting in the socket and not being read by the post ua tunnel producer.
> After further investigation, it seems that the producer is issuing the
> correct do_io_read for the required number of bytes, but, there seems to be a
> bug in the {{SSLNetVConnection::net_read_io}}, where the ntodo is being
> calculated before acquiring the mutex on the read vio.
> https://github.com/apache/trafficserver/blob/master/iocore/net/SSLNetVConnection.cc#L391
> Instrumenting the code with further debug traces showed that, in the failed
> transactions, I am noticing the ntodo being "0" when determined before the
> mutex, whereas the (s->vio.nbytes - s->vio.ndone) is non-zero after the
> mutex. I am not sure to understand how the nbytes on the read vio object can
> be different before acquiring mutex, but, moving the ntodo calculation after
> mutex seems to have resolved the problem. Note that this is how it is done in
> the corresponding function {{read_from_net}} in {{UnixNetVConnection}}.
> Talking to [~amc] on the IRC, it seems that the mutex is needed coz, the
> {{SSLNetVConnection::net_read_io}} could also be triggered by an incoming
> socket data before the {{UnixNetVConnection::do_io_read}} could trigger it
> and that could mess up the nbytes/ndone in the read vio.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3088) Have ATS look at /etc/hosts
[ https://issues.apache.org/jira/browse/TS-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14248684#comment-14248684 ] Alan M. Carroll commented on TS-3088: - No, they were consolidated into a method - HostDBMD5::set_host. I thought it wrong that the same logic was duplicated 4 or 5 times through out the code. > Have ATS look at /etc/hosts > --- > > Key: TS-3088 > URL: https://issues.apache.org/jira/browse/TS-3088 > Project: Traffic Server > Issue Type: New Feature > Components: DNS >Reporter: David Carlin >Assignee: Alan M. Carroll >Priority: Minor > Fix For: 5.3.0 > > Attachments: ts-3088-3-2-x-patch.diff > > > It would be nice if /etc/hosts was read when resolving hostnames - useful for > testing/troubleshooting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3088) Have ATS look at /etc/hosts
[
https://issues.apache.org/jira/browse/TS-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14248684#comment-14248684
]
Alan M. Carroll edited comment on TS-3088 at 12/16/14 6:57 PM:
---
No, they were consolidated into a method - {{HostDBMD5::set_host}}. I thought
it wrong that the same logic was duplicated 4 or 5 times through out the code.
was (Author: amc):
No, they were consolidated into a method - HostDBMD5::set_host. I thought it
wrong that the same logic was duplicated 4 or 5 times through out the code.
> Have ATS look at /etc/hosts
> ---
>
> Key: TS-3088
> URL: https://issues.apache.org/jira/browse/TS-3088
> Project: Traffic Server
> Issue Type: New Feature
> Components: DNS
>Reporter: David Carlin
>Assignee: Alan M. Carroll
>Priority: Minor
> Fix For: 5.3.0
>
> Attachments: ts-3088-3-2-x-patch.diff
>
>
> It would be nice if /etc/hosts was read when resolving hostnames - useful for
> testing/troubleshooting.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3051) Bad if for perror on AIO.cc
[ https://issues.apache.org/jira/browse/TS-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3051: -- Summary: Bad if for perror on AIO.cc (was: bad if for perror on AIO.cc) > Bad if for perror on AIO.cc > --- > > Key: TS-3051 > URL: https://issues.apache.org/jira/browse/TS-3051 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Juan Pablo Daniel Borgna >Assignee: James Peach > Fix For: 5.2.0 > > > File iocore/aio/AIO.cc on line 569 the condition check of the ret value of > io_getevents uses perror and logs when it returns success (until the > traffic.log fills the disk and boom) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3032) FATAL: ats_malloc: couldn't allocate XXXXXX bytes
[
https://issues.apache.org/jira/browse/TS-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3032:
--
Fix Version/s: (was: 5.2.0)
> FATAL: ats_malloc: couldn't allocate XX bytes
> -
>
> Key: TS-3032
> URL: https://issues.apache.org/jira/browse/TS-3032
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Nikolai Gorchilov
>Assignee: Brian Geffon
> Labels: crash
> Attachments: memory.d.png
>
>
> ATS 5.0.1 under Unbuntu 12.04.4 running happily for days suddenly crashes due
> to memory allocation issue. Happens once or twice a week.
> Server is having plenty of RAM - 128G - out of which 64G+ are free. Nothing
> suspicious in dmesg.
> {noformat}
> FATAL: ats_malloc: couldn't allocate 155648 bytes
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6251b3d837]
> /z/lib/libtsutil.so.5(ats_malloc+0x30)[0x2b6251b40c50]
> /z/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0x34)[0x62e834]
> /z/bin/traffic_server(http_hdr_clone(HTTPHdrImpl*, HdrHeap*,
> HdrHeap*)+0x8f)[0x62a54f]
> /z/bin/traffic_server(HttpTransactHeaders::copy_header_fields(HTTPHdr*,
> HTTPHdr*, bool, long)+0x1ae)[0x5d08de]
> /z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion)+0x5c)[0x5b280c]
> /z/bin/traffic_server(HttpTransact::HandleCacheOpenReadMiss(HttpTransact::State*)+0x2c8)[0x5c2ce8]
> /z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x58e356]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e84a]
> /z/bin/traffic_server(HttpSM::set_next_state()+0xd48)[0x5a1038]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/x3me_dscp.so(http_txn_hook(tsapi_cont*, TSEvent,
> void*)+0x236)[0x2b626342b508]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x180)[0x59b070]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x173)[0x57bbb3]
> /z/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x616)[0x6d65a6]
> /z/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0xb0)[0x6b1af0]
> /z/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x83)[0x57c2d3]
> /z/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xfb)[0x58baeb]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x888)[0x5a0b78]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x7e2)[0x5a0ad2]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c03]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/cacheurl.so(+0x17dc)[0x2b6263a477dc]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/tslua.so(+0x596f)[0x2b626363396f]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8a)[0x59c81a]
> /z/bin/traffic_server(TSHttpTxnReenable+0x141)[0x4caa51]
> /z/lib/plugins/stats_over_http.so(+0x1235)[0x2b6263228235]
> /z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x102)[0x5999c2]
> /z/bin/traffic_server(HttpSM::set_next_state()+0x238)[0x5a0528]
> /z/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x22b)[0x59270b]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ad98]
> /z/bin/traffic_server[0x714a60]
> /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1ed)[0x7077cd]
> /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736111]
> /z/bin/traffic_server(EThread::execute()+0x4fc)[0x736bcc]
> /z/bin/t
[jira] [Updated] (TS-2561) Remove app-template from examples
[ https://issues.apache.org/jira/browse/TS-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2561: -- Summary: Remove app-template from examples (was: remove app-template from examples) > Remove app-template from examples > - > > Key: TS-2561 > URL: https://issues.apache.org/jira/browse/TS-2561 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 5.0.0 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > due to the STANDALONE IOCORE is removed, the app-template example should not > be there. and most of the app-template & STANDALONE IOCORE design purpose is > able to satisfied with the protocol plugin. > let us remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2273) test_AIO fail with Linux native AIO
[
https://issues.apache.org/jira/browse/TS-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2273:
--
Fix Version/s: (was: 5.2.0)
> test_AIO fail with Linux native AIO
> ---
>
> Key: TS-2273
> URL: https://issues.apache.org/jira/browse/TS-2273
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Zhao Yongming
>Assignee: Phil Sorber
>
> {code}
> test_AIO-test_AIO.o: In function `main':
> /var/jenkins/workspace/centos_6.4_x64-master-taobao-regression/iocore/aio/test_AIO.cc:494:
> undefined reference to `cache_config_threads_per_disk'
> collect2: ld returned 1 exit status
> make[3]: *** [test_AIO] Error 1
> make[3]: Leaving directory
> `/var/jenkins/workspace/centos_6.4_x64-master-taobao-regression/build/centos_6.4_x64-master-taobao-regression.90/iocore/aio'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory
> `/var/jenkins/workspace/centos_6.4_x64-master-taobao-regression/build/centos_6.4_x64-master-taobao-regression.90/iocore/aio'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory
> `/var/jenkins/workspace/centos_6.4_x64-master-taobao-regression/build/centos_6.4_x64-master-taobao-regression.90/iocore'
> make: *** [check-recursive] Error 1
> Build step 'Execute shell' marked build as failure
> Finished: FAILURE
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3103) Improve privilege elevation
[ https://issues.apache.org/jira/browse/TS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3103: -- Summary: Improve privilege elevation (was: improve privilege elevation) > Improve privilege elevation > --- > > Key: TS-3103 > URL: https://issues.apache.org/jira/browse/TS-3103 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Security >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > Improve privilege elevation so that we have a single function that alters > process credentials, and does it correctly. > Here is the behavior I plan to implement: >1. traffic_manager runs with real root credentials, but > effective credentials as given by proxy.config.admin.user_id. > It will elevate back to root to perform privileged operations. >2. traffic_server is started with real root credentials, > but attempts to permanently drop to an unprivileged user early > in the startup process. The unprivileged user account for > traffic_server is also given by proxy.config.admin.user_id. > when traffic_server drops privilege, it does so permanently. >3. traffic_server may elevate privilege depending on the > value of proxy.config.ssl.cert.load_elevated and > proxy.config.plugin.load_elevated. This elevation will only > be supported on platforms that have per-thread capabilities. > traffic_server will check at startup whether to retain > sufficient capabilities to allow it to elevate later. This > means that the *.load_elevated configurations will not be > reloadable. >4. After traffic_server drops privilege, we will continue to abort > with a fatal error if the real or effective user ID is root. This > behavior can be avoided by defining BIG_SECURITY_HOLE=1 at build > time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3084) Forwarding mode breaks iPhone activation (gs.apple.com)
[
https://issues.apache.org/jira/browse/TS-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3084:
--
Summary: Forwarding mode breaks iPhone activation (gs.apple.com) (was:
forwarding mode breaks iPhone activation (gs.apple.com))
> Forwarding mode breaks iPhone activation (gs.apple.com)
> ---
>
> Key: TS-3084
> URL: https://issues.apache.org/jira/browse/TS-3084
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP
>Reporter: Nikolai Gorchilov
>Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
> Attachments: gs.request, gs.response, partial-request.txt,
> ts-3084.patch
>
>
> On iDevice restoration iTunes makes activation request to gs.apple.com
> (request attached).
> When sent via ATS, the request leads to HTTP/1.1 400 (bad request) response
> from origin server.
> Proper response (on direct connection) is also attached for your reference.
> Here's the command to reproduce the problem
> {noformat}
> netcat gs.apple.com 80 < gs.request
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3077) Log cache hit or miss codes
[ https://issues.apache.org/jira/browse/TS-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3077: -- Summary: Log cache hit or miss codes (was: log cache hit or miss codes) > Log cache hit or miss codes > --- > > Key: TS-3077 > URL: https://issues.apache.org/jira/browse/TS-3077 > Project: Traffic Server > Issue Type: Bug >Reporter: Miles Libbey >Assignee: Leif Hedstrom > > We are currently using the log item crc "The cache result code; specifies how > the cache responded to the request (HIT, MISS, and so on)." however, when > there is an error (like the client aborts), the crc field becomes > ERR_CLIENT_ABORT > ERR_CONNECT_FAIL > ERR_READ_TIMEOUT > etc. ERR_CLIENT_ABORTand ERR_CONNECT_FAIL don't seem to be > really cache Status related. WOuld still be nice to know if the error > happened on a hit or miss. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3077) Log cache hit or miss codes
[ https://issues.apache.org/jira/browse/TS-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3077: -- Fix Version/s: (was: 5.2.0) > Log cache hit or miss codes > --- > > Key: TS-3077 > URL: https://issues.apache.org/jira/browse/TS-3077 > Project: Traffic Server > Issue Type: Bug >Reporter: Miles Libbey >Assignee: Leif Hedstrom > > We are currently using the log item crc "The cache result code; specifies how > the cache responded to the request (HIT, MISS, and so on)." however, when > there is an error (like the client aborts), the crc field becomes > ERR_CLIENT_ABORT > ERR_CONNECT_FAIL > ERR_READ_TIMEOUT > etc. ERR_CLIENT_ABORTand ERR_CONNECT_FAIL don't seem to be > really cache Status related. WOuld still be nice to know if the error > happened on a hit or miss. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3071) Emit JSON numbers in stats_over_http
[
https://issues.apache.org/jira/browse/TS-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3071:
--
Summary: Emit JSON numbers in stats_over_http (was: emit JSON numbers in
stats_over_http)
> Emit JSON numbers in stats_over_http
>
>
> Key: TS-3071
> URL: https://issues.apache.org/jira/browse/TS-3071
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> As requested in https://github.com/apache/trafficserver/pull/100, it's
> sometimes helpful for the {{stats_over_http}} plugin to emit numbers instead
> of strings. The problem is that some environments (Javascript, Java) can't
> deal with uint64_t, so we need to make it optional.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3064) Expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers
[ https://issues.apache.org/jira/browse/TS-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3064: -- Summary: Expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers (was: expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers) > Expose TS_EVENT_VCONN_ACTIVE_TIMEOUT in headers > --- > > Key: TS-3064 > URL: https://issues.apache.org/jira/browse/TS-3064 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Daniel Vitor Morilha >Assignee: Leif Hedstrom > Labels: review > Fix For: 5.2.0 > > Attachments: ts3064.diff > > > TS_EVENT_VCONN_ACTIVE_TIMEOUT = 106 is missing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3195) Improved crash logging
[ https://issues.apache.org/jira/browse/TS-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3195: -- Summary: Improved crash logging (was: improved crash logging) > Improved crash logging > -- > > Key: TS-3195 > URL: https://issues.apache.org/jira/browse/TS-3195 > Project: Traffic Server > Issue Type: New Feature > Components: Core, Quality >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > Implement a crash logging helper so we can generate more sophisticated crash > log information. This is also an extensibility hook so that operators can > generate their own crash logs if they want. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3034) Unanchored traffic_line metrics match
[
https://issues.apache.org/jira/browse/TS-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3034:
--
Summary: Unanchored traffic_line metrics match (was: unanchored
traffic_line metrics match)
> Unanchored traffic_line metrics match
> -
>
> Key: TS-3034
> URL: https://issues.apache.org/jira/browse/TS-3034
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Tools
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> The regex passed to {{traffic_line -m}} is anchored, which makes is pretty
> annoying to match record names. We should do an unanchored match to make it
> easier to find names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3033) Reimplement management protocol
[ https://issues.apache.org/jira/browse/TS-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3033: -- Summary: Reimplement management protocol (was: reimplement management protocol) > Reimplement management protocol > --- > > Key: TS-3033 > URL: https://issues.apache.org/jira/browse/TS-3033 > Project: Traffic Server > Issue Type: Bug > Components: Core, Management API >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > The management protocol is hand-crafted for each message type. That's a lot > of code and it makes it unnecessarily complicated to add new message types. > Let's introduce a simple, generic marshaling format and use that everywhere. > The format I have implemented can be used for signaling traffic_server as > well, but for now this is just changing API messages to traffic_manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3192) Umplement proxy.config.config_dir
[
https://issues.apache.org/jira/browse/TS-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3192:
--
Summary: Umplement proxy.config.config_dir (was: implement
proxy.config.config_dir)
> Umplement proxy.config.config_dir
> -
>
> Key: TS-3192
> URL: https://issues.apache.org/jira/browse/TS-3192
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> {{proxy.config.config_dir}} has never been implemented, but there are various
> scenarios where is it useful to be able to point Traffic Server to a
> non-default set of configuration files. {{TS_ROOT}} is not always sufficient
> for this because the system config directory is a path relative to the prefix
> which otherwise cannot be altered (even assuming you know it).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3184) SPDY window_update not triggered correctly..
[
https://issues.apache.org/jira/browse/TS-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3184:
--
Summary: SPDY window_update not triggered correctly.. (was: spdy
window_update not triggered correctly..)
> SPDY window_update not triggered correctly..
>
>
> Key: TS-3184
> URL: https://issues.apache.org/jira/browse/TS-3184
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 5.2.0
>
>
> During a session start, spdy advertises the initial window size as the
> configured {{proxy.config.spdy.initial_window_size_in}}. A window_update is
> triggered whenever the current delta_window_size reaches half this advertised
> window size. However, the condition that checks for triggering the window
> update compares the delta_window_size for each stream with the initial window
> size. This fails to trigger a window_update when the delta_window_size for
> each stream individually is not half the initial_window_size, even though,
> the aggregate of the delta_window_size for all the streams is high enough.
> Consequently, the sender stalls upon exhausting the send window size and
> eventually times out waiting for a window update (which never happens, since,
> individually, each stream doesn't hit half the initial window size).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3192) Implement proxy.config.config_dir
[
https://issues.apache.org/jira/browse/TS-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3192:
--
Summary: Implement proxy.config.config_dir (was: Umplement
proxy.config.config_dir)
> Implement proxy.config.config_dir
> -
>
> Key: TS-3192
> URL: https://issues.apache.org/jira/browse/TS-3192
> Project: Traffic Server
> Issue Type: New Feature
> Components: Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> {{proxy.config.config_dir}} has never been implemented, but there are various
> scenarios where is it useful to be able to point Traffic Server to a
> non-default set of configuration files. {{TS_ROOT}} is not always sufficient
> for this because the system config directory is a path relative to the prefix
> which otherwise cannot be altered (even assuming you know it).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1244) Crash report: cores in Arena::reset
[
https://issues.apache.org/jira/browse/TS-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1244:
--
Fix Version/s: (was: 5.2.0)
> Crash report: cores in Arena::reset
>
>
> Key: TS-1244
> URL: https://issues.apache.org/jira/browse/TS-1244
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4
>Reporter: Manjesh Nilange
>Assignee: Brian Geffon
> Labels: Crash
>
> I have two slightly different stack traces, but both involving Arena::reset
> #0 0x003736032a45 in raise () from /lib64/libc.so.6
> #1 0x003736034225 in abort () from /lib64/libc.so.6
> #2 0x00373606fdfb in __libc_message () from /lib64/libc.so.6
> #3 0x003736075716 in malloc_printerr () from /lib64/libc.so.6
> #4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
> #5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
> #6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
> #7 0x0050e3e3 in destroy (this=0x2b8c2c1b6b40) at HttpTransact.h:1235
> #8 HttpSM::cleanup (this=0x2b8c2c1b6b40) at HttpSM.cc:346
> #9 0x0050e719 in HttpSM::destroy (this=0x2b8c2c1b6b40) at
> HttpSM.cc:368
> #10 0x00515a56 in HttpSM::kill_this (this=0x2b8c2c1b6b40) at
> HttpSM.cc:6023
> #11 0x00515e08 in HttpSM::main_handler (this=0x2b8c2c1b6b40,
> event=2301, data=0x2b8c2c1b8828)
> at HttpSM.cc:2452
> ...
> (gdb) f 4
> #4 0x003724e0d38d in xfree (this=0x2b8c2c1b6bb8) at ink_resource.h:89
> 89ink_free(mem);
> (gdb) p mem
> $1 =
> (gdb) f 5
> #5 blk_free (this=0x2b8c2c1b6bb8) at Arena.cc:69
> 69xfree(blk);
> (gdb) p blk
> $2 =
> (gdb) f 6
> #6 Arena::reset (this=0x2b8c2c1b6bb8) at Arena.cc:156
> 156 blk_free(m_blocks);
> (gdb) p m_blocks
> $3 = (ArenaBlock *) 0x2b8b9822b870
> (gdb) p *m_blocks
> $4 = {next = 0x3b323531322e3630, m_heap_end = 0x2554454e2e303225 0x2554454e2e303225 out of bounds>,
> m_water_level = 0x303225524c433032 bounds>, data = "3.5.3072"}
> (gdb) p *m_blocks->next
> Cannot access memory at address 0x3b323531322e3630
> It looks m_blocks is corrupted.
> and the other stack trace
> #3 0x004d03aa in signal_handler (sig=11) at signals.cc:225
> #4
> #5 blk_free (this=0x2afc58072f88) at Arena.cc:65
> #6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
> #7 0x0050e3e3 in destroy (this=0x2afc58072f10) at HttpTransact.h:1235
> #8 HttpSM::cleanup (this=0x2afc58072f10) at HttpSM.cc:346
> #9 0x0050e719 in HttpSM::destroy (this=0x2afc58072f10) at
> HttpSM.cc:368
> #10 0x00515a56 in HttpSM::kill_this (this=0x2afc58072f10) at
> HttpSM.cc:6023
> #11 0x00515e08 in HttpSM::main_handler (this=0x2afc58072f10,
> event=2301, data=0x2afc58074bf8)
> at HttpSM.cc:2452
> ...
> (gdb) f 5
> #5 blk_free (this=0x2afc58072f88) at Arena.cc:65
> 65 size = blk->m_heap_end - &blk->data[0];
> (gdb) p blk
> $1 =
> (gdb) f 6
> #6 Arena::reset (this=0x2afc58072f88) at Arena.cc:156
> 156 blk_free(m_blocks);
> (gdb) p m_blocks
> $2 = (ArenaBlock *) 0x373439333634
> (gdb) p *m_blocks
> Cannot access memory at address 0x373439333634
> Our environment:
> $ uname -a
> Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011
> x86_64 x86_64 x86_64 GNU/Linux
> $ file /usr/bin/traffic_server
> /usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2506) Active request timeout leaves client hanging
[
https://issues.apache.org/jira/browse/TS-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2506:
--
Fix Version/s: (was: 5.2.0)
> Active request timeout leaves client hanging
>
>
> Key: TS-2506
> URL: https://issues.apache.org/jira/browse/TS-2506
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP
>Reporter: James Peach
>Assignee: James Peach
>
> If you set {{proxy.config.http.transaction_active_timeout_out}} and the
> origin response takes too long, the origin end of the HTTP tunnel will get
> shut down, but the user agent will never get notified. The user agent just
> keeps waiting for a response that will never come.
> The HTTP debug log looks like this:
> {code}
> + Proxy's Response 2 +
> -- State Machine Id: 1
> HTTP/1.1 200 OK
> Content-Type: text/plain
> Date: Thu, 16 Jan 2014 01:06:06 GMT
> Age: 0
> Transfer-Encoding: chunked
> Connection: keep-alive
> Server: ATS/4.2.0
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (call_transact_and_set_next_state)> (http) [1] State Transition:
> ORIGIN_SERVER_OPEN -> SERVER_READ
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (do_redirect)> (http_redirect) [HttpSM::do_redirect]
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (deallocate_redirect_postdata_buffers)> (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Jan 15 17:06:06.612] Server {0x109267000} DEBUG: (add_producer)> (http_tunnel) [1] adding producer 'http server'
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (add_consumer)> (http_tunnel) [1] adding consumer 'user agent'
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (perform_cache_write_action)> (http) [1] perform_cache_write_action
> CACHE_DO_NO_ACTION
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (tunnel_run)> (http_tunnel) tunnel_run started, p_arg is NULL
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (do_io_write)> (http_cs) tcp_init_cwnd_set 0
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (set_tcp_init_cwnd)> (http_cs) desired TCP congestion window is 0
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (producer_run)> (http_tunnel) [producer_run] do_dechunking
> p->chunked_handler.chunked_reader->read_avail() = 184
> [Jan 15 17:06:06.613] Server {0x109267000} DEBUG: (producer_run)> (http_tunnel) [producer_run] do_dechunking
> p->chunked_handler.skip_bytes = 161
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (producer_handler)> (http_tunnel) [1] producer_handler [http server
> VC_EVENT_READ_READY]
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (producer_handler_chunked)> (http_tunnel) [1] producer_handler_chunked [http
> server VC_EVENT_READ_READY]
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (read_size)> (http_chunk) read chunk size of 17 bytes
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (read_chunk)> (http_chunk) completed read of chunk of 17 bytes
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (producer_handler)> (http_redirect) [HttpTunnel::producer_handler]
> enable_redirection: [1 0 0] event: 100
> [Jan 15 17:06:06.614] Server {0x109267000} DEBUG: (consumer_handler)> (http_tunnel) [1] consumer_handler [user agent
> VC_EVENT_WRITE_READY]
> [Jan 15 17:06:08.610] Server {0x109267000} DEBUG: (producer_handler)> (http_tunnel) [1] producer_handler [http server
> VC_EVENT_ACTIVE_TIMEOUT]
> [Jan 15 17:06:08.610] Server {0x109267000} DEBUG: (producer_handler_chunked)> (http_tunnel) [1] producer_handler_chunked [http
> server VC_EVENT_ACTIVE_TIMEOUT]
> [Jan 15 17:06:08.610] Server {0x109267000} DEBUG: (producer_handler)> (http_redirect) [HttpTunnel::producer_handler]
> enable_redirection: [1 0 0] event: 106
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (tunnel_handler_server)> (http) [1] [&HttpSM::tunnel_handler_server,
> VC_EVENT_ACTIVE_TIMEOUT]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (consumer_handler)> (http_tunnel) [1] consumer_handler [user agent
> VC_EVENT_WRITE_COMPLETE]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (tunnel_handler_ua)> (http) [1] [&HttpSM::tunnel_handler_ua,
> VC_EVENT_WRITE_COMPLETE]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (release)> (http_cs) [1] session released by sm [1]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (release)> (http_cs) [1] initiating io for next header
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (do_io_close)> (http_ss) [1] session closed
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (main_handler)> (http) [1] [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (tunnel_handler)> (http) [1] [&HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
> [Jan 15 17:06:08.612] Server {0x109267000} DEBUG: (deallocate_redirect_po
[jira] [Updated] (TS-2314) New config to allow unsatifiable Range: request to go straight to Origin
[ https://issues.apache.org/jira/browse/TS-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2314: -- Issue Type: New Feature (was: Bug) > New config to allow unsatifiable Range: request to go straight to Origin > > > Key: TS-2314 > URL: https://issues.apache.org/jira/browse/TS-2314 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: jaekyung oh >Assignee: Sudheer Vinukonda > Labels: range > Fix For: 5.2.0 > > Attachments: TS-2314.diff > > > Basically read_while_writer works fine when ATS handles normal file. > In progressive download and playback of mp4 in which moov atom is placed at > the end of the file, ATS makes and returns wrong response for range request > from unfulfilled cache when read_while_writer is 1. > In origin, apache has h264 streaming module. Everything is ok whether the > moov atom is placed at the beginning of the file or not in origin except a > range request happens with read_while_writer. > Mostly our customer’s contents placed moov atom at the end of the file and in > the case movie player stops playing when it seek somewhere in the movie. > to check if read_while_writer works fine, > 1. prepare a mp4 file whose moov atom is placed at the end of the file. > 2. curl --range - http://www.test.com/mp4/test.mp4 1> > no_cache_from_origin > 3. wget http://www.test.com/mp4/test.mp4 > 4. right after wget, execute “curl --range - > http://www.test.com/mp4/test.mp4 1> from_read_while_writer” on other terminal > (the point is sending range request while ATS is still downloading) > 5. after wget gets done, curl --range - > http://www.test.com/mp4/test.mp4 1> from_cache > 6. you can check compare those files by bindiff. > The response from origin(no_cache_from_origin) for the range request is > exactly same to from_cache resulted from #5's range request. but > from_read_while_writer from #4 is totally different from others. > i think a range request should be forwarded to origin server if it can’t find > the content with the offset in cache even if the read_while_writer is on, > instead ATS makes(from where?) and sends wrong response. (In squid.log it > indicates TCP_HIT) > That’s why a movie player stops when it seeks right after the movie starts. > Well. we turned off read_while_writer and movie play is ok but the problems > is read_while_writer is global options. we can’t set it differently for each > remap entry by conf_remap. > So the downloading of Big file(not mp4 file) gives overhead to origin server > because read_while_writer is off. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2561) Remove app-template from examples
[ https://issues.apache.org/jira/browse/TS-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2561: -- Issue Type: Improvement (was: Bug) > Remove app-template from examples > - > > Key: TS-2561 > URL: https://issues.apache.org/jira/browse/TS-2561 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 5.0.0 >Reporter: Zhao Yongming >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > due to the STANDALONE IOCORE is removed, the app-template example should not > be there. and most of the app-template & STANDALONE IOCORE design purpose is > able to satisfied with the protocol plugin. > let us remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3024) Build with OPENSSL_NO_SSL_INTERN
[
https://issues.apache.org/jira/browse/TS-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3024:
--
Issue Type: Improvement (was: Bug)
> Build with OPENSSL_NO_SSL_INTERN
>
>
> Key: TS-3024
> URL: https://issues.apache.org/jira/browse/TS-3024
> Project: Traffic Server
> Issue Type: Improvement
> Components: Build, SSL
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 5.2.0
>
> Attachments: ts-3024.patch
>
>
> I think we should enable {{OPENSSL_NO_SSL_INTERN}} to make ourselves more
> robust to OpenSSL implementation changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3023: -- Issue Type: Improvement (was: Bug) > Support space separated values in inline plugin parameters in remap rules > - > > Key: TS-3023 > URL: https://issues.apache.org/jira/browse/TS-3023 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > Attachments: TS-3023.diff > > > While reviewing and testing TS-2947, Leif found that, space separated values > are not supported correctly for inline plugin params whereas, they work as > expected when specified in the config file. > For example, > @pparam=proxy.config.foo='bar beer' results only in setting > proxy.config.foo=bar > whereas > CONFIG proxy.config.foo STRING 'bar beer' results in setting > proxy.config.foo='bar beer' > Further analysis revealed that the limitation is in parsing/tokenizing the > input, which always treats space or tab as delimiters, regardless of whether > they are included within quotes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3034) Unanchored traffic_line metrics match
[
https://issues.apache.org/jira/browse/TS-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3034:
--
Issue Type: Improvement (was: Bug)
> Unanchored traffic_line metrics match
> -
>
> Key: TS-3034
> URL: https://issues.apache.org/jira/browse/TS-3034
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration, Tools
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.2.0
>
>
> The regex passed to {{traffic_line -m}} is anchored, which makes is pretty
> annoying to match record names. We should do an unanchored match to make it
> easier to find names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3033) Reimplement management protocol
[ https://issues.apache.org/jira/browse/TS-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3033: -- Issue Type: Improvement (was: Bug) > Reimplement management protocol > --- > > Key: TS-3033 > URL: https://issues.apache.org/jira/browse/TS-3033 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Management API >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > > The management protocol is hand-crafted for each message type. That's a lot > of code and it makes it unnecessarily complicated to add new message types. > Let's introduce a simple, generic marshaling format and use that everywhere. > The format I have implemented can be used for signaling traffic_server as > well, but for now this is just changing API messages to traffic_manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3070) Consistent span configuration
[ https://issues.apache.org/jira/browse/TS-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3070: -- Issue Type: Improvement (was: Bug) > Consistent span configuration > - > > Key: TS-3070 > URL: https://issues.apache.org/jira/browse/TS-3070 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Core >Reporter: James Peach >Assignee: James Peach > Fix For: 5.2.0 > > Attachments: TS-3070.patch > > > The span configuration is not consistent across platforms because the code is > duplicated for Linux, Solaris and the BSD family. We should refactor this > code so that cache files and directories are handled consistently and only > the disk geometry probing is platform specific. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3114) Refactor IpMap to make the RB tree a shared data structure
[ https://issues.apache.org/jira/browse/TS-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3114: -- Issue Type: Improvement (was: Bug) > Refactor IpMap to make the RB tree a shared data structure > -- > > Key: TS-3114 > URL: https://issues.apache.org/jira/browse/TS-3114 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup, Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.2.0 > > > The RB tree would be useful in other places, let's pull that out and make it > something more code can take advantage of. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3194) Remove unused proxy.config.plugin.plugin_mgmt_dir
[
https://issues.apache.org/jira/browse/TS-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3194:
--
Issue Type: Improvement (was: Bug)
> Remove unused proxy.config.plugin.plugin_mgmt_dir
> -
>
> Key: TS-3194
> URL: https://issues.apache.org/jira/browse/TS-3194
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.2.0
>
>
> {{proxy.config.plugin.plugin_mgmt_dir}} is not used anywhere. Let's remove it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3121) Seeing garbage SPDY responses sometimes
[ https://issues.apache.org/jira/browse/TS-3121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3121: -- Summary: Seeing garbage SPDY responses sometimes (was: Seeing garbage Spdy responses sometimes) > Seeing garbage SPDY responses sometimes > --- > > Key: TS-3121 > URL: https://issues.apache.org/jira/browse/TS-3121 > Project: Traffic Server > Issue Type: Bug > Components: SPDY >Affects Versions: 5.0.1 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > > Seeing some HTTP/0.9 version garbage responses with status=0 from SPDY > sometimes. In some error cases, when http layer cleans up itself and sends a > FETCH ERROR to the SPDY layer and SPDY layer seems to build a SYN_REPLY with > garbage HTTP headers. Adding a simple protection to prevent this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2682) Add per remap configuration / activation to background_fetch
[ https://issues.apache.org/jira/browse/TS-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2682: -- Issue Type: New Feature (was: Improvement) > Add per remap configuration / activation to background_fetch > > > Key: TS-2682 > URL: https://issues.apache.org/jira/browse/TS-2682 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2955) Support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2955:
--
Issue Type: New Feature (was: Improvement)
> Support variable expansion in set-redirect operator for header_rewrite
> --
>
> Key: TS-2955
> URL: https://issues.apache.org/jira/browse/TS-2955
> Project: Traffic Server
> Issue Type: New Feature
> Components: Plugins
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Labels: review, yahoo
> Fix For: 5.2.0
>
> Attachments: TS-2955.diff
>
>
> support variable expansion in set-redirect operator for header_rewrite to be
> able to dynamically substitute variables in the Location header (currently,
> only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2683) Add some control for which content to activate the background_fetch plugin
[ https://issues.apache.org/jira/browse/TS-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2683: -- Issue Type: New Feature (was: Improvement) > Add some control for which content to activate the background_fetch plugin > -- > > Key: TS-2683 > URL: https://issues.apache.org/jira/browse/TS-2683 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Sudheer Vinukonda > Fix For: 5.2.0 > > > This would be both in global and per-remap configurations. Such as, only > trigger background_fetch for certain content types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3115) Add server response time field in custom logging fields
[ https://issues.apache.org/jira/browse/TS-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3115: -- Issue Type: New Feature (was: Improvement) > Add server response time field in custom logging fields > --- > > Key: TS-3115 > URL: https://issues.apache.org/jira/browse/TS-3115 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Masaori Koshiba >Assignee: James Peach > Fix For: 5.2.0 > > > It is useful that there is a custom logging field of time Traffic Server > spends retrieving an object from the origin server. > A patch is proposed on https://github.com/apache/trafficserver/pull/124 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3119) Add option to support SO_LINGER to origin server
[ https://issues.apache.org/jira/browse/TS-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3119: -- Issue Type: New Feature (was: Improvement) > Add option to support SO_LINGER to origin server > > > Key: TS-3119 > URL: https://issues.apache.org/jira/browse/TS-3119 > Project: Traffic Server > Issue Type: New Feature > Components: Network >Reporter: kang li >Assignee: James Peach > Fix For: 5.2.0 > > Attachments: add_so_linger_as_option.diff, linger.diff > > > When install ATS and apache in the same box to do SSL termination. We saw > port exhaustion, performance drop and request missing through ATS. > Before migration we are using stunnel to do SSL termination. There were no > such problem. After investigation we found add SO_LINGER option to origin > could resolve these problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2914) LogField cquuh does not work for TSSkipRemappingSet
[ https://issues.apache.org/jira/browse/TS-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2914: - Assignee: Leif Hedstrom > LogField cquuh does not work for TSSkipRemappingSet > --- > > Key: TS-2914 > URL: https://issues.apache.org/jira/browse/TS-2914 > Project: Traffic Server > Issue Type: Bug > Components: Logging, TS API >Reporter: xiongzongtao >Assignee: Leif Hedstrom > Labels: Review > Fix For: 5.3.0 > > Attachments: quickfix.diff > > > if cquuh is set in logs_xml.config and TSSkipRemappingSet called in plugin > log entry related to that plugin is not correct and not readable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2914) LogField cquuh does not work for TSSkipRemappingSet
[ https://issues.apache.org/jira/browse/TS-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2914: -- Labels: Review (was: ) > LogField cquuh does not work for TSSkipRemappingSet > --- > > Key: TS-2914 > URL: https://issues.apache.org/jira/browse/TS-2914 > Project: Traffic Server > Issue Type: Bug > Components: Logging, TS API >Reporter: xiongzongtao > Labels: Review > Fix For: 5.3.0 > > Attachments: quickfix.diff > > > if cquuh is set in logs_xml.config and TSSkipRemappingSet called in plugin > log entry related to that plugin is not correct and not readable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3227) LuaJit doesn't properly compile with clang
[
https://issues.apache.org/jira/browse/TS-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3227:
--
Fix Version/s: 5.3.0
> LuaJit doesn't properly compile with clang
> --
>
> Key: TS-3227
> URL: https://issues.apache.org/jira/browse/TS-3227
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Reporter: Igor Galić
> Fix For: 5.3.0
>
>
> {code}
> make[3]: Entering directory '/home/igalic/src/asf/trafficserver/lib/luajit'
> Building LuaJIT 2.0.3
> make -C src
> make[4]: Entering directory
> '/home/igalic/src/asf/trafficserver/lib/luajit/src'
> clang: error: unsupported option '-dumpspecs'
> clang: error: no input files
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3227) LuaJit doesn't properly compile with clang
[
https://issues.apache.org/jira/browse/TS-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249121#comment-14249121
]
Leif Hedstrom commented on TS-3227:
---
This is rather surprising, we build with clang on a number of platforms,
including OS X, Fedora and Ubuntu. What clang version is this, and what
platform ?
> LuaJit doesn't properly compile with clang
> --
>
> Key: TS-3227
> URL: https://issues.apache.org/jira/browse/TS-3227
> Project: Traffic Server
> Issue Type: Bug
> Components: Lua
>Reporter: Igor Galić
> Fix For: 5.3.0
>
>
> {code}
> make[3]: Entering directory '/home/igalic/src/asf/trafficserver/lib/luajit'
> Building LuaJIT 2.0.3
> make -C src
> make[4]: Entering directory
> '/home/igalic/src/asf/trafficserver/lib/luajit/src'
> clang: error: unsupported option '-dumpspecs'
> clang: error: no input files
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3178) ProxyAllocator improvements
[ https://issues.apache.org/jira/browse/TS-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-3178: Assignee: Brian Geffon (was: Cynthia Gu) > ProxyAllocator improvements > --- > > Key: TS-3178 > URL: https://issues.apache.org/jira/browse/TS-3178 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.2.0 > > Attachments: patch.diff, patch.diff > > > Currently when a ProxyAllocator (Thread Local) has more than a > configurable number of elements it will return them one-by-one to a > ClassAllocator (Global Freelist). Returning every item in this fashion is > inefficient as we'll likely need more items in the future. Therefore we > should maintain a low watermark (a minimum number) of items that should be in > a ProxyAllocator at any one time. When the number of elements reaches high > watermark, the free up is triggers to keep it below the low > watermark. Additionally, the free should be a block free instead of > one-by-one as we can reduce several hundred compare-and-swap operations to a > single CAS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (TS-3178) ProxyAllocator improvements
[ https://issues.apache.org/jira/browse/TS-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reopened TS-3178: -- Reopened due to bug with reclaimable freelist. > ProxyAllocator improvements > --- > > Key: TS-3178 > URL: https://issues.apache.org/jira/browse/TS-3178 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.2.0 > > Attachments: patch.diff, patch.diff > > > Currently when a ProxyAllocator (Thread Local) has more than a > configurable number of elements it will return them one-by-one to a > ClassAllocator (Global Freelist). Returning every item in this fashion is > inefficient as we'll likely need more items in the future. Therefore we > should maintain a low watermark (a minimum number) of items that should be in > a ProxyAllocator at any one time. When the number of elements reaches high > watermark, the free up is triggers to keep it below the low > watermark. Additionally, the free should be a block free instead of > one-by-one as we can reduce several hundred compare-and-swap operations to a > single CAS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3178) ProxyAllocator improvements
[ https://issues.apache.org/jira/browse/TS-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249553#comment-14249553 ] ASF subversion and git services commented on TS-3178: - Commit 8993142d44253ded76b132535b6886f971483b9f in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8993142 ] TS-3178: Fixing build error related to reclaimable freelist > ProxyAllocator improvements > --- > > Key: TS-3178 > URL: https://issues.apache.org/jira/browse/TS-3178 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.2.0 > > Attachments: patch.diff, patch.diff > > > Currently when a ProxyAllocator (Thread Local) has more than a > configurable number of elements it will return them one-by-one to a > ClassAllocator (Global Freelist). Returning every item in this fashion is > inefficient as we'll likely need more items in the future. Therefore we > should maintain a low watermark (a minimum number) of items that should be in > a ProxyAllocator at any one time. When the number of elements reaches high > watermark, the free up is triggers to keep it below the low > watermark. Additionally, the free should be a block free instead of > one-by-one as we can reduce several hundred compare-and-swap operations to a > single CAS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3178) ProxyAllocator improvements
[ https://issues.apache.org/jira/browse/TS-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon closed TS-3178. Resolution: Fixed > ProxyAllocator improvements > --- > > Key: TS-3178 > URL: https://issues.apache.org/jira/browse/TS-3178 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.2.0 > > Attachments: patch.diff, patch.diff > > > Currently when a ProxyAllocator (Thread Local) has more than a > configurable number of elements it will return them one-by-one to a > ClassAllocator (Global Freelist). Returning every item in this fashion is > inefficient as we'll likely need more items in the future. Therefore we > should maintain a low watermark (a minimum number) of items that should be in > a ProxyAllocator at any one time. When the number of elements reaches high > watermark, the free up is triggers to keep it below the low > watermark. Additionally, the free should be a block free instead of > one-by-one as we can reduce several hundred compare-and-swap operations to a > single CAS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
