Re: [API Proposal] Record reading functions returning std::optional

+1 Sent with Proton Mail secure email. On Monday, March 31st, 2025 at 6:13 AM, Hiroaki Nakamura wrote: > Hi, > > I'd like to change the third API from > > RecErrT RecGetRecordString(const char *name, char > *buf, int buf_len, bool lock = true); > > to > > std::optionalstd::string_view Rec

Re: [API Proposal] Record reading functions returning std::optional

Hi, I'd like to change the third API from RecErrTRecGetRecordString(const char *name, char *buf, int buf_len, bool lock = true); to std::optional RecGetRecordString(const char *name, char *buf, int buf_len, bool lock = true); as suggested by https://github.com/apache/traffi

[API Proposal] Record reading functions returning std::optional

Hi, I'd like to propose new APIs for record reading functions which return std::optional. std::optional RecGetRecordInt(const char *name, bool lock = true); std::optionalRecGetRecordFloat(const char *name, bool lock = true); RecErrTRecGetRecordString(const char *name,

Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

I created a PR for this. https://github.com/apache/trafficserver/pull/12032 Having ProxyProtocol in the name would be a bit confusing. One could read it like VConnProxy and ProtocolInfo. PROXY is an option, but not my preference. I kept PP on the PR. -- Masakazu On Sun, Feb 9, 2025 at 11:19 AM

Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

That’s another idea. I suppose between PROXY and PP I’d stick with PP. Brian "Come to Me, all who are weary and heavy-laden, and I will give you rest. Take My yoke upon you and learn from Me, for I am gentle and humble in heart, and you will find rest for your souls. For My yoke is easy and My bu

Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

I’m +1 too. Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper case) instead of PP, which is how it’s spelled. — Leif On Sat, Feb 8, 2025 at 20:03 Brian Neradt wrote: > +1 > > My preference would be to spell out ProxyProtocol in the API instead of > PP. But I don't feel

Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

+1 My preference would be to spell out ProxyProtocol in the API instead of PP. But I don't feel that strongly about it though. +1 either way. On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo wrote: > Hi, > > I'd like to propose a new TS API to access information from PROXY protocol. > > ATS suppo

