Re: Proposed new TS API function: TSHttp2GraceShutdown

2024-06-18 Thread Fei Deng
ings for each version, can be easier for the plugins to use. > The version number in the name should be removed at a minimum (i.e. the API > should work for every HTTP version). > > Masakazu > > > On Mon, Jun 17, 2024 at 8:52 PM Fei Deng wrote: > > > Because of this? &

Re: Proposed new TS API function: TSHttp2GraceShutdown

2024-06-18 Thread Fei Deng
I didn't find a specific test that tests for connection close in H2, so I wrote a simple one this morning and confirmed that changing the header with hook TS_HTTP_SEND_RESPONSE_HDR_HOOK works. We'll have a discussion this afternoon to discuss it over. On Mon, Jun 17, 2024 at 10:52 P

Re: Proposed new TS API function: TSHttp2GraceShutdown

2024-06-17 Thread Fei Deng
mentioned in the docs? Regards, Fei Deng Sent from my iPhone On Mon, Jun 17, 2024 at 10:45 PM Masakazu Kitajo wrote: > It's a documented feature. > > https://docs.trafficserver.apache.org/en/9.2.x/admin-guide/plugins/header_rewrite.en.html#close-connections-for-drai

Re: Proposed new TS API function: TSHttp2GraceShutdown

2024-06-17 Thread Fei Deng
Actually it’s not possible by setting the “Connection: close” header. That was the initial intention of PR #11046, but with all the discussions it looks like that functionality was taken out purposefully. Regards, Fei Deng Sent from my iPhone On Mon, Jun 17, 2024 at 8:42 PM Masakazu Kitajo

Proposed new TS API function: TSHttp2GraceShutdown

2024-06-17 Thread Fei Deng
TSReturnCode TSHttp2GraceShutdown(TSHttpTxn txnp) With this new API, plugins can request a grace shutdown by sending GOAWAY frames (https://httpwg.org/specs/rfc7540.html#GOAWAY). This will also replace this PR https://github.com/apache/trafficserver/pull/11046 Fei Deng

[proposal] Remove support for session id based tls session resumption

2024-02-22 Thread Fei Deng
Hi All, I'm proposing to remove the support for session id based tls session resumption. I mentioned this during the last hackathon, since the session id based tls session resumption is obsolete (about 0.01% total reuse rate on our production boxes). Fei Deng

Re: Proposed new TS API function: TSContScheduleOnEntirePool

2023-11-10 Thread Fei Deng
. On Fri, Oct 20, 2023 at 10:59 AM Leif Hedstrom wrote: > We would need something to allow for one shot calls (eg initializing some > thread local data). > > — Leif > > > On Oct 20, 2023, at 09:11, Fei Deng wrote: > > > > We should be able to make it

Re: Proposed new TS API function: TSContScheduleOnEntirePool

2023-10-20 Thread Fei Deng
ct 17, 2023, at 07:26, Fei Deng wrote: > > > > tsapi::c::TSAction > > tsapi::c::TSContScheduleEveryOnEntirePool(TSCont contp, TSHRTime every, > > TSThreadPool tp); > > > > With this we can schedule a continuation on all the threads of a certain > > type,

Proposed new TS API function: TSContScheduleOnEntirePool

2023-10-17 Thread Fei Deng
thread pools Event *EventProcessor::schedule_spawn(); We probably should also implement a TSContScheduleEvery variant along with it. -- Regards, Fei Deng

Re: Changes to 0-RTT Early Data configurations

2023-05-24 Thread Fei Deng
er_policy, verify_server_properties. > > Do you have any concerns with this approach? > > — Masaori > > On Wed, May 24, 2023 at 5:14 AM Fei Deng wrote: > > > Hi All, > > > > It's been requested that the configuration for 0-RTT early data needs to > be > > changeable

Changes to 0-RTT Early Data configurations

2023-05-23 Thread Fei Deng
Hi All, It's been requested that the configuration for 0-RTT early data needs to be changeable per SNI. I've been working on this feature, and the following example shows the changes I made. Please share your thoughts on this. Note: 1. The old config still exists, it is a general setting for

Re: [API] proposal to change the return type of TSSslTicketKeyUpdate

2022-02-22 Thread Fei Deng
f the API? > > > On Tue, Feb 22, 2022 at 3:02 PM Fei Deng wrote: > > > Hey guys, > > > > The api TSSslTicketKeyUpdate currently returns void, but in some recent > > plugin debugging, I find it necessary to check whether the key update was > > actually suc

[API] proposal to change the return type of TSSslTicketKeyUpdate

2022-02-22 Thread Fei Deng
ssful/failed key update. So I'm proposing that we change the return value type of TSSslTicketKeyUpdate from void to bool. Regards, Fei Deng

Re: ATS Memory Usage Steady Increase

2020-12-17 Thread Fei Deng
Not saying this is the exact cause, but we've seen similar behavior previously. The reason for our issue was the session cache size was set to a size too big compared to the ram size, and since the sessions stored in the cache are only removed when the cache is full, and inserting new sessions caus

[NEW API Proposal] TSThreadCreateWithSignalling

2020-02-28 Thread Fei Deng
Recently while dealing with shutdown crashes related to plugins, I found a way to have individual threads process signals with their own signal handlers. After discussing with Alan, we agreed on that this might be too much freedom to open to people since signal handling is really tricky to do corre

Re: API Proposal: TSContDispatch

2019-11-20 Thread Fei Deng
say, _bad > programming_) then document it as a Gotcha/limitation, but, I still don't > see why/how a new API is needed to fix a bug. > > On Wednesday, November 20, 2019, 12:21:00 PM PST, Fei Deng > wrote: > > It's not a hole, it's how it should have been all a

