[jira] [Updated] (TS-2063) LogFile::write_ascii_logbuffer3() can silently drop log entries
[ https://issues.apache.org/jira/browse/TS-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-2063: - Attachment: 0001-TS-2063-LogFile-write_ascii_logbuffer3-can-silently-.patch 1) Avoid silently dropping log entries in write_ascii_logbuffer3(). 2) Remove overspill logic, and try to write log to disk as much as possible. 3) Simplify the code by removing unecessary *overspill* variables. > LogFile::write_ascii_logbuffer3() can silently drop log entries > --- > > Key: TS-2063 > URL: https://issues.apache.org/jira/browse/TS-2063 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: A > Fix For: 3.5.0 > > Attachments: > 0001-TS-2063-LogFile-write_ascii_logbuffer3-can-silently-.patch > > > Couple of things here. > 1. Why do we need both LogFile::write_ascii_logbuffer() and > LogFile::write_ascii_logbuffer3()? The former is only used by traffic_logcat, > we ought to be able to refactor and unify this. > 2. In LogFile::write_ascii_logbuffer3(), it's possible that writing to the > LogBuffer has produced more entries than we can marshal and fit into an ascii > buffer. When that happens, we'd simply drop those log entries on the floor. > 3. It's possible this also relates to TS-777. > As for 2, I think we should at a minimum break out of the inner loop in the > else branch of testing if an entry fits (instead of silently dropping the > entry). This puts weirdness in the outer loop, for the case where a single > entry can't fit in the ascii buffer (I don't know if it can happen, but it > might). > A suggestion from amc is to refactor both loops into a single loop that > iterates and checks size restrictions. This is actually similar to how > LogFile::write_ascii_logbuffer() works as well (so fixing / unifying issue 1) > above might be the way to resolve this as well). > As for 3) I have no other proof that this bug is affiliated with TS-777, > other than they both have issues in the same area. And thinking about if, if > you increase proxy.config.log.log_buffer_size but leave > proxy.config.log.max_line_size the same, we get much larger LogBuffers, but > the ascii buffer is still the same size (so we're almost certain to trigger > 2) above). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1823) config file line continuation support
[ https://issues.apache.org/jira/browse/TS-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732057#comment-13732057 ] James Peach commented on TS-1823: - I've wanted this patch for long time. Thank you! > config file line continuation support > - > > Key: TS-1823 > URL: https://issues.apache.org/jira/browse/TS-1823 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: James Peach > Fix For: 3.5.0 > > Attachments: > 0001-Add-line-continuation-to-remap.config-using-a-backsl.patch > > > It looks like remap.config does not support line continuation. We should add > generic line continuation support so that all config files get it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2107:
--
Fix Version/s: (was: 3.3.5)
3.3.6
> add absolute proxy.config.http.transaction_active_timeout_in about request
> ---
>
> Key: TS-2107
> URL: https://issues.apache.org/jira/browse/TS-2107
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Affects Versions: 3.3.5
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.3.6
>
>
> Now, ts use proxy.config.http.transaction_active_timeout_in handle request
> and response transaction. But in some very bad network, we catch some log
> that it cost >30s to get ua_read_header_done, that is unacceptable, should be
> controled with some dedicated timeout in records.config.
> we world prefer to add proxy.config.http.transaction_header_timeout_in
> proxy.config.http.transaction_request_timeout_in
> {code}
> [Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
> Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
> bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
> ua_read_header_done: 46.790 cache_open_read_begin: 46.790
> cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732134#comment-13732134
]
Leif Hedstrom commented on TS-2107:
---
I'm moving this out, it'll not make it in for v3.4.
> add absolute proxy.config.http.transaction_active_timeout_in about request
> ---
>
> Key: TS-2107
> URL: https://issues.apache.org/jira/browse/TS-2107
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Affects Versions: 3.3.5
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.3.6
>
>
> Now, ts use proxy.config.http.transaction_active_timeout_in handle request
> and response transaction. But in some very bad network, we catch some log
> that it cost >30s to get ua_read_header_done, that is unacceptable, should be
> controled with some dedicated timeout in records.config.
> we world prefer to add proxy.config.http.transaction_header_timeout_in
> proxy.config.http.transaction_request_timeout_in
> {code}
> [Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
> Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
> bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
> ua_read_header_done: 46.790 cache_open_read_begin: 46.790
> cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732135#comment-13732135
]
Leif Hedstrom commented on TS-2107:
---
Also, can you explain more what the problem is, and what the solution does? Do
you want to close down connections earlier?
> add absolute proxy.config.http.transaction_active_timeout_in about request
> ---
>
> Key: TS-2107
> URL: https://issues.apache.org/jira/browse/TS-2107
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Affects Versions: 3.3.5
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.3.6
>
>
> Now, ts use proxy.config.http.transaction_active_timeout_in handle request
> and response transaction. But in some very bad network, we catch some log
> that it cost >30s to get ua_read_header_done, that is unacceptable, should be
> controled with some dedicated timeout in records.config.
> we world prefer to add proxy.config.http.transaction_header_timeout_in
> proxy.config.http.transaction_request_timeout_in
> {code}
> [Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
> Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
> bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
> ua_read_header_done: 46.790 cache_open_read_begin: 46.790
> cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request
[
https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2107:
--
Fix Version/s: (was: 3.3.6)
3.5.0
> add absolute proxy.config.http.transaction_active_timeout_in about request
> ---
>
> Key: TS-2107
> URL: https://issues.apache.org/jira/browse/TS-2107
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Affects Versions: 3.3.5
>Reporter: Bin Chen
>Assignee: Bin Chen
> Fix For: 3.5.0
>
>
> Now, ts use proxy.config.http.transaction_active_timeout_in handle request
> and response transaction. But in some very bad network, we catch some log
> that it cost >30s to get ua_read_header_done, that is unacceptable, should be
> controled with some dedicated timeout in records.config.
> we world prefer to add proxy.config.http.transaction_header_timeout_in
> proxy.config.http.transaction_request_timeout_in
> {code}
> [Aug 6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow
> Request: url: http://x/853771125_1448036722.jpg status: 0 unique id:
> bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000
> ua_read_header_done: 46.790 cache_open_read_begin: 46.790
> cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000
> server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
> -1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1967) create max accept handler function
[ https://issues.apache.org/jira/browse/TS-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1967: -- Fix Version/s: (was: 3.3.6) 3.5.0 > create max accept handler function > --- > > Key: TS-1967 > URL: https://issues.apache.org/jira/browse/TS-1967 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 3.2.4 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 3.5.0 > > Attachments: TS-1967.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1917) It seems that one of assert in HttpTransact::handle_content_length_header() is unnecessary
[
https://issues.apache.org/jira/browse/TS-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1917:
--
Fix Version/s: (was: 3.3.6)
3.5.0
> It seems that one of assert in HttpTransact::handle_content_length_header()
> is unnecessary
> ---
>
> Key: TS-1917
> URL: https://issues.apache.org/jira/browse/TS-1917
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: James Peach
> Fix For: 3.5.0
>
> Attachments: ts-1917.wj.diff
>
>
> ATS crashed by the following assert in debug mode:
> {code}
> (gdb) bt
> #0 0x003e86c32885 in raise () from /lib64/libc.so.6
> #1 0x003e86c34065 in abort () from /lib64/libc.so.6
> #2 0x2b349592e234 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x2b349592e301 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1,
> message_format=0x2b349594a748 "%s:%d: failed assert `%s`",
> ap=0x2b34979073a0) at ink_error.cc:65
> #4 0x2b349592e3ca in ink_fatal (return_code=1,
> message_format=0x2b349594a748 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x2b349592d2cc in _ink_assert (expression=0x70fef0 "s->range_setup !=
> RANGE_NOT_TRANSFORM_REQUESTED", file=0x70a613 "HttpTransact.cc", line=6660)
> at ink_assert.cc:37
> #6 0x0059cb57 in HttpTransact::handle_content_length_header
> (s=0x2b34b1207120, header=0x2b34b1207800, base=0x2b36d0030070) at
> HttpTransact.cc:6660
> #7 0x005a116f in HttpTransact::build_response (s=0x2b34b1207120,
> base_response=0x2b36d0030070, outgoing_response=0x2b34b1207800,
> outgoing_version=..., status_code=HTTP_STATUS_OK, reason_phrase=0x725709
> "OK") at HttpTransact.cc:7731
> #8 0x00594972 in
> HttpTransact::handle_cache_operation_on_forward_server_response
> (s=0x2b34b1207120) at HttpTransact.cc:4373
> #9 0x005924f8 in HttpTransact::handle_forward_server_connection_open
> (s=0x2b34b1207120) at HttpTransact.cc:3818
> #10 0x00590c08 in HttpTransact::handle_response_from_server
> (s=0x2b34b1207120) at HttpTransact.cc:3495
> #11 0x0058f60e in HttpTransact::HandleResponse (s=0x2b34b1207120) at
> HttpTransact.cc:3185
> #12 0x00575f25 in HttpSM::call_transact_and_set_next_state
> (this=0x2b34b12070b0, f=0) at HttpSM.cc:6685
> #13 0x00563ca4 in HttpSM::handle_api_return (this=0x2b34b12070b0) at
> HttpSM.cc:1555
> #14 0x00563a79 in HttpSM::state_api_callout (this=0x2b34b12070b0,
> event=0, data=0x0) at HttpSM.cc:1487
> #15 0x0056f79b in HttpSM::do_api_callout_internal
> (this=0x2b34b12070b0) at HttpSM.cc:4702
> #16 0x0057bce8 in HttpSM::do_api_callout (this=0x2b34b12070b0) at
> HttpSM.cc:503
> #17 0x00564b68 in HttpSM::state_read_server_response_header
> (this=0x2b34b12070b0, event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:1869
> #18 0x00567140 in HttpSM::main_handler (this=0x2b34b12070b0,
> event=100, data=0x2b35ff9ef5d0) at HttpSM.cc:2501
> #19 0x004e0f52 in Continuation::handleEvent (this=0x2b34b12070b0,
> event=100, data=0x2b35ff9ef5d0) at ../iocore/eventsystem/I_Continuation.h:146
> #20 0x006ba540 in read_signal_and_update (event=100,
> vc=0x2b35ff9ef4c0) at UnixNetVConnection.cc:138
> #21 0x006bae90 in read_from_net (nh=0x2b34960fdbc0,
> vc=0x2b35ff9ef4c0, thread=0x2b34960fa010) at UnixNetVConnection.cc:320
> #22 0x006bcc7f in UnixNetVConnection::net_read_io
> (this=0x2b35ff9ef4c0, nh=0x2b34960fdbc0, lthread=0x2b34960fa010) at
> UnixNetVConnection.cc:818
> #23 0x006b72e8 in NetHandler::mainNetEvent (this=0x2b34960fdbc0,
> event=5, e=0x2b349cf16b40) at UnixNet.cc:377
> #24 0x004e0f52 in Continuation::handleEvent (this=0x2b34960fdbc0,
> event=5, data=0x2b349cf16b40) at ../iocore/eventsystem/I_Continuation.h:146
> #25 0x006dbcd0 in EThread::process_event (this=0x2b34960fa010,
> e=0x2b349cf16b40, calling_code=5) at UnixEThread.cc:141
> #26 0x006dc2b2 in EThread::execute (this=0x2b34960fa010) at
> UnixEThread.cc:265
> #27 0x006daedc in spawn_thread_internal (a=0x15e2160) at Thread.cc:88
> #28 0x003e878077f1 in start_thread () from /lib64/libpthread.so.0
> #29 0x003e86ce5ccd in clone () from /lib64/libc.so.6
> {code}
> By analyzing the code, it seems that this assertion is unnecessary:
> When client sends a request to ATS, and the content hits in cache, but if the
> cache is STALE, ATS will sent a request to Original-Server.
> In this case, the t_sate.source will be updated to
> SOURCE_HTTP_ORIGIN_SERVER(the old value is SOURCE_CACHE), and in
> HttpTransact::handle_cache_operation_on_forward_server_response()
> => s->sta
[jira] [Updated] (TS-2069) Regression tests fails on OSX
[
https://issues.apache.org/jira/browse/TS-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2069:
--
Fix Version/s: (was: 3.3.6)
3.5.0
> Regression tests fails on OSX
> -
>
> Key: TS-2069
> URL: https://issues.apache.org/jira/browse/TS-2069
> Project: Traffic Server
> Issue Type: Bug
> Components: Quality
>Reporter: Leif Hedstrom
> Fix For: 3.5.0
>
>
> I get
> {code}
> [SDK_API_HttpAltInfo] TSHttpAltInfo : [All] <> { Test not executed even
> once }
> REGRESSION_RESULT SDK_API_HttpAltInfo: FAILED
> REGRESSION TEST SDK_API_HttpTxnTransform started
> Regression test(SDK_API_HttpTxnTransform) still in progress
> [SDK_API_HttpTxnTransform] TSHttpTxnUntransformedResponseCache : [TestCase1]
> <> { Value's Mismatch }
> [SDK_API_HttpTxnTransform] TSHttpTxnTransformedResponseCache : [TestCase1]
> <> { Value's Mismatch }
> [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] <> { did not
> pass transformed_resp_cache }
> [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] <> { did not
> pass untransformed_resp_cache }
> [SDK_API_HttpTxnTransform] TSTransformCreate : [TestCase1] <> { did not
> pass transform_create }
> REGRESSION_RESULT SDK_API_HttpTxnTransform: FAILED
> REGRESSION TEST SDK_API_HttpTxnCache started
> Regression test(SDK_API_HttpTxnCache) still in progress
> REGRESSION_RESULT SDK_API_HttpTxnCache: FAILED
> REGRESSION TEST SDK_API_HttpSsn started
> Regression test(SDK_API_HttpSsn) still in progress
> REGRESSION_RESULT SDK_API_HttpSsn: FAILED
> REGRESSION TEST SDK_API_HttpHookAdd started
> Regression test(SDK_API_HttpHookAdd) still in progress
> [SDK_API_HttpHookAdd] TSHttpHookAdd : [TestCase1] <> { Hooks not called
> or request failure. Hook mask = 0
> HTTP/1.0 200 OK
> X-Response-ID: 1
> Content-Type: text/html
> Cache-Control: no-cache
> Date: Sat, 27 Jul 2013 16:22:45 GMT
> Age: 0
> Via: http/1.0 heimdall.local (ApacheTrafficServer/3.3.5-dev)
> Server: ATS/3.3.5-dev
> Body for response 1: }
> [SDK_API_HttpHookAdd] TSHttpTxnReenable : [TestCase1] <> { Txn not
> re-enabled properly }
> REGRESSION_RESULT SDK_API_HttpHookAdd: FAILED
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2068) Add subdir-objects to configure.ac
[ https://issues.apache.org/jira/browse/TS-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2068: -- Fix Version/s: (was: 3.3.6) 3.5.0 > Add subdir-objects to configure.ac > -- > > Key: TS-2068 > URL: https://issues.apache.org/jira/browse/TS-2068 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom > Fix For: 3.5.0 > > > New versions of automake needs it, however, it seems to fail with automake on > RHEL5. How can we make this conditional on automake version? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2095) autoconf warnings related to unordered_map
[
https://issues.apache.org/jira/browse/TS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2095:
--
Fix Version/s: (was: 3.3.6)
3.5.0
> autoconf warnings related to unordered_map
> --
>
> Key: TS-2095
> URL: https://issues.apache.org/jira/browse/TS-2095
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
> Fix For: 3.5.0
>
>
> {code}
> configure: WARNING: unordered_map: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_map: proceeding with the compiler's result
> checking for unordered_map... yes
> checking unordered_set usability... yes
> checking unordered_set presence... no
> configure: WARNING: unordered_set: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: unordered_set: proceeding with the compiler's result
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2094) OSX autoconf warnings with TCL
[
https://issues.apache.org/jira/browse/TS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2094:
--
Fix Version/s: (was: 3.3.6)
3.5.0
> OSX autoconf warnings with TCL
> --
>
> Key: TS-2094
> URL: https://issues.apache.org/jira/browse/TS-2094
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Leif Hedstrom
> Fix For: 3.5.0
>
>
> {code}
> checking for Tcl configuration... xcrun: error: unrecognized option:
> --show-sdk-path
> Usage: xcrun [options] ... arguments ...
> Find and execute the named command line utility from
> the installed Xcode.
> Options:
> -h, --help show this help message and exit
> -v, --verboseshow verbose logging output
> --sdk find the tool for the given SDK name
> --toolchainfind the tool for the given toolchain
> -l, --logshow commands to be executed (with --run)
> -f, --find only find and print the utility path
> -r, --runfind and execute the utility (this is the default
> behavior)
> -n, --no-cache do not use the lookup cache
> -k, --kill-cache remove any existing cache file (and perhaps recreate)
> found /usr/lib/tclConfig.sh
> checking for existence of /usr/lib/tclConfig.sh... loading
> checking for Expat location... xcrun: error: unrecognized option:
> -show-sdk-path
> Usage: xcrun [options] ... arguments ...
> Find and execute the named command line utility from
> the installed Xcode.
> Options:
> -h, --help show this help message and exit
> -v, --verboseshow verbose logging output
> --sdk find the tool for the given SDK name
> --toolchainfind the tool for the given toolchain
> -l, --logshow commands to be executed (with --run)
> -f, --find only find and print the utility path
> -r, --runfind and execute the utility (this is the default
> behavior)
> -n, --no-cache do not use the lookup cache
> -k, --kill-cache remove any existing cache file (and perhaps recreate)
> /usr
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1590) use_remap_processor crashes if share_server_sessions = 2
[
https://issues.apache.org/jira/browse/TS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1590:
--
Fix Version/s: (was: 3.3.6)
3.5.0
> use_remap_processor crashes if share_server_sessions = 2
>
>
> Key: TS-1590
> URL: https://issues.apache.org/jira/browse/TS-1590
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.3.0
>Reporter: Conan Wang
>Priority: Critical
> Fix For: 3.5.0
>
>
> easy to reproduce:
> {code}
> CONFIG proxy.config.remap.use_remap_processor INT 1 (default is 0)
> CONFIG proxy.config.http.share_server_sessions INT 2 (0, 1 will be ok)
> {code}
> {code}
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x1210
> [Switching to process 8927 thread 0x1a03]
> 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
> hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
> (gdb) bt
> #0 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
> hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
> #1 0x0001000eb366 in HttpSessionManager::acquire_session
> (this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19
> "127.0.0.1", ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
> #2 0x000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0,
> raw=false) at HttpSM.cc:4384
> ..
> (gdb) p this_ethread()->l1_hash
> $2 = (SessionBucket *) 0x0
> (gdb) p this_ethread()->event_types
> $3 = 2 (ET_REMAP)
> {code}
> Using separate remap processor is a hidden option, and I enable it by
> accident.. (Does anyone use it in prod?)
> I noticed HttpSM::do_http_server_open is always executed by the remap
> processer ethread (because of
> action.continuation->handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if
> wrong). While the remap thread was not initialized as ET_NET and has no
> l1_hash, server session lookup in this ET_REMAP thread will crash.
> I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on
> ET_NET. So a fast workaround would be falling back to global server
> connection when use_remap_processor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2077) Remove proxy.config.http.user_agent_pipeline remnants
[ https://issues.apache.org/jira/browse/TS-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2077: -- Fix Version/s: (was: 3.3.6) 3.5.0 > Remove proxy.config.http.user_agent_pipeline remnants > - > > Key: TS-2077 > URL: https://issues.apache.org/jira/browse/TS-2077 > Project: Traffic Server > Issue Type: Bug > Components: Configuration, HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.5.0 > > > As it turns out, this configuration doesn't actually do *anything*. It's a > completely unused (and unfortunately) unusuable configuration. I think > removing it (for now) is better, until we actually either need it or do > something useful with it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1955) read_while_writer sends wrong response for range request.
[ https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1955: -- Fix Version/s: (was: 3.3.6) 3.5.0 > read_while_writer sends wrong response for range request. > - > > Key: TS-1955 > URL: https://issues.apache.org/jira/browse/TS-1955 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.2.4 >Reporter: jaekyung oh >Assignee: Alan M. Carroll > Labels: range > Fix For: 3.5.0 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2051) ATS crashing shortly after starting when SSL is enabled
[
https://issues.apache.org/jira/browse/TS-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732185#comment-13732185
]
Bryan Call commented on TS-2051:
[bcall@l6 ~]$ date
Wed Aug 7 17:25:21 UTC 2013
[bcall@l6 ~]$ ps axuw | grep traffic_serve[r]
nobody 44290 107 68.4 25469872 16820080 ? Sl Aug06 1548:53
/home/y/bin/traffic_server -M --httpport
80:fd=7,81:fd=8,82:fd=11,83:fd=12,84:fd=13,85:fd=14,90:fd=15,80:fd=16:ipv6,81:fd=17:ipv6,443:fd=18:ipv6:ssl,444:fd=19:ipv6:ssl,443:fd=20:ssl,444:fd=21:ssl,445:fd=22:ssl,446:fd=24:ssl,447:fd=25:ssl,448:fd=26:ssl,490:fd=27:ssl
No cores last night!
> ATS crashing shortly after starting when SSL is enabled
> ---
>
> Key: TS-2051
> URL: https://issues.apache.org/jira/browse/TS-2051
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
>Reporter: David Carlin
>Assignee: Leif Hedstrom
>Priority: Blocker
> Fix For: 3.3.5
>
> Attachments: ts-2051.patch
>
>
> We went to test master because it contains a fix for TS-2035. It seems to
> crash if SSL is enabled shortly after startup. The filenames for the core
> files indicate they are from SSL threads.
> CONFIG proxy.config.http.server_ports STRING 80 81 82 83 84 85 90 80:ipv6
> 81:ipv6 443:ipv6:ssl 444:ipv6:ssl 443:ssl 444:ssl 445:ssl 446:ssl 447:ssl
> 448:ssl 490:ssl
> Stack trace:
> {quote}
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x3f8240f500)[0x2aafe95f3500]
> /home/y/bin/traffic_server(_ZN10HttpTunnel12producer_runEP18HttpTunnelProducer+0x25f)[0x568daf]
> /home/y/bin/traffic_server(_ZN10HttpTunnel10tunnel_runEP18HttpTunnelProducer+0xd9)[0x569f09]
> /home/y/bin/traffic_server(_ZN6HttpSM23setup_internal_transferEMS_FiiPvE+0x632)[0x526172]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x487)[0x532357]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x529220]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8a)[0x52f1ba]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b5ad4]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2ab03679ad5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x529084]
> /home/y/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x114)[0x530714]
> /home/y/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3aa)[0x53227a]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x529220]
> /home/y/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8a)[0x52f1ba]
> /home/y/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b5ad4]
> /home/y/libexec64/trafficserver/header_filter.so(+0x2d5d)[0x2ab03679ad5d]
> /home/y/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x114)[0x529084]
> /home/y/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x390)[0x52c830]
> /home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x52efc8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection14readSignalDoneEiP10NetHandler+0x3d)[0x67fc3d]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xb91)[0x6704b1]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x679632]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a1aff]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a24e3]
> /home/y/bin/traffic_server[0x6a099a]
> /lib64/libpthread.so.0(+0x3f82407851)[0x2aafe95eb851]
> /lib64/libc.so.6(clone+0x6d)[0x3f820e890d]
> {quote}
> Backtrace:
> {quote}
> #0 operator= (this=, p=) at
> ../../lib/ts/Ptr.h:425
> #1 clone_reader (this=, p=) at
> ../../iocore/eventsystem/P_IOBuffer.h:873
> #2 HttpTunnel::producer_run (this=, p= out>) at HttpTunnel.cc:831
> #3 0x00569f09 in HttpTunnel::tunnel_run (this=0x2ba83d9425e8,
> p_arg=0x0) at HttpTunnel.cc:698
> #4 0x00526172 in HttpSM::setup_internal_transfer
> (this=0x2ba83d940a50, handler_arg=(int (HttpSM::*)(HttpSM *, int, void *))
> 0x5328d0 ) at HttpSM.cc:5872
> #5 0x00532357 in HttpSM::handle_api_return (this=0x2ba83d940a50) at
> HttpSM.cc:1598
> #6 0x00529220 in HttpSM::state_api_callout (this=0x2ba83d940a50,
> event=6, data=0x0) at HttpSM.cc:1484
> #7 0x0052f1ba in HttpSM::state_api_callback (this=0x2ba83d940a50,
> event=6, data=0x0) at HttpSM.cc:1303
> #8 0x004b5ad4 in TSHttpTxnReenable (txnp=0x2ba83d940a50,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5530
> #9 0x2ba69a79ad5d in cont_header_filter (event=,
> edata=0x2ba83d940a50) at header_filter.cc:90
> #10 0x00529084 in HttpSM::state_api_callout (this=0x2ba83d940a50,
> event=, data=) at HttpSM.cc:1410
> #11 0x00530714 in HttpSM::set_next_state (this=0x2ba83d940a50) at
> HttpSM.cc:
[jira] [Created] (TS-2108) TsConfig doesn't build with bison 3.0
James Peach created TS-2108:
---
Summary: TsConfig doesn't build with bison 3.0
Key: TS-2108
URL: https://issues.apache.org/jira/browse/TS-2108
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
With bison 3.0, the generated code has changes such that BisonHeaderToC.sed no
longer edits the generated header correctly.
TsConfigGrammar ends up looking like this:
{code}
namespace ts { namespace config {
enum TokenType {
{
STRING = 258,
IDENT = 259,
INTEGER = 260,
LIST_OPEN = 261,
LIST_CLOSE = 262,
GROUP_OPEN = 263,
GROUP_CLOSE = 264,
PATH_OPEN = 265,
PATH_CLOSE = 266,
PATH_SEPARATOR = 267,
SEPARATOR = 268,
ASSIGN = 269
};
}} // namespace ts::config
{code}
Maybe a more robust solution would be to include the generated header into
another file that does the namespace.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2108) TsConfig doesn't build with bison 3.0
[
https://issues.apache.org/jira/browse/TS-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732572#comment-13732572
]
James Peach commented on TS-2108:
-
The original bison file is:
{code}
/* A Bison parser, made by GNU Bison 3.0. */
/* Bison interface for Yacc-like parsers in C
Copyright (C) 1984, 1989-1990, 2000-2013 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see
[jira] [Created] (TS-2109) Cache-Control: no-cache responses are not stored the cache
Igor Brezac created TS-2109: --- Summary: Cache-Control: no-cache responses are not stored the cache Key: TS-2109 URL: https://issues.apache.org/jira/browse/TS-2109 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Igor Brezac This can be duplicated using 3.3.5-dev (trunk). Cache-Control: must-revalidate suffers from the same issue. Cache-Control: max-age=0,must-revalidate works correctly -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1597) document remap.config filtering directives
[
https://issues.apache.org/jira/browse/TS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Riggs updated TS-1597:
--
Attachment: 0002-TS-1597-Add-documentation-and-examples-for-the-.defi.patch
0001-TS-1597-Add-documentation-and-examples-for-the-.defi.patch
TS-1597 - Add documentation and examples for the .definefilter,
.activatefilter, and .deactivatefilter directives in remap.config.
These docs are specifically restricted to these particular names because (1) we
should standardize on one variant for each of these directives to avoid
end-user confusion and (2) I personally believe these variants to be the
clearest and most understandable ("defflt", "useflt", "deuseflt", etc., are
confusing or awkward).
The .deletefilter directive is not documented, because I am not sure when or
why it would be used.
0001 patch is for git (remap.config.default)
0002 patch is for svn (admin documentation)
> document remap.config filtering directives
> --
>
> Key: TS-1597
> URL: https://issues.apache.org/jira/browse/TS-1597
> Project: Traffic Server
> Issue Type: Improvement
> Components: Documentation
>Reporter: James Peach
> Fix For: sometime
>
> Attachments:
> 0001-TS-1597-Add-documentation-and-examples-for-the-.defi.patch,
> 0002-TS-1597-Add-documentation-and-examples-for-the-.defi.patch
>
>
> See UrlRewrite.cc:parse_directive().
> remap.config supports a number of directives that do something:
> .definefilter, .deletefilter, .usefilter, .unusefilter
> These are briefly mentioned in remap.config, but we should provide sufficient
> documentation for people to make use of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1597) document remap.config filtering directives
[ https://issues.apache.org/jira/browse/TS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1597: --- Assignee: James Peach > document remap.config filtering directives > -- > > Key: TS-1597 > URL: https://issues.apache.org/jira/browse/TS-1597 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Peach >Assignee: James Peach > Fix For: sometime > > Attachments: > 0001-TS-1597-Add-documentation-and-examples-for-the-.defi.patch, > 0002-TS-1597-Add-documentation-and-examples-for-the-.defi.patch > > > See UrlRewrite.cc:parse_directive(). > remap.config supports a number of directives that do something: > .definefilter, .deletefilter, .usefilter, .unusefilter > These are briefly mentioned in remap.config, but we should provide sufficient > documentation for people to make use of them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1597) document remap.config filtering directives
[ https://issues.apache.org/jira/browse/TS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1597: Fix Version/s: (was: sometime) 3.3.6 Nice, let's merge this for 3.4. We are transitioning the documentation to sphinx, so I'll commit your patch to the current docs and also translate to sphinx for 3.4 > document remap.config filtering directives > -- > > Key: TS-1597 > URL: https://issues.apache.org/jira/browse/TS-1597 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.6 > > Attachments: > 0001-TS-1597-Add-documentation-and-examples-for-the-.defi.patch, > 0002-TS-1597-Add-documentation-and-examples-for-the-.defi.patch > > > See UrlRewrite.cc:parse_directive(). > remap.config supports a number of directives that do something: > .definefilter, .deletefilter, .usefilter, .unusefilter > These are briefly mentioned in remap.config, but we should provide sufficient > documentation for people to make use of them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1823) config file line continuation support
[ https://issues.apache.org/jira/browse/TS-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1823: Fix Version/s: (was: 3.5.1) 3.3.6 Assignee: James Peach There's some general config file parsing routines, so in the future we should look at pushing this change down. For now, remap.config is the file that needs this the most, so this looks like a really useful and safe patch for 3.4. > config file line continuation support > - > > Key: TS-1823 > URL: https://issues.apache.org/jira/browse/TS-1823 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.6 > > Attachments: > 0001-Add-line-continuation-to-remap.config-using-a-backsl.patch > > > It looks like remap.config does not support line continuation. We should add > generic line continuation support so that all config files get it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1597) document remap.config filtering directives
[ https://issues.apache.org/jira/browse/TS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733128#comment-13733128 ] ASF subversion and git services commented on TS-1597: - Commit 1511576 from [~jpe...@apache.org] in branch 'site/trunk' [ https://svn.apache.org/r1511576 ] TS-1597: document remap.config filtering directives Author: Jim Riggs > document remap.config filtering directives > -- > > Key: TS-1597 > URL: https://issues.apache.org/jira/browse/TS-1597 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.6 > > Attachments: > 0001-TS-1597-Add-documentation-and-examples-for-the-.defi.patch, > 0002-TS-1597-Add-documentation-and-examples-for-the-.defi.patch > > > See UrlRewrite.cc:parse_directive(). > remap.config supports a number of directives that do something: > .definefilter, .deletefilter, .usefilter, .unusefilter > These are briefly mentioned in remap.config, but we should provide sufficient > documentation for people to make use of them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1597) document remap.config filtering directives
[
https://issues.apache.org/jira/browse/TS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733132#comment-13733132
]
ASF subversion and git services commented on TS-1597:
-
Commit caf79a236e892518f8ab16304a7efd5d727b903a in branch refs/heads/master
from [~jhriggs]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=caf79a2 ]
TS-1597: Document remap.config filters
Add documentation and examples for the
.definefilter, .activatefilter, and .deactivatefilter
directives in remap.config.
These docs are specifically restricted to these particular names
because (1) we should standardize on one variant for each of these
directives to avoid end-user confusion and (2) I personally believe
these variants to be the clearest and most understandable ("defflt",
"useflt", "deuseflt", etc., are confusing or awkward).
The .deletefilter directive is not documented, because I am not sure
when or why it would be used.
> document remap.config filtering directives
> --
>
> Key: TS-1597
> URL: https://issues.apache.org/jira/browse/TS-1597
> Project: Traffic Server
> Issue Type: Improvement
> Components: Documentation
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 3.3.6
>
> Attachments:
> 0001-TS-1597-Add-documentation-and-examples-for-the-.defi.patch,
> 0002-TS-1597-Add-documentation-and-examples-for-the-.defi.patch
>
>
> See UrlRewrite.cc:parse_directive().
> remap.config supports a number of directives that do something:
> .definefilter, .deletefilter, .usefilter, .unusefilter
> These are briefly mentioned in remap.config, but we should provide sufficient
> documentation for people to make use of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1823) config file line continuation support
[ https://issues.apache.org/jira/browse/TS-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733162#comment-13733162 ] ASF subversion and git services commented on TS-1823: - Commit 1ddfc042fc8df6a92dc3c74718451db0a7ec3f93 in branch refs/heads/master from [~jhriggs] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1ddfc04 ] TS-1823: add line continuation to remap.config Add line continuation to remap.config using a backslash at the end of a line as the continuation character. The handling for continuation was made in tokLine() by adding an optional third char parameter (`cont') which is the continuation character. This should make it usable in other contexts outside of remap.config also, for example other config file parsers. This implementation is not very intelligent, as it only checks for the backslash immediately preceding the newline and does not handle any whitespace. The backslash and newline are converted into spaces, and the next line is appended. Example: .definefilter foo \ @action=allow \ @src_ip=127.0.0.1 is read and parsed in UrlRewrite::BuildTable() as: .definefilter foo @action=allow @src_ip=127.0.0.1 > config file line continuation support > - > > Key: TS-1823 > URL: https://issues.apache.org/jira/browse/TS-1823 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.6 > > Attachments: > 0001-Add-line-continuation-to-remap.config-using-a-backsl.patch > > > It looks like remap.config does not support line continuation. We should add > generic line continuation support so that all config files get it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