[API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

Hi, I'd like to propose a new TS API to access information from PROXY protocol. ATS supports PROXY protocol, which carries connection information between a client and a LB (basically the 5-tuple). And I recently added the support for PROXY protocol version 2 TLV (Type-Length-Value) fields, which

Re: [API proposal] TSHttpSsnInfoIntGet

I kept the new API in experimental.h for now, because even existing TSHttpTxnInfoIntGet is currently in experimental.h and I think we probably want to have the Ssn version (new one) next to it. -- Masakazu On Wed, Oct 25, 2023 at 3:19 PM Leif Hedstrom wrote: > +1 > > As for experimental, I thin

Re: [API proposal] TSHttpSsnInfoIntGet

+1 As for experimental, I think we mostly decided to stop using this. In fact we should remove / move what’s left there IMO. — Leif > On Oct 25, 2023, at 14:10, Masakazu Kitajo wrote: > > Hi, > > I'd like to add TSHttpSsnInfoIntGet to TS API. The API documentation is on > the PR below: > h

[API proposal] TSHttpSsnInfoIntGet

Hi, I'd like to add TSHttpSsnInfoIntGet to TS API. The API documentation is on the PR below: https://github.com/apache/trafficserver/pull/10627 We currently have a similar function, TSHttpTxnInfoIntGet, for transactions, and the new API would be one for sessions. The function signature is basical

Re: [API proposal] Adding a third optional argument to TSMgmtUpdateRegister

+1 On Sun, Oct 22, 2023 at 5:05 PM Leif Hedstrom wrote: > > I’d like to update the existing API for TSMgmtUpdateRegister(), to add a > third, optional argument: > > > void TSMgmtUpdateRegister(TSCont contp, const char *plugin_name, const char > *plugin_file_name = nullptr); > > > The old behavi

[API proposal] Adding a third optional argument to TSMgmtUpdateRegister

I’d like to update the existing API for TSMgmtUpdateRegister(), to add a third, optional argument: void TSMgmtUpdateRegister(TSCont contp, const char *plugin_name, const char *plugin_file_name = nullptr); The old behavior (without providing this plugin_file_name) remains the same. However, w

Re: TS API Proposal: TS_FETCH_FLAGS_SKIP_REMAP

+1 On Mon, Aug 7, 2023 at 10:40 AM Masakazu Kitajo wrote: > > Could you achieve the same result my making > proxy.config.url_remap.remap_required overridable? > > No, I don't think I can take that approach for OCSP requests. Can we know > which requests are from FetchSM and made by ATS core for

Re: TS API Proposal: TS_FETCH_FLAGS_SKIP_REMAP

> Could you achieve the same result my making proxy.config.url_remap.remap_required overridable? No, I don't think I can take that approach for OCSP requests. Can we know which requests are from FetchSM and made by ATS core for OCSP requests? If it's just that a plugin wants to decide whether a r

Re: TS API Proposal: TS_FETCH_FLAGS_SKIP_REMAP

> On 4 Aug 2023, at 1:45 am, Masakazu Kitajo wrote: > > Hi, > > I'd like to propose a new flag for FetchSM that'd allow making HTTP > requests for other servers without remap rules regardless of ATS > configuration (proxy.config.url_remap.remap_required). Could you achieve the same result m

TS API Proposal: TS_FETCH_FLAGS_SKIP_REMAP

Hi, I'd like to propose a new flag for FetchSM that'd allow making HTTP requests for other servers without remap rules regardless of ATS configuration (proxy.config.url_remap.remap_required). The motivation is actually not enabling plugins to do the above. The code on master uses FetchSM for OCSP

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

Ahh yes, good point. TSReturnCode would be the better choice. On Tue, Feb 22, 2022 at 4:09 PM Robert O Butts wrote: > +1 > > Seems useful, and it shouldn't break backwards compatibility. > > But should it be a TSReturnCode of TS_ERROR or TS_SUCCESS, to match the > rest of the API? > > > On Tue,

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

+1 Seems useful, and it shouldn't break backwards compatibility. But should it be a TSReturnCode of TS_ERROR or TS_SUCCESS, to match the rest of 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 > p

[API] proposal to change the return type of TSSslTicketKeyUpdate

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 successful or not. Upon reading the related functions I think it's possible to return a bool value as an indication for a successful/

[API] - JSONRPC Plugin API proposal

Hello guys, As you all know there is a new JSONRPC implementation that is up for review which is intended to land in the 10-Dev branch. As a part of this effort and to use all the benefits of having such protocol in our ATS, I am proposing to add

Re: [E] New TS API Proposal: TSHttpTxnCacheDiskPathGet

Hi all, Based on a brief conversion on Slack with amc, I've added the length argument. Update commit: https://github.com/apache/trafficserver/pull/7783/commits/b44c9d932f3c4d9fdbdb037d7286d859e260bfe1 Please let me know if there is any other feedback on this API. -- Thanks, Jeff On Thu, May 6,

Re: [E] New TS API Proposal: TSHttpTxnCacheDiskPathGet

I just pushed a commit that incorporates this feedback and updated the dependent PR that enhances the xdebug plugin to reflect the change. The diff is as follows: – tsapi TSReturnCode TSHttpTxnCacheDiskPathGet(TSHttpTxn txnp, const char **path); + tsapi const char *TSHttpTxnCacheDiskPathGet(TSHttp

Re: [E] New TS API Proposal: TSHttpTxnCacheDiskPathGet

Going forward we want to be view oriented, and also to be consistent with other API, the signature should be arranged to return a view. E.g. const char * TSHttpTxnCacheDiskPathGet(TSHttpTxn txn, int * length); This is modeled on API calls such as TSHttpHdrHostGet, TSHttpTxnPluginTagGet, and the f

New TS API Proposal: TSHttpTxnCacheDiskPathGet

Hi all, I'd like to propose the introduction of a new TS API, TSHttpTxnCacheDiskPathGet. The function signature is as follows: tsapi TSReturnCode TSHttpTxnCacheDiskPathGet(TSHttpTxn txnp, const char **path); The intent of this API is to expose the underlying disk used to service a request, regar

Re: [API Proposal] Global Arg slots

I was planning on replacing the internals of TxnArg with the Extendible. I haven't fully fleshed out the API. I had planned to keep the C API backward compatible. But I really want to dive into a C++ API with type safety, which was a major goal in the Extendible implementation. On Fri, Mar 6, 2020

Re: [API Proposal] Global Arg slots

I am in favor of this because although the replace of In Name Only types with void * makes a more risky API, it is (in my judgement) a relatively minor risk especially since almost all of those types are in fact Continuations and the internals can check the dynamic_cast for success. I think it is m

Re: [API Proposal] Global Arg slots

> On Mar 4, 2020, at 12:18 PM, Walt Karas > wrote: > > Instead of int argument indexes, how about argument IDs of type: > > typedef struct > { > TSUserArgType type; > short idx; > } TSUserArgIDType; > > This would allow for more run-time type checking. Not sure I follow that… The type

Re: [API Proposal] Global Arg slots

Instead of int argument indexes, how about argument IDs of type: typedef struct { TSUserArgType type; short idx; } TSUserArgIDType; This would allow for more run-time type checking. On Wed, Mar 4, 2020 at 12:40 PM Alan Carroll wrote: > I like thinner and more automatic APIs. This is less

Re: [API Proposal] Global Arg slots

I like thinner and more automatic APIs. This is less typing overall, because the Get/Set functions don't require a type name in them. It also makes it easier to add or remove object args. Also, in the longer term (ATS 10) we should move to Extendible anyway, which provides real type safety. On Wed

Re: [API Proposal] Global Arg slots

> On Mar 4, 2020, at 11:17 AM, Walt Karas > wrote: > > So why do you like this? - Less code - Fewer APIs - Generalizes the concept I don’t feel super strongly about the Get() / Set()’ers, I can definitely retain the underlying core changes (which are good), and keep (and add more) of the

Re: [API Proposal] Global Arg slots

So why do you like this? - Breaks lots of existing code. - Less typesafe. - Makes use more verbose. It's good how the API has avoided the use of void pointers. We should not reverse that design goal. On Wed, Mar 4, 2020 at 12:03 PM Leif Hedstrom wrote: > > > > On Feb 27, 2020, at 10:13 AM, Le

Re: [API Proposal] Global Arg slots

> On Feb 27, 2020, at 10:13 AM, Leif Hedstrom wrote: > > Hi all, > > This is an idea from Bryan Call, which he suggested as a solution for > reloadable plugins changes that are now in 9.0.x. I recently ran into a > different use case (thanks Miles …), which could really benefit (performance

Re: [NEW API Proposal] TSThreadCreateWithSignalling

This seems reasonable and there's no apparent opposition, I think we should proceed. On Fri, Feb 28, 2020 at 2:21 PM Fei Deng wrote: > Recently while dealing with shutdown crashes related to plugins, I found a > way to have individual threads process signals with their own signal > handlers. Aft

Re: [API Proposal] Global Arg slots

> On Feb 27, 2020, at 8:02 PM, Sudheer Vinukonda > wrote: > > definitely very useful to share global data in a consistent (and supported) > manner than having to rely on something undocumented (like we do for sharing > global data between global and remap plugins) which as it’s proven now is

[NEW API Proposal] TSThreadCreateWithSignalling

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] Extend CPPAPI RemapPlugin to access TSRemapRequestInfo

Hi all, I opened a PR with the patch in this thread in https://github.com/apache/trafficserver/pull/6463 I expanded a little bit more in my motivation for this change here: https://github.com/apache/trafficserver/pull/6463#issuecomment-592659119 Cheers, David On Thu, Feb 27, 2020 at 11:34 AM Da

Re: [API Proposal] Global Arg slots

Yeah, I misunderstood the use case and the proposal. Synced up with Leif offline and I understand it better now. The existing Txn API allows to share data across states within a given transaction, while the new API is to share data globally across transactions. I’m still +1 on the new API, of c

Re: [API Proposal] Global Arg slots

I'm thinking perhaps we should instead pass a const pointer to: typedef struct { TSReturnCode (*globalArgIndexReserve)(const char * name, const char * description, int * arg_idx); TSReturnCode (*globalArgIndexNameLookup)(const char * name, int * arg__idx, const char ** description); TSRetur

Re: [API Proposal] Global Arg slots

Did you mean: void TSGlobalArgSet(int arg_idx, void * arg) void * TSGlobalArgGet(int arg_idx) ??? On Thu, Feb 27, 2020 at 11:13 AM Leif Hedstrom wrote: > Hi all, > > This is an idea from Bryan Call, which he suggested as a solution for > reloadable plugins changes that are now in 9.0.x. I re

Re: [API Proposal] Global Arg slots

Sudheer, can you create a branch in your trafficserver fork, that switches an existing plugin from using TxnArg to GlobalArg? I don't see how that would work typically. I believe the point is that you want a different value for the same arg index for each transaction. On Thu, Feb 27, 2020 at 11:

[API Proposal] Extend CPPAPI RemapPlugin to access TSRemapRequestInfo

Hi all, This is a proposal to add a new virtual method to the CPP API to get access to TSRemapRequestInfo. We're working on a plugin that changes the origin URL on demand, and the CPP API is a little bit confusing around which URL you need to modify to accomplish this, specially if you want to le

Re: [API Proposal] Global Arg slots

Yes, definitely +1 on the idea! Curious though, why couldn't we just ditch the existing ConnArg / SsnArg / TxnArg, in favor of the GlobalArgs or may be even just replace the existing ArgTable with the vector? -- Sudheer On Thursday, February 27, 2020, 09:13:11 AM PST, Leif Hedstrom wrote:

Re: [API Proposal] Global Arg slots

I understand your goal but I think this is the wrong approach. I think it would work better to add names to the "config" in the TSConfigGet family of functions. This also provides a nice "check out/in" mechanism for synchronization, On Thu, Feb 27, 2020 at 11:13 AM Leif Hedstrom wrote: > Hi all,

[API Proposal] Global Arg slots

Hi all, This is an idea from Bryan Call, which he suggested as a solution for reloadable plugins changes that are now in 9.0.x. I recently ran into a different use case (thanks Miles …), which could really benefit (performance wise) with such APIs. I *could* use the TxnArg APIs instead, but the

Re: API Proposal: TSContDispatch

Ah, missed some other stuff. The bug we've seen is one that's not always visible, particularly on busy systems, because the event loop never waits very long. However, in the particular use case here, the systems are sufficiently lightly loaded and the latency requirements sufficiently strict that

Re: API Proposal: TSContDispatch

For event processing style programming, it's standard to have two event scheduling "styles" - an immediate "do as soon as possible", and a "scheduled" style which is guaranteed to unwind the event processing stack at least once. In another way, it's similar to "call" and "yield" in co-routines. I w

Re: API Proposal: TSContDispatch

it's not a bug, it's how it was supposed to be from the beginning but wasn't functioning correctly. On Wed, Nov 20, 2019 at 2:27 PM Sudheer Vinukonda wrote: > >>> that will cause an issue for devs that are using > schedule with 0 timeouts in their code to schedule itself over and over > again (

Re: API Proposal: TSContDispatch

>>> that will cause an issue for devs that are using schedule with 0 timeouts in their code to schedule itself over and over again (see test code in PR comment), which is bad programming on their part but it might happen and is a valid concern.  So, isn't this a new bug introduced with PR# 6103? 

Re: API Proposal: TSContDispatch

It's not a hole, it's how it should have been all along, but have not been working properly for a long time. schedule_imm is supposed to put things in queue and have the eventloop process them asap and not waiting for IO or other stuff, but instead it stays in queue till we wake up the thread eithe

Re: API Proposal: TSContDispatch

Hmm..Why’d the API need to differentiate the implementation details to users? Alternately, why’d someone pick an API that may have 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

Re: API Proposal: TSContDispatch

Let me rephrase that, the new API behaves the same as the TSContSchedule with 0 timeout after PR#6103, which will handle events as soon as possible. While this is good for delays, it also causes the situation scw00 brought up (dead loop). And since there is no good way of differentiating this behav

Re: API Proposal: TSContDispatch

> 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 dead loop. > >> On Tue, Nov 19, 2019 at 2:39 PM Fei Deng wrote: >> >> While PR#6103 (https://github.com/apache/trafficserver/pull/6103)

Re: API Proposal: TSContDispatch

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 waiting

API Proposal: TSContDispatch

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: New API proposal: TSEmergencyShutdown

unsubscribe On Wed, Jun 19, 2019 at 7:13 PM Fei Deng wrote: > Adding some notes here from the discussion we had just now: > >- *Fatal* and *Emergency* both need to be exposed to plugins, where >*Emergency* keeps traffic server down and *Fatal* will try and restart >(just like the cor

Re: New API proposal: TSEmergencyShutdown

Weighing in late, as usual, but I'm not sure what Leif means by "ts/mgmt.h". Did you mean "ts/mgmtapi.h"? If so, that's a rather heavy weight solution for the desired action here. AFAICT using that requires setting up a full API client, not just making a single call to send a message. You'd also ha

Re: New API proposal: TSEmergencyShutdown

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 previous configuration.

Re: New API proposal: TSEmergencyShutdown

>>> while on a config reload it should not call it and fall back to the >>>previous configuration. Is there a way we can alert this (at a minimum, an Error log?)?  Falling back to old config (definitely preferable), but, silently is a bit misleading and confusing. - Sudheer On Wednesd

Re: New API proposal: TSEmergencyShutdown

Adding some notes here from the discussion we had just now: - *Fatal* and *Emergency* both need to be exposed to plugins, where *Emergency* keeps traffic server down and *Fatal* will try and restart (just like the core functions). - When reading configs for the first time and fails, tr

Re: New API proposal: TSEmergencyShutdown

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 sometimes we

Re: New API proposal: TSEmergencyShutdown

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 Deng On Mon, Ju

Re: New API proposal: TSEmergencyShutdown

Looking how Emergency() vs ink_emergency() works. The only difference is Emergency() calls Diags::cleanup_func() with is only defined in traffic_manager. Here is the call stack for Emergency(): Emergency > DiagsError > diags->error > error_va > ink_emergency_va > ::exit(UNRECOVERABLE_EXIT) Vs

Re: New API proposal: TSEmergencyShutdown

> On Jun 17, 2019, at 4:27 PM, Bryan Call wrote: > > I would assume he is going to be calling ink_emergency(), so it wouldn’t be a > management API. That’s not what I meant :). I believe things that does process management, such as stop / start / check status etc. etc. all belongs in the m

Re: New API proposal: TSEmergencyShutdown

I would assume he is going to be calling ink_emergency(), so it wouldn’t be a management API. Fei, can you add more details about what "This API is a wrapper for the "Emergency” call” is really going to do? -Bryan > On Jun 17, 2019, at 3:22 PM, Leif Hedstrom wrote: > > > >> On Jun 17, 201

Re: New API proposal: TSEmergencyShutdown

> On Jun 17, 2019, at 4:16 PM, Bryan Call wrote: > > I would recommend having it like TSDebug and TSError. > > tsapi void TSEmergency(const char *fmt, ...) TS_PRINTFLIKE(1, 2); > > TSDebug and TSError: > tsapi void TSDebug(const char *tag, const char *format_str, ...) > TS_PRINTFLIKE(2, 3);

Re: New API proposal: TSEmergencyShutdown

I would recommend having it like TSDebug and TSError. tsapi void TSEmergency(const char *fmt, ...) TS_PRINTFLIKE(1, 2); TSDebug and TSError: tsapi void TSDebug(const char *tag, const char *format_str, ...) TS_PRINTFLIKE(2, 3); tsapi void TSError(const char *fmt, ...) TS_PRINTFLIKE(1, 2); -Brya

Re: New API proposal: TSEmergencyShutdown

> On Jun 17, 2019, at 3:13 PM, Fei Deng wrote: > > 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

New API proposal: TSEmergencyShutdown

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: API Proposal: SSL client context retrieval

I think the main barrier to good documentation is the amount of reverse engineer it would require at this point. I've never found Doxygen to be so helpful but also have not used it much. Unlike other languages such as Java, C++ is designed to allow separating interface from implementation, so bett

Re: API Proposal: SSL client context retrieval

Here are the prototypes with comments: /** * This function retrieves an array of lookup keys for client contexts loaded in * traffic server. Given a 2-level mapping for client contexts, every 2 lookup keys * can be used to locate and identify 1 context. * @param n Allocated size for result arr

Re: API Proposal: SSL client context retrieval

Yes, although doxylink requires a couple of patches to work well with C++17. I have PRs up on the repo for those fixes, but need to find time to write some unit tests to get them accepted. The goal is to have Doxygen generate reference material, while Sphinx provides higher level descriptions of t

Re: API Proposal: SSL client context retrieval

Alan do you mean this? https://pythonhosted.org/sphinxcontrib-doxylink/ On Thu, May 2, 2019 at 9:21 AM Leif Hedstrom wrote: > > > > On May 2, 2019, at 08:17, Alan Carroll > wrote: > > > > Yes they can work together. I presented on that at the Summit, you should > > have been there. > > I shoul

Re: API Proposal: SSL client context retrieval

> On May 2, 2019, at 08:17, Alan Carroll > wrote: > > Yes they can work together. I presented on that at the Summit, you should > have been there. I should have. So is that setup today? Where does it go? How does it synergize with all existing API docs? And, stop inlining Doxygen comments

Re: API Proposal: SSL client context retrieval

Yes they can work together. I presented on that at the Summit, you should have been there. On Thu, May 2, 2019 at 9:15 AM Leif Hedstrom wrote: > +1 on docs. > > However , I think it’s a bit of a mess now with Doxygen sometimes, and > normal Sphinx docs (most of the time?). It seems we should hav

Re: API Proposal: SSL client context retrieval

+1 on docs. However , I think it’s a bit of a mess now with Doxygen sometimes, and normal Sphinx docs (most of the time?). It seems we should have one way of documenting our interfaces and APIs, no? I find often times, Doxygen can get in the way of code formatting / indentation, specially when

Re: API Proposal: SSL client context retrieval

They shouldn't become invalid during the callback invocation, but may after the callback returns. As for Doxygen, perhaps I am simply weird in that I like to have documentation for API that I call. I guess I'm just not smart enough to deduce the meaning and function from only the function and para

Re: API Proposal: SSL client context retrieval

Talked with Zeyuan, he clarified that an example call would be something like: const char *ctx[666]; int n_actual_ctx; rc = TSSslClientContextsGet(666, ctx, &n_actual_ctx); I don't know enough about SSL to know when the pointers in ctx[] would become dangling. On Wed, May 1, 2019 at 2:55 PM Zey

Re: API Proposal: SSL client context retrieval

Doxygen is all that at sign business? Been here almost 2 years first time I heard it's required. Zwoop did thank me for not doing that. On Wed, May 1, 2019 at 4:59 PM Alan Carroll wrote: > Um, any detail on what the parameters are? Doxygen comments should be the > minimum provided. > > On Wed,

Re: API Proposal: SSL client context retrieval

Um, any detail on what the parameters are? Doxygen comments should be the minimum provided. On Wed, May 1, 2019 at 2:55 PM Zeyuan Yu wrote: > Alan and Walt pointed out the API needs to be C. Here are the new > prototypes: > > TSReturnCode TSSslClientContextsGet(int n, const char **result, int >

Re: [API proposal] TSVConnSslVerifyCTXGet

Details in PR https://github.com/apache/trafficserver/pull/5414 On Wed, May 1, 2019 at 4:36 PM SUSAN HINRICHS wrote: > > > -- Forwarded message - > From: SUSAN HINRICHS > Date: Wed, May 1, 2019 at 4:36 PM > Subject: [API proposal] TSVConnSslVerifyCTXGet &g

Fwd: [API proposal] TSVConnSslVerifyCTXGet

-- Forwarded message - From: SUSAN HINRICHS Date: Wed, May 1, 2019 at 4:36 PM Subject: [API proposal] TSVConnSslVerifyCTXGet To: Finally going in to fix the TS_SSL_VERIFY_CLIENT_HOOK and TS_SSL_VERIFY_SERVER_HOOK and needed to add a call to get access to the X509_STORE_CTX

[API proposal] TSVConnSslVerifyCTXGet

Finally going in to fix the TS_SSL_VERIFY_CLIENT_HOOK and TS_SSL_VERIFY_SERVER_HOOK and needed to add a call to get access to the X509_STORE_CTX object to the plugin as pointed out by CrendKing in https://github.com/apache/trafficserver/issues/4569 I propose adding the following API. I will put u

Fwd: [API proposal] TSVConnSslVerifyCTXGet

-- Forwarded message - From: Susan Hinrichs Date: Wed, May 1, 2019 at 2:46 PM Subject: [API proposal] TSVConnSslVerifyCTXGet To: dev Finally going in to fix the TS_SSL_VERIFY_CLIENT_HOOK and TS_SSL_VERIFY_SERVER_HOOK and needed to add a call to get access to the X509_STORE_CTX

Re: API Proposal: SSL client context retrieval

Alan and Walt pointed out the API needs to be C. Here are the new prototypes: TSReturnCode TSSslClientContextsGet(int n, const char **result, int *actual) ; TSSslContext TSSslClientContextFind(const char *name); [image: work-eat-sleep--400090.jpg] *Zeyuan Yu* Software Development Engineer, Veri

API Proposal: SSL client context retrieval

vector TSSslClientContextsGet(); TSSslContext TSSslClientContextFind(const string name); ATS has APIs for server context retrieval (TSSslContextFindByName(), TSSslContextFindByAddr()). It would be useful to expose client context via APIs too. I would like to propose new APIs for this purpose. Gi

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

At some point pthreads may conceivably be made obsolete by a better thread library on Linux, MacOS or FreeBSD, and C++ standard would be ported to run on the better thread library. But true, unlikely to happen in ATS's lifetime. On Wed, Mar 6, 2019 at 4:02 PM Leif Hedstrom wrote: > > > > On Ma

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

> On Mar 5, 2019, at 16:10, Walt Karas wrote: > > What I was trying to say was, if we keep the thread handles abstract, we > can switch from pthreads to stdc++ threads without impacting the plugins. Hmm, what’s the point / win in that? Likely c++ threads are an abstraction on top of pthreads

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

What I was trying to say was, if we keep the thread handles abstract, we can switch from pthreads to stdc++ threads without impacting the plugins. On Tue, Mar 5, 2019 at 5:02 PM Leif Hedstrom wrote: > > > > On Mar 5, 2019, at 2:24 PM, Walt Karas > wrote: > > > > Would we ever want to switch ove

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

> On Mar 5, 2019, at 2:24 PM, Walt Karas > wrote: > > Would we ever want to switch over to using libstdc++ threads? I’m likely ok with that, but we have to figure out the story with retaining C APIs. I.e. this is a big decision to make, making ts/ts.h requiring C++ to compile. I’m not *o

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

Would we ever want to switch over to using libstdc++ threads? On Tue, Mar 5, 2019 at 3:12 PM Leif Hedstrom wrote: > I still think it might be time to investigate if eliminating this > abstraction is better. Like I said, we only support posix threads anyways > so this abstraction is just extra ov

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

I still think it might be time to investigate if eliminating this abstraction is better. Like I said, we only support posix threads anyways so this abstraction is just extra overhead I assume ? — Leif > On Mar 4, 2019, at 09:57, Fei Deng wrote: > > I don't like setting cancel state and type

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

I don't like setting cancel state and type myself either, but at the time I couldn't come up with other ways of making sure the thread are in the right state/type. I think the idea just returning a pthread_t to the plugin is a good idea, it can also solve the problem with the set state/type, I didn

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

Good points. And, is here even a reason to keep our own thread APIs? We only support posix threads anyways. — Leif > 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

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

> On Feb 28, 2019, at 9:17 AM, Fei Deng wrote: > > void TSThreadSetCancelState(TSThread thread, int state); > void TSThreadSetCancelType(TSThread thread, int type); I guess you are supposed to pass PTHREAD_CANCEL_* for type type parameter? I don't like how this leaks the pthread implementati

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

So something like this: while (!plugin_threads.empty()) { TSThread th = plugin_threads.front(); // Cancel the threads, then call join to make sure they actually are stopped. TSThreadCancel(th); TSThreadJoin(th); plugin_threads.pop(); } On Thu, Feb 28, 2019 at 2:55

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

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 threads that sleeps up to 30 seconds, or if the timi

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

> On Feb 28, 2019, at 9: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); That’s a lot of APIs for something that sounds “

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

I thought about doing that, but that requires a lot of inter thread communication, and we might need to change all the other threads to do it the new way. It could be a better way moving forward, but these apis will solve the problem right now and we can fix the real problem later. On Thu, Feb 28,

API Proposal: TSThreadSetCancelState, TSThreadSetCancelType, TSThreadCancel, TSThreadJoin

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

  1   2   3   >