Re: [PROPOSAL] Remove "stats" pages

Not DNS connections, but regular connections per downstream service. https://github.com/apache/trafficserver/pull/1609 The HostDB stat also can be dumped into JSON. It could be convenient if you would like to know the exact HostDB cache result for a specific service name. Leif Hedstrom 于2019年6月6日

Re: [PROPOSAL] Remove SSL v3 code and configs

+1 On Thu, Jun 6, 2019 at 5:51 PM Steven R. Feltner wrote: > +1 > > On 6/6/19, 8:32 PM, "Leif Hedstrom" wrote: > > This code is disabled and does not build by default. I think it’s time > to remove this code path completely, it’s an insecure protocol, and I don’t > think any of us enables

Re: proxy.config.http.request_buffer_enabled

Thanks for the info. I'll add the missing entry. Susan Hinrichs 于2019年1月10日周四 上午9:32写道： > Looks like the request_buffer_enabled was added by zizhong. > 78cb6c9bf86e8d72c79a9084604bc25520ef57d7 > > If there is no RecordsConfig.cc entry does that mean it is override only? > > On Thu, Jan 10, 2019

Re: Headers.h in the CPPAPI

read, delete, etc. If you can share some pseudo code having the issue, we can analyze it to see if it's a design issue or being used in a wrong way. Walt Karas 于2018年9月13日周四 上午8:21写道： > Do you use it to change the contents of headers or just to read them? > > I've been told that if (for example)

Re: [New API Proposal] TSContScheduleToCurrentThread and TSContScheduleToCurrentThreadEvery

Thanks, Kees, Otto, and Alan. TSScheduleOnThread() seems perfect and much more powerful. Any use cases you guys can figure for scheduling a cont on a specific different thread? For scheduling on the current thread case, we don't even need a mutex. If we'd schedule the cont with mutex on the mutex->

Re: [INFO] Don't merge PRs with missing information

Could we add these requirements to the checklist where we check milestones/labels as we check review approval/autest/build? 2018-06-06 3:16 GMT-07:00 Leif Hedstrom : > Hi all, > > I’m going through all the PRs landed for 8.0.0, and there’s an alarming > number of PRs without fields such as > >

Re: [PROPOSAL] Remove the tools/traffic_shell.pl script

+1 We've never used it too. On Fri, May 4, 2018, 2:06 PM Bryan Call wrote: > +1 - I don’t use it and it looks like it is broken on master > > -Bryan > > > On May 3, 2018, at 8:38 AM, Leif Hedstrom wrote: > > > > I don’t think this script has a purpose any more, and it’s not > maintained. Does a

Re: [New API proposal]TSIOBufferReaderPostGet

)`? Most of > the API that takes a TSHttpTxn is prefixed with 'TSHTTPTxn'. > > On Wed, Mar 7, 2018 at 11:15 AM, Bryan Call wrote: > > > +1 > > > > -Bryan > > > > > > > > > On Mar 5, 2018, at 11:19 AM, CrazyCow > > wr

[New API proposal]TSIOBufferReaderPostGet

Hi, Team, Along with the post buffer PR which buffers post body before opening connections to origin servers, I'd introduce a new API that enables plugins to read the buffered body. TSIOBufferReader TSIOBufferReaderPostGet(TSHttpTxn txnp); Plu

[New API Proposal] TSHttpTxnGetClientRequestBody

Hi, ATS devs, As a part of https://github.com/apache/trafficserver/pull/2335, I'd like to introduce a new API that the plugin can get the entire post body. The current signature of it is "tsapi char * TSHttpTxnGetClientRequestBody(TSHttpTxn txnp, int *len)" In the implementation, it will get a c

Re: [Dependency Proposal] intel::tbb

We use continuations everywhere, which might not be appropriate according to the above quote? xD For this particular use case of the PR, it's pretty simple code and I don't think it will be a performance bottleneck. What we want here is a mature, well documented and widely used concurrent implemen

Re: [Dependency Proposal] intel::tbb

at > ink_hash_table.cc:244 > #7 0x77bafeb6 in ink_hash_table_insert (ht_ptr=ht_ptr@entry=0x614010, > key=key@entry=0x400b3c "foo", value=value@entry=0x400b30) at > ink_hash_table.cc:293 > #8 0x00400951 in main () at test_ink_hash_table.cc:10 >

Re: [Dependency Proposal] intel::tbb

ll in to get a thread safe > unordered map. We already have a dependency on Tcl_HashTable > (InkHashTable), that handles concurrency, and it used throughout the code > base. > > -Bryan > > > > On Sep 28, 2017, at 5:55 PM, CrazyCow wrote: > > Hi, AT

Re: [Dependency Proposal] intel::tbb

Seems the latest version supports FreeBSD and SunOS. https://github.com/01org/tbb/blob/tbb_2018/build/FreeBSD.inc https://github.com/01org/tbb/blob/tbb_2018/build/SunOS.inc 2017-09-29 8:26 GMT-07:00 James Peach : > > > On Sep 29, 2017, at 7:37 AM, Derek Dagit > wrote: > > > > 3) Does it run on p

[Dependency Proposal] intel::tbb

Hi, ATS devs, Currently, we have a requirement of concurrent_unordered_map (details can be found https://github.com/apache/trafficserver/pull/2555). And intel::tbb::concurrent_unordered_map is the most mature one we can try out. I understand this dependency is huge. I'd like to hear opinions from

Re: [apache/trafficserver] HTTP2 drain (#1710)

I don't disagree. The reasons I chose this way are: 1. We are using other stuff in my team instead of traffic_ctl to manage the process and do the upgrade. 2. traffic_ctl --drain can only support HTTP and it can only be used when restarting ATS. That makes it hardly useful in our use case. 2017-05