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?
&
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
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
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
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
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
.
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
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,
thread pools
Event *EventProcessor::schedule_spawn();
We probably should also implement a TSContScheduleEvery variant along with
it.
--
Regards,
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
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
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
ssful/failed
key update.
So I'm proposing that we change the return value type of
TSSslTicketKeyUpdate from void to bool.
Regards,
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
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
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
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,
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
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
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
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
&
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
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
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
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
, 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
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
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
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.
+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
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
: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
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);
> >
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:
>
> >
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
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
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
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
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
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
40 matches
Mail list logo