[jira] [Assigned] (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
]
Sudheer Vinukonda reassigned TS-3184:
-
Assignee: Sudheer Vinukonda
> 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
>
> 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] [Resolved] (TS-3138) Implement TLS False Start
[ https://issues.apache.org/jira/browse/TS-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-3138. -- Resolution: Implemented This is fully verified as working and I'm closing this issue. > Implement TLS False Start > - > > Key: TS-3138 > URL: https://issues.apache.org/jira/browse/TS-3138 > Project: Traffic Server > Issue Type: New Feature > Components: Core, SSL >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.2.0 > > Attachments: disabled_tls_falsestart_ats.png, > enabled_tls_falsestart_ats.png > > > TLS false start can really reduce latency by allowing data to be transmitted > before the CipherChange has been completed. For more information see: > http://chimera.labs.oreilly.com/books/123000545/ch04.html#TLS_FALSE_START > and http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00 > We need to 1) verify that Traffic Server correctly reads data that was > transmitted as false start before the hand shake is "officially complete." > and 2) if it's not then determine why the read is not happening earlier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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
]
Sudheer Vinukonda resolved TS-3184.
---
Resolution: Fixed
> 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
>
> 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] [Commented] (TS-2600) HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208896#comment-14208896 ] Bryan Call commented on TS-2600: There needs to be a detailed proposal on what needs to change. Right now the changes for the bug are somewhat vague and needs to be defined more or this bug runs the risk of being closed as won't fix or invalid... > HTTPS statistics > > > Key: TS-2600 > URL: https://issues.apache.org/jira/browse/TS-2600 > Project: Traffic Server > Issue Type: Improvement > Components: Metrics, SSL >Reporter: David Carlin >Assignee: Bryan Call > Labels: Review > Fix For: 6.0.0 > > > It would be swell if there were some traffic_line SSL statistic variables. > For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-2676) crash when enable --enable-linux-native-aio
[
https://issues.apache.org/jira/browse/TS-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2676.
---
Resolution: Duplicate
Fix Version/s: (was: sometime)
Almost certain this is a dupe of TS-3053, which has better details.
> crash when enable --enable-linux-native-aio
>
>
> Key: TS-2676
> URL: https://issues.apache.org/jira/browse/TS-2676
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
> Labels: crash
>
> Centos 6 x86_64 gitmaster version
> when enable --enable-linux-native-aio ,ATS will be crash
> (gdb) bt
> #0 0x006bb2e2 in Queue Continuation::Link_link>::enqueue (this=0x8040, e=0x2b2077f60180) at
> ../../lib/ts/List.h:290
> #1 0x006bad5b in ink_aio_read (op=0x2b2077f60180) at AIO.cc:605
> #2 0x006800d5 in CacheVC::handleRead (this=0x2b2077f6) at
> Cache.cc:2605
> #3 0x00687922 in CacheVC::do_read_call (this=0x2b2077f6,
> akey=0x2b2077f60038) at P_CacheInternal.h:703
> #4 0x0068088a in CacheVC::removeEvent (this=0x2b2077f6) at
> Cache.cc:2733
> #5 0x00680c8b in Cache::remove (this=0x3f62270, cont=0x2b1ea8a764e0,
> key=0x103fbb40, type=CACHE_FRAG_TYPE_NONE, hostname=0x0,
> host_len=0) at Cache.cc:2787
> #6 0x0050e60e in CacheProcessor::remove (this=0xf91ef0,
> cont=0x2b1ea8a764e0, key=0x103fbb40, cluster_cache_local=true,
> frag_type=CACHE_FRAG_TYPE_NONE, rm_user_agents=true, rm_link=false,
> hostname=0x0, host_len=0) at ../iocore/cache/P_CacheInternal.h:1254
> #7 0x00507365 in TSCacheRemove (contp=0x2b1ea8a764e0,
> key=0x103fbb40) at InkAPI.cc:6644
> (gdb) f 1
> #1 0x006bad5b in ink_aio_read (op=0x2b2077f60180) at AIO.cc:605
> 605 this_ethread()->diskHandler->ready_list.enqueue(op);
> (gdb) list
> 600 int
> 601 ink_aio_read(AIOCallback *op, int /* fromAPI ATS_UNUSED */) {
> 602 op->aiocb.aio_reqprio = AIO_DEFAULT_PRIORITY;
> 603 op->aiocb.aio_lio_opcode = IO_CMD_PREAD;
> 604 op->aiocb.data = op;
> 605 this_ethread()->diskHandler->ready_list.enqueue(op);
> 606
> 607 return 1;
> 608 }
> 609
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3053) enable-linux-native-aio crash
[
https://issues.apache.org/jira/browse/TS-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3053:
--
Fix Version/s: (was: 5.2.0)
5.3.0
> enable-linux-native-aio crash
> -
>
> Key: TS-3053
> URL: https://issues.apache.org/jira/browse/TS-3053
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Qiang Li
> Fix For: 5.3.0
>
>
> configure with --enable-linux-native-aio it will crash sometime
> {code}
> (gdb) bt
> #0 enqueue (op=0x2aaae465ecc0) at ../../lib/ts/List.h:290
> #1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
> #2 0x006ca458 in CacheVC::handleRead (this=0x2aaae465eb40) at
> Cache.cc:2756
> #3 0x006ef52e in Cache::open_read (this=,
> cont=0x2aaaf0101a30, key=, request=0x2aaaf0100708,
> params=0x2aaaf01000e0, type=,
> hostname=0x2aaaf0240073
> "cdn.u1.huluxia.comhttpg1/M00/0C/8D/wKgBB1QAtUOAXXj-AAARZtl9MXk020.jpg_160x160.jpegcdn.u1.huluxia.com\377",
> host_len=18)
> at CacheRead.cc:136
> #4 0x006ccf6d in open_read (this=,
> cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local= out>,
> request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
> type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1083
> #5 CacheProcessor::open_read (this=,
> cont=0x2aaaf0101a30, url=0x2aaaf0100720, cluster_cache_local= out>,
> request=0x2aaaf0100708, params=0x2aaaf01000e0, pin_in_cache=0,
> type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3600
> #6 0x00588d94 in do_cache_open_read (this=,
> url=, hdr=,
> params=, pin_in_cache=) at
> HttpCacheSM.cc:216
> #7 HttpCacheSM::open_read (this=, url= out>, hdr=, params=,
> pin_in_cache=) at HttpCacheSM.cc:248
> #8 0x005961e3 in HttpSM::do_cache_lookup_and_read
> (this=0x2aaaf010) at HttpSM.cc:4330
> #9 0x005af784 in HttpSM::set_next_state (this=0x2aaaf010) at
> HttpSM.cc:6992
> #10 0x005a8ec2 in HttpSM::handle_api_return (this=0x2aaaf010) at
> HttpSM.cc:1509
> #11 0x005a95c0 in HttpSM::state_api_callout (this=0x2aaaf010,
> event=0, data=0x0) at HttpSM.cc:1441
> #12 0x005af26a in HttpSM::set_next_state (this=0x2aaaf010) at
> HttpSM.cc:6882
> #13 0x0059563e in HttpSM::state_remap_request (this=0x2aaaf010,
> event=63002) at HttpSM.cc:3826
> #14 0x005ac598 in HttpSM::main_handler (this=0x2aaaf010,
> event=63002, data=0x0) at HttpSM.cc:2546
> #15 0x00605c3a in handleEvent (this=0x2aaacc548000, event=1,
> e=0x2aaaf024ed20) at ../../../iocore/eventsystem/I_Continuation.h:146
> #16 RemapPlugins::run_remap (this=0x2aaacc548000, event=1, e=0x2aaaf024ed20)
> at RemapPlugins.cc:180
> #17 0x0074656f in handleEvent (this=0x2afd7171f010, e=0x2aaaf024ed20,
> calling_code=1) at I_Continuation.h:146
> #18 EThread::process_event (this=0x2afd7171f010, e=0x2aaaf024ed20,
> calling_code=1) at UnixEThread.cc:144
> #19 0x00746edb in EThread::execute (this=0x2afd7171f010) at
> UnixEThread.cc:195
> #20 0x0074590a in spawn_thread_internal (a=0x1b86300) at Thread.cc:88
> #21 0x2afd68f2e9d1 in start_thread () from /lib64/libpthread.so.0
> #22 0x2afd69f24b6d in clone () from /lib64/libc.so.6
> (gdb) f 1
> #1 ink_aio_read (op=0x2aaae465ecc0) at AIO.cc:611
> 611 t->diskHandler->ready_list.enqueue(op);
> (gdb) p t->diskHandler
> $1 = (DiskHandler *) 0x0
> (gdb)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2676) crash when enable --enable-linux-native-aio
[
https://issues.apache.org/jira/browse/TS-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2676:
--
Assignee: (was: Zhao Yongming)
> crash when enable --enable-linux-native-aio
>
>
> Key: TS-2676
> URL: https://issues.apache.org/jira/browse/TS-2676
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
> Labels: crash
> Fix For: sometime
>
>
> Centos 6 x86_64 gitmaster version
> when enable --enable-linux-native-aio ,ATS will be crash
> (gdb) bt
> #0 0x006bb2e2 in Queue Continuation::Link_link>::enqueue (this=0x8040, e=0x2b2077f60180) at
> ../../lib/ts/List.h:290
> #1 0x006bad5b in ink_aio_read (op=0x2b2077f60180) at AIO.cc:605
> #2 0x006800d5 in CacheVC::handleRead (this=0x2b2077f6) at
> Cache.cc:2605
> #3 0x00687922 in CacheVC::do_read_call (this=0x2b2077f6,
> akey=0x2b2077f60038) at P_CacheInternal.h:703
> #4 0x0068088a in CacheVC::removeEvent (this=0x2b2077f6) at
> Cache.cc:2733
> #5 0x00680c8b in Cache::remove (this=0x3f62270, cont=0x2b1ea8a764e0,
> key=0x103fbb40, type=CACHE_FRAG_TYPE_NONE, hostname=0x0,
> host_len=0) at Cache.cc:2787
> #6 0x0050e60e in CacheProcessor::remove (this=0xf91ef0,
> cont=0x2b1ea8a764e0, key=0x103fbb40, cluster_cache_local=true,
> frag_type=CACHE_FRAG_TYPE_NONE, rm_user_agents=true, rm_link=false,
> hostname=0x0, host_len=0) at ../iocore/cache/P_CacheInternal.h:1254
> #7 0x00507365 in TSCacheRemove (contp=0x2b1ea8a764e0,
> key=0x103fbb40) at InkAPI.cc:6644
> (gdb) f 1
> #1 0x006bad5b in ink_aio_read (op=0x2b2077f60180) at AIO.cc:605
> 605 this_ethread()->diskHandler->ready_list.enqueue(op);
> (gdb) list
> 600 int
> 601 ink_aio_read(AIOCallback *op, int /* fromAPI ATS_UNUSED */) {
> 602 op->aiocb.aio_reqprio = AIO_DEFAULT_PRIORITY;
> 603 op->aiocb.aio_lio_opcode = IO_CMD_PREAD;
> 604 op->aiocb.data = op;
> 605 this_ethread()->diskHandler->ready_list.enqueue(op);
> 606
> 607 return 1;
> 608 }
> 609
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2676) crash when enable --enable-linux-native-aio
[
https://issues.apache.org/jira/browse/TS-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2676:
--
Labels: crash (was: )
> crash when enable --enable-linux-native-aio
>
>
> Key: TS-2676
> URL: https://issues.apache.org/jira/browse/TS-2676
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
> Labels: crash
> Fix For: sometime
>
>
> Centos 6 x86_64 gitmaster version
> when enable --enable-linux-native-aio ,ATS will be crash
> (gdb) bt
> #0 0x006bb2e2 in Queue Continuation::Link_link>::enqueue (this=0x8040, e=0x2b2077f60180) at
> ../../lib/ts/List.h:290
> #1 0x006bad5b in ink_aio_read (op=0x2b2077f60180) at AIO.cc:605
> #2 0x006800d5 in CacheVC::handleRead (this=0x2b2077f6) at
> Cache.cc:2605
> #3 0x00687922 in CacheVC::do_read_call (this=0x2b2077f6,
> akey=0x2b2077f60038) at P_CacheInternal.h:703
> #4 0x0068088a in CacheVC::removeEvent (this=0x2b2077f6) at
> Cache.cc:2733
> #5 0x00680c8b in Cache::remove (this=0x3f62270, cont=0x2b1ea8a764e0,
> key=0x103fbb40, type=CACHE_FRAG_TYPE_NONE, hostname=0x0,
> host_len=0) at Cache.cc:2787
> #6 0x0050e60e in CacheProcessor::remove (this=0xf91ef0,
> cont=0x2b1ea8a764e0, key=0x103fbb40, cluster_cache_local=true,
> frag_type=CACHE_FRAG_TYPE_NONE, rm_user_agents=true, rm_link=false,
> hostname=0x0, host_len=0) at ../iocore/cache/P_CacheInternal.h:1254
> #7 0x00507365 in TSCacheRemove (contp=0x2b1ea8a764e0,
> key=0x103fbb40) at InkAPI.cc:6644
> (gdb) f 1
> #1 0x006bad5b in ink_aio_read (op=0x2b2077f60180) at AIO.cc:605
> 605 this_ethread()->diskHandler->ready_list.enqueue(op);
> (gdb) list
> 600 int
> 601 ink_aio_read(AIOCallback *op, int /* fromAPI ATS_UNUSED */) {
> 602 op->aiocb.aio_reqprio = AIO_DEFAULT_PRIORITY;
> 603 op->aiocb.aio_lio_opcode = IO_CMD_PREAD;
> 604 op->aiocb.data = op;
> 605 this_ethread()->diskHandler->ready_list.enqueue(op);
> 606
> 607 return 1;
> 608 }
> 609
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-2537) Segmentation Fault with cache files and linux native AIO
[
https://issues.apache.org/jira/browse/TS-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2537.
---
Resolution: Duplicate
I'm pretty sure this is a dupe, the trace on TS-3053 has slightly better
details.
> Segmentation Fault with cache files and linux native AIO
>
>
> Key: TS-2537
> URL: https://issues.apache.org/jira/browse/TS-2537
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.1.2
>Reporter: Thomas Berger
> Labels: crash
> Fix For: sometime
>
>
> We have multiple crashes with trafficserver if we use AIO.
> {code}
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf030)[0x2ba879a1e030]
> /usr/bin/traffic_server(ink_aio_read(AIOCallback*, int)+0x26)[0x605796]
> /usr/bin/traffic_server(CacheVC::handleRead(int, Event*)+0x5c1)[0x5db1c1]
> /usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
> CacheLookupHttpConfig*, CacheFragType, char*, int)+0x55e)[0x5f23ae]
> /usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*, bool,
> HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x86)[0x5dd176]
> /usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
> CacheLookupHttpConfig*, long)+0x8e)[0x4f6f1e]
> /usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0x102)[0x513812]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1a1)[0x5162f1]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x174a)[0x51789a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/gzip.so(+0x4c9e)[0x2ba884004c9e]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x88)[0x506998]
> /usr/bin/traffic_server(TSHttpTxnReenable+0xd0)[0x4b3750]
> /usr/lib/trafficserver/header_filter.so(+0x2acf)[0x2ba87fc03acf]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x66c)[0x5070fc]
> /usr/bin/traffic_server(HttpSM::set_next_state()+0x1289)[0x5173d9]
> /usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x524)[0x503df4]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x95)[0x5028c5]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x3f7)[0x506e87]
> /usr/bin/traffic_server(HttpSM::state_add_to_list(int, void*)+0x14f)[0x50302f]
> /usr/bin/traffic_server(HttpSM::attach_client_session(HttpClientSession*,
> IOBufferReader*)+0x434)[0x503894]
> /usr/bin/traffic_server(HttpClientSession::state_keep_alive(int, void*)+0x8b)
> [0x4f873b]
> /usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x2e)
> [0x6157de]
> /usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
> EThread*)+0x807)[0x6078f7]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x4e7)[0x60f6e7]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x15a)[0x62c10a]
> /usr/bin/traffic_server(EThread::execute()+0x954)[0x62ccb4]
> /usr/bin/traffic_server[0x62b174]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x2ba879a15b50]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ba87a426a7d]
> {code}
> If we deactivate the cache files, we have no cache, but also no crashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2512:
--
Labels: incompatible (was: )
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
> Labels: incompatible
> Fix For: 6.0.0
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2512:
-
Assignee: Leif Hedstrom
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Labels: incompatible
> Fix For: 6.0.0
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208868#comment-14208868
]
Leif Hedstrom edited comment on TS-2512 at 11/12/14 11:14 PM:
--
Is there a reason not to do this (deprecating the plugin)? Just bringing it
down to a single plugin would be better IMO.
was (Author: zwoop):
Is there a reason not to do this? Just bringing it down to a single plugin
would be better IMO.
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
> Labels: incompatible
> Fix For: 6.0.0
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208868#comment-14208868
]
Leif Hedstrom commented on TS-2512:
---
Is there a reason not to do this? Just bringing it down to a single plugin
would be better IMO.
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 6.0.0
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2565) ALPN: configure protocol selection
[ https://issues.apache.org/jira/browse/TS-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208757#comment-14208757 ] Sudheer Vinukonda commented on TS-2565: --- TS-3153 developed a sni_proto_plugin that allows to enable/disable npn/alpn based on SNI. On an initial look, the same plugin can be enhanced to actually use a configured npn/alpn advertisement list to satisfy this requirement. The SNI hook that [~shinrich] added passes the netVC object to the plugin call back, so, it should be possible to associate a different set of advertised list for each SNI. > ALPN: configure protocol selection > -- > > Key: TS-2565 > URL: https://issues.apache.org/jira/browse/TS-2565 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, SSL >Reporter: James Peach >Assignee: Sudheer Vinukonda > Fix For: sometime > > > Once there is a meaningful set of protocols that uses ALPN, we should have a > way for operators to configure the ALP protocol selection. For example, some > sites might want to prefer HTTP1 to HTTP2, some sites might want the reverse. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2512:
--
Fix Version/s: (was: sometime)
6.0.0
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 6.0.0
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2573) Exponentional increasing of cluster timeouts
[ https://issues.apache.org/jira/browse/TS-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208745#comment-14208745 ] Peter Walsh commented on TS-2573: - It has been awhile since I looked into it, but I recall there was a 5 second timeout when peer fetching. It was not configurable (that I recall). Once a particular node in the cluster entered this "bad state", we saw continual timeouts with peer fetching until it was restarted. But since this is not a concern at this point, I'd say go ahead and close it. I can reopen if necessary. I last saw it on 4.0.1 so I am not even sure if the bug is still in the current code base. > Exponentional increasing of cluster timeouts > > > Key: TS-2573 > URL: https://issues.apache.org/jira/browse/TS-2573 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Peter Walsh > Fix For: sometime > > > Occasionally we see cluster operations will start timing out after 5 seconds. > This will continue at an increasing rate until traffic server is restarted. > The following stats increase when this happens, > proxy.process.cluster.remote_op_timeouts and > proxy.process.cluster.connections_open. > I can tell that spikes in IO wait can contribute to this issue. > Any ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2565) ALPN: configure protocol selection
[ https://issues.apache.org/jira/browse/TS-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208738#comment-14208738 ] Sudheer Vinukonda commented on TS-2565: --- This requirement can be handled using SNI based configurable ALPN protocol lists (for example, by enhancing the sni_proto_nego plugin in TS-3153). > ALPN: configure protocol selection > -- > > Key: TS-2565 > URL: https://issues.apache.org/jira/browse/TS-2565 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, SSL >Reporter: James Peach >Assignee: Sudheer Vinukonda > Fix For: sometime > > > Once there is a meaningful set of protocols that uses ALPN, we should have a > way for operators to configure the ALP protocol selection. For example, some > sites might want to prefer HTTP1 to HTTP2, some sites might want the reverse. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-2573) Exponentional increasing of cluster timeouts
[ https://issues.apache.org/jira/browse/TS-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208733#comment-14208733 ] Leif Hedstrom edited comment on TS-2573 at 11/12/14 9:31 PM: - Interesting. Does that 5s timeouts correlate to a specific configuration setting? Should we just close this Jira for now? As for clustering, the primary customer of clustering, Taobao, no longer uses nor supports ATS. It's unclear what the future holds of this future right now. But there are no plans as of now to remove it, we're hoping to see more development on the feature as others gets interested in it. was (Author: zwoop): Interesting. Does that 5s timeouts correlate to a specific bug? Should we just close this Jira for now? As for clustering, the primary customer of clustering, Taobao, no longer uses nor supports ATS. It's unclear what the future holds of this future right now. But there are no plans as of now to remove it, we're hoping to see more development on the feature as others gets interested in it. > Exponentional increasing of cluster timeouts > > > Key: TS-2573 > URL: https://issues.apache.org/jira/browse/TS-2573 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Peter Walsh > Fix For: sometime > > > Occasionally we see cluster operations will start timing out after 5 seconds. > This will continue at an increasing rate until traffic server is restarted. > The following stats increase when this happens, > proxy.process.cluster.remote_op_timeouts and > proxy.process.cluster.connections_open. > I can tell that spikes in IO wait can contribute to this issue. > Any ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208736#comment-14208736
]
Phil Sorber commented on TS-2512:
-
I have no bandwidth for this. The remap_stats plugin does what you suggest.
Perhaps we should evaluate if this can be deprecated?
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2573) Exponentional increasing of cluster timeouts
[ https://issues.apache.org/jira/browse/TS-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208733#comment-14208733 ] Leif Hedstrom commented on TS-2573: --- Interesting. Does that 5s timeouts correlate to a specific bug? Should we just close this Jira for now? As for clustering, the primary customer of clustering, Taobao, no longer uses nor supports ATS. It's unclear what the future holds of this future right now. But there are no plans as of now to remove it, we're hoping to see more development on the feature as others gets interested in it. > Exponentional increasing of cluster timeouts > > > Key: TS-2573 > URL: https://issues.apache.org/jira/browse/TS-2573 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Peter Walsh > Fix For: sometime > > > Occasionally we see cluster operations will start timing out after 5 seconds. > This will continue at an increasing rate until traffic server is restarted. > The following stats increase when this happens, > proxy.process.cluster.remote_op_timeouts and > proxy.process.cluster.connections_open. > I can tell that spikes in IO wait can contribute to this issue. > Any ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2572) Response header corruption when transforming cached objects
[ https://issues.apache.org/jira/browse/TS-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208727#comment-14208727 ] Peter Walsh commented on TS-2572: - Hi Leif, as of 4.2.2 this was still happening. I strongly suspect the issue to be related to clustering but haven't been able to find root cause. > Response header corruption when transforming cached objects > --- > > Key: TS-2572 > URL: https://issues.apache.org/jira/browse/TS-2572 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Peter Walsh > Fix For: sometime > > > I have a transform that caches the untransformed response, so that way I > perform the transformation for each subsequent cache hit of that document. > Whenever the response is peer fetched from another node in the cluster, the > response headers are partially overwritten by the response data. This does > not happen when the response is NOT cached, and it does NOT happen when NOT > using cluster feature. > In my transform plugin I use TSIOBufferCreate to a create the buffer which > gets written into by TSIOBufferWrite with the desired response body. > When a response is peer fetched from cache, the address of the transformed > response header's values (I'm printing address using > TSHttpTxnTransformRespGet and other API's) starts halfway into the buffer > allocated by TSIOBufferCreate. So if I write about 2k into it, I > overwrite my response transform headers. > When the response is not from cache, or when the response is from cache > and we're not in a cluster, this does NOT happen, ever. Could be > coincidence, but its repeatable for response sizes varying from 5k to 10 > MB. > I don't know how the Transform response headers values can share the same > memory as what I get from calling TSIOBufferCreate, but it does. My > concern is that at a deeper level the memory is being mismanaged, and > while I can check in my transform plugin if I'll overwrite my transform > resp header buffer, but what about other parts of ATS that are utilizing > buffers, or when I have multiple transforms happening at the same time? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2573) Exponentional increasing of cluster timeouts
[ https://issues.apache.org/jira/browse/TS-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208725#comment-14208725 ] Peter Walsh commented on TS-2573: - Hi Leif, We determined the problem was attributed to spikes in disk IO that put ATS in a bad state that resulted in the timeouts I described above. We've taken steps to work around the problem and have not experienced it since. It is possible it can still occur but at this time it is not a concern. As for the clustering, we are still using it heavily. Do you know why others have stopped using clustering or if there is an alternate approach they are using to have a distributed cache? > Exponentional increasing of cluster timeouts > > > Key: TS-2573 > URL: https://issues.apache.org/jira/browse/TS-2573 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Peter Walsh > Fix For: sometime > > > Occasionally we see cluster operations will start timing out after 5 seconds. > This will continue at an increasing rate until traffic server is restarted. > The following stats increase when this happens, > proxy.process.cluster.remote_op_timeouts and > proxy.process.cluster.connections_open. > I can tell that spikes in IO wait can contribute to this issue. > Any ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-2621) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2621.
---
Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)
Please reopen if you have some more details.
> Segmentation fault in 4.2.0-rc0
> ---
>
> Key: TS-2621
> URL: https://issues.apache.org/jira/browse/TS-2621
> Project: Traffic Server
> Issue Type: Bug
> Environment: CentOS release 5.9 (Final) x64
> TS 4.2.0-rc0
>Reporter: helaku
> Labels: crash
>
> {code}
> (gdb) bt
> #0 0x005be56c in ink_atomic_increment
> (this=0x2ada9355a930, block_ref=0x2adbb4b87980)
> at ../../lib/ts/ink_atomic.h:162
> #1 refcount_dec (this=0x2ada9355a930, block_ref=0x2adbb4b87980) at
> ../../lib/ts/Ptr.h:288
> #2 HTTPInfo::set_buffer_reference (this=0x2ada9355a930,
> block_ref=0x2adbb4b87980) at HTTP.cc:2055
> #3 0x0063d845 in set_channel_data_ClusterFunction (ch= optimized out>, tdata=,
> tlen=7008) at ClusterRPC.cc:215
> #4 0x00622bd5 in ClusterHandler::process_set_data_msgs
> (this=0x2adac020a010) at ClusterHandler.cc:911
> #5 0x00626dd6 in ClusterHandler::update_channels_read
> (this=0x2ada9355a930) at ClusterHandler.cc:1105
> #6 0x0062cb54 in ClusterHandler::process_read (this=0x2adac020a010)
> at ClusterHandler.cc:2803
> #7 0x0062d385 in ClusterHandler::mainClusterEvent
> (this=0x2adac020a010, event=, e=0x0)
> at ClusterHandler.cc:2482
> #8 0x0062fce2 in handleEvent (this=0x2adac020a3a0) at
> ../../iocore/eventsystem/I_Continuation.h:146
> #9 ClusterState::IOComplete (this=0x2adac020a3a0) at
> ClusterHandlerBase.cc:583
> #10 0x00630101 in ClusterState::doIO_read_event (this=0x2ada9355a930,
> event=-1262978688, d=)
> at ClusterHandlerBase.cc:481
> #11 0x006a6451 in read_signal_and_update (nh=0x2ada92943c10,
> vc=0x2adabe5ca2c0, thread=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #12 read_signal_done (nh=0x2ada92943c10, vc=0x2adabe5ca2c0, thread= optimized out>) at UnixNetVConnection.cc:168
> #13 read_from_net (nh=0x2ada92943c10, vc=0x2adabe5ca2c0, thread= optimized out>) at UnixNetVConnection.cc:316
> #14 0x0069a7b4 in NetHandler::mainNetEvent (this=0x2ada92943c10,
> event=,
> e=) at UnixNet.cc:384
> #15 0x006ccf18 in EThread::process_event (this=0x2ada92940010,
> e=0x2ada4ea60f60, calling_code=5)
> at I_Continuation.h:146
> #16 0x006cd6ea in EThread::execute (this=0x2ada92940010) at
> UnixEThread.cc:269
> #17 0x006cc56e in spawn_thread_internal (a=0xe530cf0) at Thread.cc:88
> #18 0x2ada4480983d in start_thread () from /lib64/libpthread.so.0
> #19 0x0032f1ad503d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2609) Header rewrite plugin ORIGIN-HOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208723#comment-14208723 ] Leif Hedstrom commented on TS-2609: --- sudheer, can you work with the Yahoo team on this? I'd prefer that we stick to existing syntaxes, such that we don't make it more complex than it already is :). > Header rewrite plugin ORIGIN-HOST condition > --- > > Key: TS-2609 > URL: https://issues.apache.org/jira/browse/TS-2609 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Anil Kumar Myla >Assignee: Sudheer Vinukonda >Priority: Minor > Labels: review > Fix For: sometime > > > Enhance header rewrite plugin to support ORIGIN-HOST condition. Header > rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2609) Header rewrite plugin ORIGIN-HOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2609: -- Assignee: Sudheer Vinukonda (was: Leif Hedstrom) > Header rewrite plugin ORIGIN-HOST condition > --- > > Key: TS-2609 > URL: https://issues.apache.org/jira/browse/TS-2609 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Anil Kumar Myla >Assignee: Sudheer Vinukonda >Priority: Minor > Labels: review > Fix For: sometime > > > Enhance header rewrite plugin to support ORIGIN-HOST condition. Header > rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2600) HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208720#comment-14208720 ] Leif Hedstrom commented on TS-2600: --- [~bcall] What to do with this? > HTTPS statistics > > > Key: TS-2600 > URL: https://issues.apache.org/jira/browse/TS-2600 > Project: Traffic Server > Issue Type: Improvement > Components: Metrics, SSL >Reporter: David Carlin >Assignee: Bryan Call > Labels: Review > Fix For: 6.0.0 > > > It would be swell if there were some traffic_line SSL statistic variables. > For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2600) HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2600: -- Assignee: Bryan Call (was: Ron Barber) > HTTPS statistics > > > Key: TS-2600 > URL: https://issues.apache.org/jira/browse/TS-2600 > Project: Traffic Server > Issue Type: Improvement > Components: Metrics, SSL >Reporter: David Carlin >Assignee: Bryan Call > Labels: Review > Fix For: 6.0.0 > > > It would be swell if there were some traffic_line SSL statistic variables. > For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2597) QoS (Quality of Service) Support ZPH (Zero Penalty HIT)
[ https://issues.apache.org/jira/browse/TS-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208718#comment-14208718 ] Leif Hedstrom commented on TS-2597: --- Jack, is this actionable? Or do we have appropriate coverage in docs and features? If so, please close this ticket as won't fix (remember to remove the fix version). > QoS (Quality of Service) Support ZPH (Zero Penalty HIT) > --- > > Key: TS-2597 > URL: https://issues.apache.org/jira/browse/TS-2597 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Faysal Banna >Assignee: Jack Bates > Fix For: sometime > > > Hello there. > I know it would be easy for someone in development team to create a module > (plugin) that enables to set QoS markers on outgoing traffic. > as such : > Allows admin to set a TOS/Diffserv value to mark local hits. > thus allowing missed (non locally cached )objects to have certain > TOS/Diffserv and HITs (locally cached) objects to have different TOS/Diffserv. > Much Regards > Faysal Banna -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2600) HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2600: -- Fix Version/s: (was: 5.2.0) 6.0.0 > HTTPS statistics > > > Key: TS-2600 > URL: https://issues.apache.org/jira/browse/TS-2600 > Project: Traffic Server > Issue Type: Improvement > Components: Metrics, SSL >Reporter: David Carlin >Assignee: Bryan Call > Labels: Review > Fix For: 6.0.0 > > > It would be swell if there were some traffic_line SSL statistic variables. > For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2597) QoS (Quality of Service) Support ZPH (Zero Penalty HIT)
[ https://issues.apache.org/jira/browse/TS-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2597: -- Assignee: Jack Bates > QoS (Quality of Service) Support ZPH (Zero Penalty HIT) > --- > > Key: TS-2597 > URL: https://issues.apache.org/jira/browse/TS-2597 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Faysal Banna >Assignee: Jack Bates > Fix For: sometime > > > Hello there. > I know it would be easy for someone in development team to create a module > (plugin) that enables to set QoS markers on outgoing traffic. > as such : > Allows admin to set a TOS/Diffserv value to mark local hits. > thus allowing missed (non locally cached )objects to have certain > TOS/Diffserv and HITs (locally cached) objects to have different TOS/Diffserv. > Much Regards > Faysal Banna -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2591: -- Fix Version/s: (was: 5.2.0) 5.3.0 > Cache does not invalidate variant/alternate content types on PUT or POST > - > > Key: TS-2591 > URL: https://issues.apache.org/jira/browse/TS-2591 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: Norm Paxton >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > "Some HTTP methods MUST cause a cache to invalidate an entity. This is either > the entity referred to by the Request-URI, or by the Location or > Content-Location headers (if present). These methods are: PUT, DELETE, POST." > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 > (This doesn't explicitly address variant content types, I read it as implied.) > The current caching implementation only invalidates the Request URI, and not > variant/alternate URI's. > Example: A REST service provides both xml and json documents. A client app > requests in both content-types (perhaps two different components, one expects > xml, the other json). Assume both documents (xml and json) are in the cache. > If the app PUTs a modification to the object in XML (ie, changes a User > object's email address), it should then be able to retrieve the correct > object data via a GET in json. In order to do so, the json object in the > cache would need to be invalidated, so that the cache server forwards the > request on to the REST service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2581) Add / modify APIs to allow easy freelist allocation of iobuffer's from C/C++ plugins
[ https://issues.apache.org/jira/browse/TS-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208711#comment-14208711 ] Leif Hedstrom commented on TS-2581: --- After other discussions, and recent changes in other areas, it seems very reasonable that exposing a simple API around iobuf's would be useful. > Add / modify APIs to allow easy freelist allocation of iobuffer's from C/C++ > plugins > > > Key: TS-2581 > URL: https://issues.apache.org/jira/browse/TS-2581 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Reporter: Leif Hedstrom >Assignee: Phil Sorber > Labels: api-addition > Fix For: 5.3.0 > > > This would allow for efficient allocations in plugins, such that they can do > an in-place new() on a chunk of memory (iobuffer). > The API / features should make it easy and possible to asks for an iobuffer > of at least size . It can return a bigger one, at which point, you'd waste > some. But this allows us to reuse / repurpose the existing iobuffer > allocation. > Phil points out that there are existing iobuffer allocation APIs, so maybe > something in conjunction with that is appropriate. I would like for this to > be easy on the plugin user though, such that it's as simple as "malloc/free" > chains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2573) Exponentional increasing of cluster timeouts
[ https://issues.apache.org/jira/browse/TS-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208710#comment-14208710 ] Leif Hedstrom commented on TS-2573: --- Peter, ping on this? Still an issue? We unfortunately have no active developers that are using clustering. So if you still are, you might be the main clustering guy going forward :). > Exponentional increasing of cluster timeouts > > > Key: TS-2573 > URL: https://issues.apache.org/jira/browse/TS-2573 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Peter Walsh > Fix For: sometime > > > Occasionally we see cluster operations will start timing out after 5 seconds. > This will continue at an increasing rate until traffic server is restarted. > The following stats increase when this happens, > proxy.process.cluster.remote_op_timeouts and > proxy.process.cluster.connections_open. > I can tell that spikes in IO wait can contribute to this issue. > Any ideas? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2583) invalid argument for option '-m when compiling with Intel compilers
[ https://issues.apache.org/jira/browse/TS-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2583: -- Fix Version/s: (was: 5.2.0) sometime > invalid argument for option '-m when compiling with Intel compilers > > > Key: TS-2583 > URL: https://issues.apache.org/jira/browse/TS-2583 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom > Fix For: sometime > > > This is because of the -mcx16 that gets added. That really should be done (I > think?) only when the compiler supports it (e.g. gcc). The 128-bit CAS seems > to work in ICC without this option (obviously it doesn't support / use the > option). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2565) ALPN: configure protocol selection
[ https://issues.apache.org/jira/browse/TS-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208706#comment-14208706 ] Brian Geffon commented on TS-2565: -- This should be covered by TS-2740 ? > ALPN: configure protocol selection > -- > > Key: TS-2565 > URL: https://issues.apache.org/jira/browse/TS-2565 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, SSL >Reporter: James Peach >Assignee: Sudheer Vinukonda > Fix For: sometime > > > Once there is a meaningful set of protocols that uses ALPN, we should have a > way for operators to configure the ALP protocol selection. For example, some > sites might want to prefer HTTP1 to HTTP2, some sites might want the reverse. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2572) Response header corruption when transforming cached objects
[ https://issues.apache.org/jira/browse/TS-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208705#comment-14208705 ] Leif Hedstrom commented on TS-2572: --- Peter, it feels we've dropped the ball on some of your issues :-/. Sorry about that, lets get your issues into the queues again. Is this still something that needs to be investigated? > Response header corruption when transforming cached objects > --- > > Key: TS-2572 > URL: https://issues.apache.org/jira/browse/TS-2572 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Peter Walsh > Fix For: sometime > > > I have a transform that caches the untransformed response, so that way I > perform the transformation for each subsequent cache hit of that document. > Whenever the response is peer fetched from another node in the cluster, the > response headers are partially overwritten by the response data. This does > not happen when the response is NOT cached, and it does NOT happen when NOT > using cluster feature. > In my transform plugin I use TSIOBufferCreate to a create the buffer which > gets written into by TSIOBufferWrite with the desired response body. > When a response is peer fetched from cache, the address of the transformed > response header's values (I'm printing address using > TSHttpTxnTransformRespGet and other API's) starts halfway into the buffer > allocated by TSIOBufferCreate. So if I write about 2k into it, I > overwrite my response transform headers. > When the response is not from cache, or when the response is from cache > and we're not in a cluster, this does NOT happen, ever. Could be > coincidence, but its repeatable for response sizes varying from 5k to 10 > MB. > I don't know how the Transform response headers values can share the same > memory as what I get from calling TSIOBufferCreate, but it does. My > concern is that at a deeper level the memory is being mismanaged, and > while I can check in my transform plugin if I'll overwrite my transform > resp header buffer, but what about other parts of ATS that are utilizing > buffers, or when I have multiple transforms happening at the same time? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2557) adopt resumable SSL session API
[
https://issues.apache.org/jira/browse/TS-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208702#comment-14208702
]
Brian Geffon commented on TS-2557:
--
[~jpe...@apache.org] were you thinking about exposing this logic to plugins?
How were you thinking this could be beneficial?
> adopt resumable SSL session API
> ---
>
> Key: TS-2557
> URL: https://issues.apache.org/jira/browse/TS-2557
> Project: Traffic Server
> Issue Type: New Feature
> Components: Security, SSL
>Reporter: James Peach
>Assignee: Brian Geffon
> Fix For: sometime
>
>
> In OpenSSL 1.1.0 adds a new callback API for applications to control whether
> the TLS session should be cached or not.
> {quote}
>void SSL_CTX_set_not_resumable_session_callback(SSL_CTX *ctx, int
> (*cb)(SSL *ssl, int is_forward_secure))
>void SSL_set_not_resumable_session_callback(SSL *ssl, int (*cb)(SSL
> *ssl, int is_forward_secure))
> for use by SSL/TLS servers; the callback function will be called
> whenever a
> new session is created, and gets to decide whether the session may be
> cached to make it resumable (return 0) or not (return 1). (As by the
> SSL/TLS protocol specifications, the session_id sent by the server will
> be
> empty to indicate that the session is not resumable; also, the server
> will
> not generate RFC 4507 (RFC 5077) session tickets.)
> A simple reasonable callback implementation is to return
> is_forward_secure.
> This parameter will be set to 1 or 0 depending on the ciphersuite
> selected
> by the SSL/TLS server library, indicating whether it can provide forward
> security.
> {quote}
> This seems like a useful sort of option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2557) adopt resumable SSL session API
[
https://issues.apache.org/jira/browse/TS-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2557:
Description:
In OpenSSL 1.1.0 adds a new callback API for applications to control whether
the TLS session should be cached or not.
{quote}
void SSL_CTX_set_not_resumable_session_callback(SSL_CTX *ctx, int
(*cb)(SSL *ssl, int is_forward_secure))
void SSL_set_not_resumable_session_callback(SSL *ssl, int (*cb)(SSL
*ssl, int is_forward_secure))
for use by SSL/TLS servers; the callback function will be called whenever a
new session is created, and gets to decide whether the session may be
cached to make it resumable (return 0) or not (return 1). (As by the
SSL/TLS protocol specifications, the session_id sent by the server will be
empty to indicate that the session is not resumable; also, the server will
not generate RFC 4507 (RFC 5077) session tickets.)
A simple reasonable callback implementation is to return is_forward_secure.
This parameter will be set to 1 or 0 depending on the ciphersuite selected
by the SSL/TLS server library, indicating whether it can provide forward
security.
{quote}
This seems like a useful sort of option.
was:
In OpenSSL 1.1.0 adds a new callback API for applications to control whether
the TSL session should be cached or not.
{quote}
void SSL_CTX_set_not_resumable_session_callback(SSL_CTX *ctx, int
(*cb)(SSL *ssl, int is_forward_secure))
void SSL_set_not_resumable_session_callback(SSL *ssl, int (*cb)(SSL
*ssl, int is_forward_secure))
for use by SSL/TLS servers; the callback function will be called whenever a
new session is created, and gets to decide whether the session may be
cached to make it resumable (return 0) or not (return 1). (As by the
SSL/TLS protocol specifications, the session_id sent by the server will be
empty to indicate that the session is not resumable; also, the server will
not generate RFC 4507 (RFC 5077) session tickets.)
A simple reasonable callback implementation is to return is_forward_secure.
This parameter will be set to 1 or 0 depending on the ciphersuite selected
by the SSL/TLS server library, indicating whether it can provide forward
security.
{quote}
This seems like a useful sort of option.
> adopt resumable SSL session API
> ---
>
> Key: TS-2557
> URL: https://issues.apache.org/jira/browse/TS-2557
> Project: Traffic Server
> Issue Type: New Feature
> Components: Security, SSL
>Reporter: James Peach
> Fix For: sometime
>
>
> In OpenSSL 1.1.0 adds a new callback API for applications to control whether
> the TLS session should be cached or not.
> {quote}
>void SSL_CTX_set_not_resumable_session_callback(SSL_CTX *ctx, int
> (*cb)(SSL *ssl, int is_forward_secure))
>void SSL_set_not_resumable_session_callback(SSL *ssl, int (*cb)(SSL
> *ssl, int is_forward_secure))
> for use by SSL/TLS servers; the callback function will be called
> whenever a
> new session is created, and gets to decide whether the session may be
> cached to make it resumable (return 0) or not (return 1). (As by the
> SSL/TLS protocol specifications, the session_id sent by the server will
> be
> empty to indicate that the session is not resumable; also, the server
> will
> not generate RFC 4507 (RFC 5077) session tickets.)
> A simple reasonable callback implementation is to return
> is_forward_secure.
> This parameter will be set to 1 or 0 depending on the ciphersuite
> selected
> by the SSL/TLS server library, indicating whether it can provide forward
> security.
> {quote}
> This seems like a useful sort of option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2565) ALPN: configure protocol selection
[ https://issues.apache.org/jira/browse/TS-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2565: -- Assignee: Sudheer Vinukonda > ALPN: configure protocol selection > -- > > Key: TS-2565 > URL: https://issues.apache.org/jira/browse/TS-2565 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, SSL >Reporter: James Peach >Assignee: Sudheer Vinukonda > Fix For: sometime > > > Once there is a meaningful set of protocols that uses ALPN, we should have a > way for operators to configure the ALP protocol selection. For example, some > sites might want to prefer HTTP1 to HTTP2, some sites might want the reverse. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2557) adopt resumable SSL session API
[
https://issues.apache.org/jira/browse/TS-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2557:
--
Assignee: Brian Geffon
> adopt resumable SSL session API
> ---
>
> Key: TS-2557
> URL: https://issues.apache.org/jira/browse/TS-2557
> Project: Traffic Server
> Issue Type: New Feature
> Components: Security, SSL
>Reporter: James Peach
>Assignee: Brian Geffon
> Fix For: sometime
>
>
> In OpenSSL 1.1.0 adds a new callback API for applications to control whether
> the TLS session should be cached or not.
> {quote}
>void SSL_CTX_set_not_resumable_session_callback(SSL_CTX *ctx, int
> (*cb)(SSL *ssl, int is_forward_secure))
>void SSL_set_not_resumable_session_callback(SSL *ssl, int (*cb)(SSL
> *ssl, int is_forward_secure))
> for use by SSL/TLS servers; the callback function will be called
> whenever a
> new session is created, and gets to decide whether the session may be
> cached to make it resumable (return 0) or not (return 1). (As by the
> SSL/TLS protocol specifications, the session_id sent by the server will
> be
> empty to indicate that the session is not resumable; also, the server
> will
> not generate RFC 4507 (RFC 5077) session tickets.)
> A simple reasonable callback implementation is to return
> is_forward_secure.
> This parameter will be set to 1 or 0 depending on the ciphersuite
> selected
> by the SSL/TLS server library, indicating whether it can provide forward
> security.
> {quote}
> This seems like a useful sort of option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2540) header_rewrite: Does not detect a Statement without a predicate as an error
[
https://issues.apache.org/jira/browse/TS-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2540:
--
Assignee: Sudheer Vinukonda
> header_rewrite: Does not detect a Statement without a predicate as an error
> ---
>
> Key: TS-2540
> URL: https://issues.apache.org/jira/browse/TS-2540
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Sudheer Vinukonda
> Fix For: 5.3.0
>
>
> For example, this config silently fails with no errors, and worse, leaves the
> parser in a potentially erroneous state (causing subsequent rules to be
> wrong):
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> X-Some-Header "zwoop"
> {code}
> Yes, it's obviously a config error (it should have a "set-config" predicate),
> but we should detect this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2540) header_rewrite: Does not detect a Statement without a predicate as an error
[
https://issues.apache.org/jira/browse/TS-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2540:
--
Summary: header_rewrite: Does not detect a Statement without a predicate as
an error (was: header_rewrite: Does not detect a Statement without a
predicated as an error)
> header_rewrite: Does not detect a Statement without a predicate as an error
> ---
>
> Key: TS-2540
> URL: https://issues.apache.org/jira/browse/TS-2540
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 5.3.0
>
>
> For example, this config silently fails with no errors, and worse, leaves the
> parser in a potentially erroneous state (causing subsequent rules to be
> wrong):
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> X-Some-Header "zwoop"
> {code}
> Yes, it's obviously a config error (it should have a "set-config" predicate),
> but we should detect this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2540) header_rewrite: Does not detect a Statement without a predicated as an error
[
https://issues.apache.org/jira/browse/TS-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2540:
--
Fix Version/s: (was: 5.2.0)
5.3.0
> header_rewrite: Does not detect a Statement without a predicated as an error
>
>
> Key: TS-2540
> URL: https://issues.apache.org/jira/browse/TS-2540
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: 5.3.0
>
>
> For example, this config silently fails with no errors, and worse, leaves the
> parser in a potentially erroneous state (causing subsequent rules to be
> wrong):
> {code}
> cond %{READ_REQUEST_HDR_HOOK}
> X-Some-Header "zwoop"
> {code}
> Yes, it's obviously a config error (it should have a "set-config" predicate),
> but we should detect this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2536) Performance improvements to VariableExpander in header_rewrite
[ https://issues.apache.org/jira/browse/TS-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208682#comment-14208682 ] Leif Hedstrom commented on TS-2536: --- This probably depends on the Body Factory improvements. > Performance improvements to VariableExpander in header_rewrite > -- > > Key: TS-2536 > URL: https://issues.apache.org/jira/browse/TS-2536 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Leif Hedstrom > Fix For: sometime > > > It seems that VariableExpander gets instantiated and executed on every > add-header operator. However, this seems rather suboptimal for a number of > reasons: > 1. It might not even be necessary (i.e. there might not be any %<> strings in > the "static" string. > 2. Perhaps even more important, we look for these strings on every request, > even though if they are there, they would always be in the same position on > every request. > One suggestion would be to incorporate the VariableExpander "state" as part > of parsing the configuration on startup / reload. Maybe it gets complicated > when there are other expansions, but it still feels we can pre-parse these > strings and get some ideas of what needs to be expanded once, and not on > every request. > This is similar to how e.g. the regex_remap plugin works, it recalculates the > positions and expansion once only. > Thoughts? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2523) automatically max out the listen backlog
[
https://issues.apache.org/jira/browse/TS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2523:
--
Fix Version/s: (was: sometime)
6.0.0
> automatically max out the listen backlog
>
>
> Key: TS-2523
> URL: https://issues.apache.org/jira/browse/TS-2523
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Network
>Reporter: James Peach
>Assignee: James Peach
> Labels: compatibility
> Fix For: 6.0.0
>
>
> Rather than choosing the right value for {{proxy.config.net.listen_backlog}},
> we should support a -1 default. This would max out the listen backlog on
> systems where we know how to find that, and set it to {{SOMAXCON}} everywhere
> else.
> On Linux, the max backlog is 65535 (unsigned short), and the kernel will clip
> that to {{/proc/sys/net/core/somaxconn}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2520) Configuration variable to enable TFO
[ https://issues.apache.org/jira/browse/TS-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208680#comment-14208680 ] Leif Hedstrom commented on TS-2520: --- Was there not a patch for this? Is there something on Github? > Configuration variable to enable TFO > > > Key: TS-2520 > URL: https://issues.apache.org/jira/browse/TS-2520 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration >Reporter: Alex Sandro Garzão >Priority: Trivial > Fix For: sometime > > > TFO (TCP Fast Open) can be enabled on all listen sockets in the kernel. > Nevertheless, I would like that only ATS try using TFO. > One possibility is a configuration variable that informs ATS to set > TCP_FASTOPEN. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2523) automatically max out the listen backlog
[
https://issues.apache.org/jira/browse/TS-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2523:
--
Labels: compatibility (was: )
> automatically max out the listen backlog
>
>
> Key: TS-2523
> URL: https://issues.apache.org/jira/browse/TS-2523
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Network
>Reporter: James Peach
>Assignee: James Peach
> Labels: compatibility
> Fix For: 6.0.0
>
>
> Rather than choosing the right value for {{proxy.config.net.listen_backlog}},
> we should support a -1 default. This would max out the listen backlog on
> systems where we know how to find that, and set it to {{SOMAXCON}} everywhere
> else.
> On Linux, the max backlog is 65535 (unsigned short), and the kernel will clip
> that to {{/proc/sys/net/core/somaxconn}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2515) Create stat for when ATS wrapped around on disk cache cleanup
[ https://issues.apache.org/jira/browse/TS-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2515: -- Fix Version/s: (was: 5.2.0) 5.3.0 > Create stat for when ATS wrapped around on disk cache cleanup > - > > Key: TS-2515 > URL: https://issues.apache.org/jira/browse/TS-2515 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Metrics >Reporter: Bryan Call >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > Create a stat for the last time ATS wrapped around on cleaning up the disk > cache. > This can be implemented with two stats the last time it wrapped and the time > difference between the last two wraps. This would give an idea of how often > the cache does wrap around. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208677#comment-14208677
]
Leif Hedstrom commented on TS-2512:
---
[~psudaemon] Should we do something with this?
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2512) Optimize performance in channel_stats plugin
[
https://issues.apache.org/jira/browse/TS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2512:
--
Fix Version/s: (was: 5.2.0)
sometime
> Optimize performance in channel_stats plugin
>
>
> Key: TS-2512
> URL: https://issues.apache.org/jira/browse/TS-2512
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Leif Hedstrom
> Fix For: sometime
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things
> (such as metrics names / indexes) such that we don't have to look it up on
> every request. Instead, it can just use the pre-calculated information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2510) Create a hook for Plugins to attach themselves into the Lua Configuration system
[ https://issues.apache.org/jira/browse/TS-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2510: -- Fix Version/s: (was: 5.2.0) 6.0.0 > Create a hook for Plugins to attach themselves into the Lua Configuration > system > > > Key: TS-2510 > URL: https://issues.apache.org/jira/browse/TS-2510 > Project: Traffic Server > Issue Type: Sub-task > Components: Configuration >Reporter: Igor Galić > Fix For: 6.0.0 > > > We need a way for plugins to get into the Lua Config. > Plugins shouldn't have to create new configurations and parse them each on > their own. We should create a namespace like `ats:plugin:` in the LuaConfig > and a special function (the plugin name) for its configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3191) Confusion with HTTP_TUNNEL_STATIC_PRODUCER
[ https://issues.apache.org/jira/browse/TS-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208616#comment-14208616 ] ASF GitHub Bot commented on TS-3191: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/145 TS-3191: Add logic to better handle collisions with static producers. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver ts-3191 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/145.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #145 commit c35aa7c0bc5dfcdcdab313a9d4a2326a5c6a1b05 Author: shinrich Date: 2014-11-12T19:06:58Z TS-3191 Add logic to better handle collisions with static producers. > Confusion with HTTP_TUNNEL_STATIC_PRODUCER > -- > > Key: TS-3191 > URL: https://issues.apache.org/jira/browse/TS-3191 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > > In the HttpTunnel processing, normally a producer has a VC associated with > it. The VC is used to lookup the producer via the HttpTunnel::get_producer > method out of the HttpTunnel producer array. > All is well and good, but in the case of a static producer, there is no vc. > Rather the constant HTTP_TUNNEL_STATIC_PRODUCER is used in lieu of the vc. > If there is only only one static producer all is still well, get_producer > will return the one producer associated with HTTP_TUNNEL_STATIC_PRODUCER. > But if there is more than one static producer involved with the tunnel, > get_producer() will only return one producer. Both static consumers will > only interact with one of the static producers and things will go down hill > from here. > I ran into this case while chasing down crashes via TS-3105, so this > situation does come up in the wild. > I fixed it by clearing out the tunnel before starting a static producer and > making some other checks along the way. > We could also avoid some calls to get_producer since it many cases, the > caller already has the producer in question, but the callee ends up looking > up that value again via the VC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2907) Unix Sockets
[
https://issues.apache.org/jira/browse/TS-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208514#comment-14208514
]
Brian Geffon commented on TS-2907:
--
Agree that {{--enable-unix-socket}} is unnecessary.
In general I do not like the idea of ‘unix:///foo/bar.sock/path, I think the
following syntax makes more sense, how else can we manipulate the host header
for the next hop without a plugin?
{{map http://www.foo.bar/ http://www.blah.com/ @unix_socket=/tmp/foo.bar.sock}}
Also, with this approach you can remove all the
{{url_parse_unix_no_path_component_breakdown()}} code.
> Unix Sockets
>
>
> Key: TS-2907
> URL: https://issues.apache.org/jira/browse/TS-2907
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core
>Reporter: Luca Rea
>Assignee: James Peach
> Labels: review
> Fix For: 5.2.0
>
> Attachments: TS-2907.diff, unixsocket-backpost.diff
>
>
> Feature request for support listeners and parents on unix sockets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3190) Change producer_run() to run a specific producer in more cases
[ https://issues.apache.org/jira/browse/TS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208510#comment-14208510 ] ASF GitHub Bot commented on TS-3190: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/144 TS-3190: Limit the number of producers invoked via producer_run You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver ts-3190 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/144.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #144 commit d9cd23acb7b9b143ec8a2cdda450d17dfaf48c40 Author: shinrich Date: 2014-11-12T18:44:43Z TS-3190 Use the version of producer_run that runs a specific producer instead of all producers. commit 0a6fc4f21eddc6823020ef3ae4c7a1e95e87a5a1 Author: shinrich Date: 2014-11-12T18:46:04Z Add a clear half close flag. > Change producer_run() to run a specific producer in more cases > -- > > Key: TS-3190 > URL: https://issues.apache.org/jira/browse/TS-3190 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > > Found while tracking down TS-3105. It seemed like sometimes producers were > having producer_run called on them multiple times. producer_run can be run on > a particular producers or on all producers added at that point in time. > There are a couple places where multiple producers are set up and so > producer_run(NULL) makes sense. But in many cases a producer is carefully > added and then producer_run(NULL) is called on all producers that are around > that that point in time. > It seems safer to call producer_run() on the newly added producer in those > cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3189) Do not start reading data on server to user agent tunnel too soon
[ https://issues.apache.org/jira/browse/TS-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208504#comment-14208504 ] ASF GitHub Bot commented on TS-3189: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/143 TS-3189: Delay initial do_io_read Delay the do_io_read on the server to user agent tunnel to avoid cases of the incorrect tunnel handling EOS in the post case. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver ts-3189 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/143.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #143 commit 2646c3d631b4d98c386582442bdecd47666a341a Author: shinrich Date: 2014-11-11T17:24:13Z TS-3189 Delay the do_io_read on the server to user agent tunnel to avoid cases of the incorrect tunnel handling EOS in the post case. > Do not start reading data on server to user agent tunnel too soon > - > > Key: TS-3189 > URL: https://issues.apache.org/jira/browse/TS-3189 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > > The original logic would set up a do_io_read for max_int in > HttpSM::attach_server_session. > However, at this point there still may be things finishing up in the > user_agent to server tunnel (for posts). We were seeing occasional cases of > the EOS for the tunnel to user_agent communication being incorrectly > delivered to the consumer of the user_agent to server tunnel. > It is sufficient to set up a 0 length read in HttpSM::attach_server_session. > This will enable the correct handlers to deal with inactivity timeouts. Then > we can setup the real read in HttpSM::setup_server_read_response_header() > after we know that the user_agent to origin server tunnel has been taken > down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-2907) Unix Sockets
[
https://issues.apache.org/jira/browse/TS-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208426#comment-14208426
]
James Peach edited comment on TS-2907 at 11/12/14 7:07 PM:
---
This looks pretty reasonable to me. I had a few comments ...
Remove --enable-unix-socket option. we already assume unix domain socket, let's
just use them.
TS_UNIX_SIZE is not necessary; it's clearer to use sockaddr.sun_path directly.
Do you need to increment the HostDB version number to force traffic_server do
recreate it?
{{bool ats_is_supported_sa(int family)}} should be called
{{ats_is_supported_family()}}.
The comments for {{ats_unix_path_cast()}} seems wrong. AFAICT
{{ats_unix_path_cast()}} doesn't return NULL if applied to the wrong socket
type.
I need [~amc] to review the hdrtoken+wks changes for cache compatibility.
In {{HttpTransact::initialize_state_variables_from_request}}, I don't see how
the scheme from {{incoming_request->url_get()}} can be Unix. The Unix scheme is
only for origin requests, so this seems confusing.
In {{remap_parse_config_bti}}, we should raise an error if the {{fromScheme}}
is Unix.
We should mention this feature in the {{remap.config}} documentation.
was (Author: jamespeach):
This looks pretty reasonable to me. I had a few comments ...
Remove --enable-unix-socket option. we already assume unix domain socket, let's
just use them.
TS_UNIX_SIZE is not necessary; it's clearer to use sockaddr.sun_path directly.
Do you need to increment the HostDB version number so force traffic_server do
recreate it?
{{bool ats_is_supported_sa(int family)}} should be called
{{ats_is_supported_family()}}.
The comments for {{ats_unix_path_cast()}} seems wrong. AFAICT
{{ats_unix_path_cast()}} doesn't return NULL if applied to the wrong socket
type.
I need [~amc] to review the hdrtoken+wks changes for cache compatibility.
In {{HttpTransact::initialize_state_variables_from_request}}, I don't see how
the scheme from {{incoming_request->url_get()}} can be Unix. The Unix scheme is
only for origin requests, so this seems confusing.
In {{remap_parse_config_bti}}, we should raise an error if the {{fromScheme}}
is Unix.
We should mention this feature in the {{remap.config}} documentation.
> Unix Sockets
>
>
> Key: TS-2907
> URL: https://issues.apache.org/jira/browse/TS-2907
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core
>Reporter: Luca Rea
>Assignee: James Peach
> Labels: review
> Fix For: 5.2.0
>
> Attachments: TS-2907.diff, unixsocket-backpost.diff
>
>
> Feature request for support listeners and parents on unix sockets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[
https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208469#comment-14208469
]
James Peach commented on TS-3156:
-
I verified that the {{ci/tsqa/test-ssl-certificates}} test was crashing before
this last fix, and passes after it.
> Mutex[Try]Lock bool() operator change and unused API removal
>
>
> Key: TS-3156
> URL: https://issues.apache.org/jira/browse/TS-3156
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Powell Molleti
>Assignee: James Peach
>Priority: Minor
> Labels: review
> Fix For: 5.2.0
>
> Attachments: MutexLock-ats.patch, MutexLock-ats.patch,
> Use-Ryo-s-patch-to-pass-shared_ptr-to-MutexLock.patch, fix-MutexLock.patch
>
>
> Removed unused constructor in MutexLock along with set_and_take() method, had
> to change FORCE_PLUGIN_MUTEX() for that. Removed release() method.
> default bool and ! operator from both MutexLock and MutexTryLock with
> is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code
> base.
> Ran make test will be performing more system testing. Posted before for early
> comments / feedback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[ https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208467#comment-14208467 ] ASF subversion and git services commented on TS-3156: - Commit 1fc0fd0fe9bca2802543ae0a55bb80e8817a6e31 in trafficserver's branch refs/heads/master from [~geek101] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1fc0fd0 ] TS-3156: fix mutex crashes MUTEX_LOCK and MUTEX_TRY_LOCK expect to be passed a Ptr. Change direct uses of ProxyMutex to Ptr so the underlying mutex is not destroyed early. > Mutex[Try]Lock bool() operator change and unused API removal > > > Key: TS-3156 > URL: https://issues.apache.org/jira/browse/TS-3156 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Powell Molleti >Assignee: James Peach >Priority: Minor > Labels: review > Fix For: 5.2.0 > > Attachments: MutexLock-ats.patch, MutexLock-ats.patch, > Use-Ryo-s-patch-to-pass-shared_ptr-to-MutexLock.patch, fix-MutexLock.patch > > > Removed unused constructor in MutexLock along with set_and_take() method, had > to change FORCE_PLUGIN_MUTEX() for that. Removed release() method. > default bool and ! operator from both MutexLock and MutexTryLock with > is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code > base. > Ran make test will be performing more system testing. Posted before for early > comments / feedback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3105: --- Attachment: (was: ts-3073-and-3084-and-3105-against-510.patch) > Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on > 5.1 and beyond > > > Key: TS-3105 > URL: https://issues.apache.org/jira/browse/TS-3105 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: ts-3073-and-3084-and-3105-and-3155-against-510-15.patch, > ts-3105-master-7.patch, ts-3105-master-9.patch > > > These two patches were run in a production environment on top of 5.0.1 > without problem for several weeks. Now running with these patches on top of > 5.1 causes either an assert or a segfault. Another person has reported the > same segfault when running master in a production environment. > In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than > a terminal state which is expected. I'm assuming either we are being > directed into the terminal state from a connection that terminates too > quickly. Or an event has hung around for too long and is being executed > against the state machine after it has been recycled. > The event is HTTP_TUNNEL_EVENT_DONE > The assert stack trace is > FATAL: HttpSM.cc:2632: failed assert `0` > /z/bin/traffic_server - STACK TRACE: > /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] > /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] > /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] > /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] > /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] > /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, > EThread*)+0x136e)[0x721d1e] > /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] > /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] > The segfault stack trace is > /z/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] > /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, > HttpTunnelConsumer*)+0x122)[0x591462] > /z/bin/traffic_server(HttpTunnel::consumer_handler(int, > HttpTunnelConsumer*)+0x9e)[0x5dd15e] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] > /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, > Event*)+0x3f0)[0x725190] > /z/bin/traffic_server(InactivityCop::check_inactivity(int, > Event*)+0x275)[0x716b75] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034] > /lib64/libc.so.6(clone+0x6d)[0x2abccde1475d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3105) Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on 5.1 and beyond
[ https://issues.apache.org/jira/browse/TS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Susan Hinrichs updated TS-3105: --- Attachment: ts-3073-and-3084-and-3105-and-3155-against-510-15.patch > Combination of fixes for TS-3084 and TS-3073 causing asserts and segfaults on > 5.1 and beyond > > > Key: TS-3105 > URL: https://issues.apache.org/jira/browse/TS-3105 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.2.0 > > Attachments: ts-3073-and-3084-and-3105-against-510.patch, > ts-3073-and-3084-and-3105-and-3155-against-510-15.patch, > ts-3105-master-7.patch, ts-3105-master-9.patch > > > These two patches were run in a production environment on top of 5.0.1 > without problem for several weeks. Now running with these patches on top of > 5.1 causes either an assert or a segfault. Another person has reported the > same segfault when running master in a production environment. > In the assert, the handler_state of the producers is 0 (UNKNOWN) rather than > a terminal state which is expected. I'm assuming either we are being > directed into the terminal state from a connection that terminates too > quickly. Or an event has hung around for too long and is being executed > against the state machine after it has been recycled. > The event is HTTP_TUNNEL_EVENT_DONE > The assert stack trace is > FATAL: HttpSM.cc:2632: failed assert `0` > /z/bin/traffic_server - STACK TRACE: > /z/lib/libtsutil.so.5(+0x25197)[0x2b8bd08dc197] > /z/lib/libtsutil.so.5(+0x23def)[0x2b8bd08dadef] > /z/bin/traffic_server(HttpSM::tunnel_handler_post_or_put(HttpTunnelProducer*)+0xcd)[0x5982ad] > /z/bin/traffic_server(HttpSM::tunnel_handler_post(int, void*)+0x86)[0x5a32d6] > /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5a1e18] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xee)[0x5dd6ae] > /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, > EThread*)+0x136e)[0x721d1e] > /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x28c)[0x7162fc] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x4fc)[0x7458ac] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2b8bd1ee4034] > /lib64/libc.so.6(clone+0x6d)[0x2b8bd2c2875d] > The segfault stack trace is > /z/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf280)[0x2abccd0d8280] > /z/bin/traffic_server(HttpSM::tunnel_handler_ua(int, > HttpTunnelConsumer*)+0x122)[0x591462] > /z/bin/traffic_server(HttpTunnel::consumer_handler(int, > HttpTunnelConsumer*)+0x9e)[0x5dd15e] > /z/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x117)[0x5dd6d7] > /z/bin/traffic_server(UnixNetVConnection::mainEvent(int, > Event*)+0x3f0)[0x725190] > /z/bin/traffic_server(InactivityCop::check_inactivity(int, > Event*)+0x275)[0x716b75] > /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x744df1] > /z/bin/traffic_server(EThread::execute()+0x2fb)[0x7456ab] > /z/bin/traffic_server[0x7440ca] > /lib64/libpthread.so.0(+0x7034)[0x2abccd0d0034] > /lib64/libc.so.6(clone+0x6d)[0x2abccde1475d] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2907) Unix Sockets
[
https://issues.apache.org/jira/browse/TS-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208426#comment-14208426
]
James Peach commented on TS-2907:
-
This looks pretty reasonable to me. I had a few comments ...
Remove --enable-unix-socket option. we already assume unix domain socket, let's
just use them.
TS_UNIX_SIZE is not necessary; it's clearer to use sockaddr.sun_path directly.
Do you need to increment the HostDB version number so force traffic_server do
recreate it?
{{bool ats_is_supported_sa(int family)}} should be called
{{ats_is_supported_family()}}.
The comments for {{ats_unix_path_cast()}} seems wrong. AFAICT
{{ats_unix_path_cast()}} doesn't return NULL if applied to the wrong socket
type.
I need [~amc] to review the hdrtoken+wks changes for cache compatibility.
In {{HttpTransact::initialize_state_variables_from_request}}, I don't see how
the scheme from {{incoming_request->url_get()}} can be Unix. The Unix scheme is
only for origin requests, so this seems confusing.
In {{remap_parse_config_bti}}, we should raise an error if the {{fromScheme}}
is Unix.
We should mention this feature in the {{remap.config}} documentation.
> Unix Sockets
>
>
> Key: TS-2907
> URL: https://issues.apache.org/jira/browse/TS-2907
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core
>Reporter: Luca Rea
>Assignee: James Peach
> Labels: review
> Fix For: 5.2.0
>
> Attachments: TS-2907.diff, unixsocket-backpost.diff
>
>
> Feature request for support listeners and parents on unix sockets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3156) Mutex[Try]Lock bool() operator change and unused API removal
[ https://issues.apache.org/jira/browse/TS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208385#comment-14208385 ] Powell Molleti commented on TS-3156: who is going to commit this new patch?. Powell. > Mutex[Try]Lock bool() operator change and unused API removal > > > Key: TS-3156 > URL: https://issues.apache.org/jira/browse/TS-3156 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Powell Molleti >Assignee: James Peach >Priority: Minor > Labels: review > Fix For: 5.2.0 > > Attachments: MutexLock-ats.patch, MutexLock-ats.patch, > Use-Ryo-s-patch-to-pass-shared_ptr-to-MutexLock.patch, fix-MutexLock.patch > > > Removed unused constructor in MutexLock along with set_and_take() method, had > to change FORCE_PLUGIN_MUTEX() for that. Removed release() method. > default bool and ! operator from both MutexLock and MutexTryLock with > is_locked() API. Changes if (lock) to if (lock.is_locked()) across the code > base. > Ran make test will be performing more system testing. Posted before for early > comments / feedback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3192) implement proxy.config.config_dir
[
https://issues.apache.org/jira/browse/TS-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208322#comment-14208322
]
James Peach commented on TS-3192:
-
This is needed for the test suite, where you have a single build that you want
to run multiple instances of with different configurations. In practice, this
is also a useful deployment capability. In past lives, I've deployed httpd
using isolated configuration files and it is very helpful.
> 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)