Re: API Proposal: TSContDispatch

2019-11-20 Thread Fei Deng
hole? > > I haven’t fully analyzed and understood the proposed changes, but having > two different API that only differ in how they are implemented under the > hood (and one of them with an apparent hole) doesn’t sound right to me. > > - Sudheer > > > > On Nov 20, 2019,

Re: API Proposal: TSContDispatch

2019-11-20 Thread Fei Deng
such that the new execute ASAP is retained. On Tue, Nov 19, 2019 at 6:06 PM Leif Hedstrom wrote: > > > > On Nov 20, 2019, at 05:52, Fei Deng wrote: > > > > Forgot to mention that this change would restore the old behavior of > > TSContSchedule minus the delay and d

Re: API Proposal: TSContDispatch

2019-11-19 Thread Fei Deng
Forgot to mention that this change would restore the old behavior of TSContSchedule minus the delay and dead loop. On Tue, Nov 19, 2019 at 2:39 PM Fei Deng wrote: > While PR#6103 (https://github.com/apache/trafficserver/pull/6103) solves > the problem of having the 60ms delay (caused by w

API Proposal: TSContDispatch

2019-11-19 Thread Fei Deng
While PR#6103 (https://github.com/apache/trafficserver/pull/6103) solves the problem of having the 60ms delay (caused by waiting in sleep), it also creates an issue where the event loop ends up in a "dead loop" if the scheduled event schedules itself with 0 timeout (see test code by scw00). Here's

Re: Proposal: remove command "traffic_ctl config status"

2019-10-14 Thread Fei Deng
atus" existed from release 6 at the very least, if not longer). > My 2c.. > Thanks, > Sudheer > On Monday, October 14, 2019, 09:27:18 AM PDT, Fei Deng < > duke8...@apache.org> wrote: > > Seems like there's some use to it, maybe we should change it to display &

Re: Proposal: remove command "traffic_ctl config status"

2019-10-14 Thread Fei Deng
Seems like there's some use to it, maybe we should change it to display which configs are being modified, instead of just saying yes/no? On Fri, Oct 11, 2019 at 8:42 AM Emanuele Rocca wrote: > Hello! > > On 10/10 03:34, Fei Deng wrote: > > While fixing the problem where

Proposal: remove command "traffic_ctl config status"

2019-10-10 Thread Fei Deng
While fixing the problem where "remap.config" gets reloaded automatically, we noticed it is related to the command "traffic_ctl config status". Some of us at the summit thinks that this command isn't useful, since the only thing it does is returning a status code to say some config files has been c

Re: Tentative proposal: TS mutexes should be queues not OS mutexes

2019-10-02 Thread Fei Deng
I've done some profiling before, using Intel's VTune, you can ask Jason for details. On Wed, Oct 2, 2019 at 1:32 PM Leif Hedstrom wrote: > > > > On Oct 2, 2019, at 11:23 AM, Walt Karas > wrote: > > > > What's the best tool for multi-threaded profiling on Linux? > > Probably the Intel tools. Pr

Re: New API proposal: TSEmergencyShutdown

2019-06-19 Thread Fei Deng
I think it is already logging it right now, leif had a new PR for it just recently to remove the Emergency call. Regards, Fei Deng On Wed, Jun 19, 2019 at 11:18 AM Sudheer Vinukonda wrote: > >>> while on a config reload it should not call it and fall back to > the previou

Re: New API proposal: TSEmergencyShutdown

2019-06-19 Thread Fei Deng
, traffic server should call *Emergency*, while on a config reload it should not call it and fall back to the previous configuration. If I forgot something we just talked about please add to this note @Alan @Bryan. Regards, Fei Deng On Tue, Jun 18, 2019 at 10:11 AM Fei Deng wrote: > So t

Re: New API proposal: TSEmergencyShutdown

2019-06-18 Thread Fei Deng
So this is what it looks like now: tsapi void TSEmergency(const char *fmt, ...) { va_list args; va_start(args, fmt); EmergencyV(fmt, args); va_end(args); } Regards, Fei Deng On Tue, Jun 18, 2019 at 9:41 AM Fei Deng wrote: > Yes, this is suggested by Alan and Susan, since someti

Re: New API proposal: TSEmergencyShutdown

2019-06-18 Thread Fei Deng
Yes, this is suggested by Alan and Susan, since sometimes we need plugins to be able to abort and not try to restart (say if some important files are missing). I'll change the name to TSEmergency(). And I'll look at TSDebug and TSError, and make it similar to those. Regards, Fei Den

New API proposal: TSEmergencyShutdown

2019-06-17 Thread Fei Deng
void TSEmergencyShutdown(const char *log_msg); This API is a wrapper for the "Emergency" call, which signals traffic_manager to not restart traffic_server after the shutdown, i.e. this call should be used when something has gone wrong and cannot be recovered by a restart.

Re: [PROPOSAL] Move from the IRC to Slack

2019-05-12 Thread Fei Deng
+1 Already using slack for work, would be nice to use one client for all the chats. On Sun, May 12, 2019 at 3:46 PM Chris Lemmons wrote: > +1 > > While Slack isn't my favourite, I think the benefits outweigh the > costs. One of the biggest costs is the archive search. You can either > use somet

Re: API Proposal: TSThreadSetCancelState, TSThreadSetCancelType, TSThreadCancel, TSThreadJoin

2019-03-04 Thread Fei Deng
f > > > On Feb 28, 2019, at 21:46, James Peach wrote: > > > > > > > >> On Feb 28, 2019, at 9:17 AM, Fei Deng wrote: > >> > >> void TSThreadSetCancelState(TSThread thread, int state); > >> void TSThreadSetCancelType(TSThread thread, int typ

Re: API Proposal: TSThreadSetCancelState, TSThreadSetCancelType, TSThreadCancel, TSThreadJoin

2019-02-28 Thread Fei Deng
:55 PM Fei Deng wrote: > Use case right now is for the ssl_session_reuse plugin, it's crashing > during shutdown and the reason is one or more thread of it is lingering > just a bit too long and with openssl-1.1.1 it will crash. The current way > is to set a flag but there are threa

Re: API Proposal: TSThreadSetCancelState, TSThreadSetCancelType, TSThreadCancel, TSThreadJoin

2019-02-28 Thread Fei Deng
can find a way to hide them. On Thu, Feb 28, 2019 at 2:43 PM Leif Hedstrom wrote: > > > > On Feb 28, 2019, at 9:17 AM, Fei Deng wrote: > > > > void TSThreadSetCancelState(TSThread thread, int state); > > void TSThreadSetCancelType(TSThread thread, int type); > >

Re: API Proposal: TSThreadSetCancelState, TSThreadSetCancelType, TSThreadCancel, TSThreadJoin

2019-02-28 Thread Fei Deng
me sort when you start something, remove this object when you're done. > If the fail-safe timeout for a clean shutdown expired, ATS would log the > contents of the i_am_doing_something map, and then shut down ugly. > > On Thu, Feb 28, 2019 at 11:17 AM Fei Deng wrote: > > >

API Proposal: TSThreadSetCancelState, TSThreadSetCancelType, TSThreadCancel, TSThreadJoin

2019-02-28 Thread Fei Deng
void TSThreadSetCancelState(TSThread thread, int state); void TSThreadSetCancelType(TSThread thread, int type); void TSThreadCancel(TSThread thread); void *TSThreadJoin(TSThread thread); Some plugins have been causing a lot of crashes during ATS shutdown, the root cause is due plugin threads are n

API Proposal: TSThreadSetCancelState, TSThreadSetCancelType, TSThreadCancel, TSThreadJoin

2019-02-28 Thread Fei Deng
void TSThreadSetCancelState(TSThread thread, int state); void TSThreadSetCancelType(TSThread thread, int type); void TSThreadCancel(TSThread thread); void *TSThreadJoin(TSThread thread); Some plugins have been causing a lot of crashes during ATS shutdown, the root cause is due plugin threads are n

Re: New Lifecycle Hooks

2018-12-12 Thread Fei Deng
These would be synchronous hooks. On Wed, Dec 12, 2018 at 8:53 AM Alan Carroll wrote: > Would these be synchronous or asynchronous hooks? > > If this is done, I would them them done in separate PRs. In addition, > please write the man pages first. > > On Tue, Dec 11, 2018 at

New Lifecycle Hooks

2018-12-11 Thread Fei Deng
There are two new lifecycle hooks I'd like to add to the list: - TS_LIFECYCLE_TASK_THREADS_READY_HOOK - TS_LIFECYCLE_SHUTDOWN_HOOK TS_LIFECYCLE_TASK_THREADS_READY_HOOK is needed for the new TSContScheduleOn APIs. I don't think there is any way of telling whether the ET_TASK threads are

Re: [New API Proposal] TSContScheduleToCurrentThread and TSContScheduleToCurrentThreadEvery

2018-10-03 Thread Fei Deng
This is the current state of the APIs. I have this tracked on my private branch on github, please provide feedback for it. Thanks! https://github.com/duke8253/trafficserver/pull/5 On Tue, Aug 21, 2018 at 3:36 PM zzz wrote: > Thanks, Fei Deng, glad to hear the good news! Looking forward to

Re: [New API Proposal] TSContScheduleToCurrentThread and TSContScheduleToCurrentThreadEvery

2018-08-21 Thread Fei Deng
starts to unravel. > > > > > > > "check the callback continuations in the current API?" - check them for > > > what? I don't understand this question. > > > > > > > > > The callback cont for some async tsapi calls might not be c