See my previous email - we could say it must be a POD for TxnAlloc and if it's
not, use Cleanup.
-Original Message-
From: Chris McFarlen
Sent: Friday, December 8, 2023 12:03 PM
To: dev@trafficserver.apache.org
Subject: Re: [TSAPI] TSTxnAlloc
Should the template function versions ensure
>> If the memory returned by these new functions are not in the Txn arena,
>> where are they stored?
In a swoc::MemArena which will replace the Arena in the HTTP state machine.
>> I guess my comments for the TxnAuxDataMgr class template are too sparse:
>> https://github.com/apache/trafficserver/
"Arena.h" is scheduled for KIWF. This would be implemented using
swoc::MemArena, which is already available to plugins. I am concerned about
giving plugins direct access to the MemArena because I planned to use it
internally in the HttpSM as well. I would be interested to
hear what others thinks
Proposed Transaction based memory allocation API
TSTxnAlloc
**
Traffic Server Transaction based memory allocation.
Synopsis
.. code-block:: cpp
#include
.. function:: swoc::MemSpan TSTxnAlloc(TSHttpTxn txn, size_t bytes)
.. function:: swoc::MemSpan TSTxnAllocAligned(TSHt
Yes. That's now a language feature, we should KIWF.
-Original Message-
From: Masakazu Kitajo
Sent: Tuesday, October 31, 2023 4:28 PM
To: dev@trafficserver.apache.org
Subject: Re: What should we do with noncopyable.h?
I'd say get rid of it (when we delete the C++ API). I don't like havin
Note this could be done the same way as remap - put all the literals in one
search structure and check for that first. If there's a match, it's for a
specific line in the file and one need only linear search the regular
expressions before that line. Anecdotally I've been told you can improve rem
There’s a viewpoint issue with these measurements. ATS will record when the
last byte was written to the inbound socket. This will always appear longer
from the client point of view because those bytes will take time to move from
the kernel socket buffers to the client and this depends strongly
I agree with deprecating Linux native AIO. I have heard of many problems with
it and not once any successful use. I don't think it's the ATS implementation,
I think the kernel support has never been all there. And now with io_uring, I
doubt it will ever be fixed, rather native AIO will be replac
This seems reasonable, although I'd call it "tr-allow-plain" to indicate that
plain text HTTP is enabled along with TLS. As noted, this is similar in flavor
to the existing "tr-pass" except instead of blind tunneling, it tries plain
text HTTP. We can allow both with a preference for plain text
In trying to start using libswoc I ran in to some build issues. I put this
partially in to an earlier PR updating libswoc but was requested to make it a
separate PR.
This PR does two things. The major one is to move "lib/records" out of "lib"
and in to "src" and "include", splitting the headers
Best to just put up a PR. It's ok if the PR is small.
On Sat, Aug 21, 2021 at 8:57 AM Randy DuCharme
wrote:
> Hey all,
>
> Seems like the latest fetch from master is missing that include directive
> in *trafficserver/plugins/experimental/traffic_dump/session_data.h*. Has
> anyone got anything g
>
> Yes, we don't want to mess around with the actual indexing in this PR.
>
A couple of thoughts -
1. We could have a static instance of the options which could be `memcpy`
into the struct to initialize it to default values.
2. It's kind of ugly, but we could have a function to initialize an op
u're suggesting. With this foundation, we might be able to merge
> `TSHttpConnectTransparent()` into `TSHttpConnectPlugin()` as time
> permits.
> --
> Thanks,
> Jeff
>
> On Mon, Jul 26, 2021 at 1:07 PM Alan Carroll
> wrote:
> >
> > There is already a pr
There is already a problem where the set of "connect" methods and the
options grow without bounds. This first came up with transparency (outbound
transparent) and now we have it with IOBuffer control. What I'd like is to
create a new connect function that takes an option structure. This would
conta
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
The difference is that for ATS 9, the ability to reload the DSO for remap
plugin causes the remap DSO to have different static data than the global
DSO even though they are loaded from the same DSO on disk. This is, shall
we say, somewhat unexpected.
As another note, the global plugin argument sup
Yes, sorry, I'm OOO this week. You can disable it in "records.config" but
there is also now a plugin API call to disable it for a specific plugin
which is a safer approach. I don't recall offhand, but it should be in the
ATS 10 docs, and I think it's been backported to our ATS 9. There's an
example
I would expect the 60ms ttms is due to the event loop timing - that because
of the DNS callout, there is a miss which then waits for the event loop to
timeout and try again, which takes 60ms on a lightly loaded system. DNS is
done even for cache hits but that's not something I've ever understood. I
UrDs&m=zFZbls36NrhIT2vj_0hfqinSa9lAhT-6H4trx4FBBoQ&s=fB-M3Z_KFA6aSyaHeYdEIPIMyITM1nAhfCfnCwf7pO4&e=
>
> void TSHttpTxnResponseActionSet(TSHttpTxn txnp, TSResponseAction *action);
>
>
> On Thu, Mar 4, 2021 at 3:18 PM Alan Carroll
> wrote:
>
> > >
> > > I think y
>
> I think you noted that TSHostnameIsSelf(const char *hostname) is painful
> to make take a non-null terminated string. Is that still the case?
void TSHttpTxnResponseActionSet(TSHttpTxn txnp, TSResponseAction action); -
I still don't like passing the action by value.
+1
On Thu, Nov 19, 2020 at 6:15 PM Susan Hinrichs
wrote:
> There is also a proxy.config.http.parent_proxy.connect_attempts_timeout. I
> have less familiarity with the parent selection path, but I question the
> value of separating that case out as well.
>
> On Thu, Nov 19, 2020 at 6:05 PM Susan
regex showing up multiple times in that file with different
> expiration times. The error made comes from choosing too long a TTL for
> the revalidation rule.
>
> On 11/17/20, 7:40 AM, "Alan Carroll"
> wrote:
>
> Is this all in the same configuration? Or duing a conf
Is this all in the same configuration? Or duing a config reload?
On Fri, Nov 13, 2020 at 1:39 PM Olsen, Brian
wrote:
> Never mind that's too hard to keep track of. The idea here is that if a
> new regex_revalidate rule comes in with the same regex as an active but a
> different expiration time
for any kind of log).
>
> On Monday, October 19, 2020, 09:48:33 AM PDT, Alan Carroll
> wrote:
>
> I'm addressing the question of "why not do this for all messages?". I
> think
> Neue Brie's approach for specific messages is fine. If, however, the
> ge
e throttling when exceeding a rate of 10
> occurrences/sec vs 5/sec matters for each given type of log message, then I
> guess that's a different problem altogether.
> Nevertheless, sounds like a good topic to discuss during the summit?
> On Monday, October 19, 2020, 08:23:12
unless we want it customized per log line (I’m
> not sure if this is really needed?), a system wide config may still be
> possible to configure, no?
>
> > On Oct 19, 2020, at 7:04 AM, Alan Carroll
> wrote:
> >
> > My concern at this point is the lack of configurability
My concern at this point is the lack of configurability of the throttle
time. The underlying implementation supports it but by wrapping it directly
in the logging call, only the default value can be used.
ygwkPvGGOgslH3ebXP4-mnTtFJc3haQqTFed4pNg&s=g5gOZR6b6ewuLPRZ8za0GQJNTS-kokmEwer56gVjt_Y&e=
> TSHttpHdrEffectiveUrlBufGet(): 127.0.0.1:61000/
> TSUrlSchemeGet(): failed to get URL scheme
>
> That's not what we want is it?
>
> On Wed, Oct 7, 2020 at 10:10 AM Alan Carroll
> w
p;m=tHbcxwP-7R4CDqWxQtN0lU5SU0iqTJtPosNC-K_tQ6Q&s=oi7IufY5vsl5r1JR9oGUyIHWUsG5ANRXj-SZXx67r2g&e=
> HTTP/1.1\r\n\r\n" | nc localhost 61001
>
> I get "http" for both. Does that mean it's already working as desired?
> Should TSUrlRawSchemeGet() return an empty string for the f
eturns 61000. Should TSUrlRawPortGet() also return 6100 ?
>
> On Thu, Oct 1, 2020 at 1:31 PM Alan Carroll <
> solidwallofc...@verizonmedia.com> wrote:
>
>> After discussions, this will be changed to TSUrlRawPortGet that returns 0
>> if the port is not explicitly present i
I thought I had, but I can't find it. I did discuss this at the last
summit, but that slide is not very informative..
On Fri, Oct 2, 2020 at 11:05 AM Sudheer Vinukonda
wrote:
> Sounds reasonable to me!
>
> A related aspect for completeness would be to also drop all the existing
> keep alive sess
I would like to propose a change to how TS handles unresponsive upstream
destinations. The current logic is
- If there is a round robin, skip elements that are down.
- Attempt to connect.
- If the connect fails, and the upstream is marked down and within the
down server cache time, res
After discussions, this will be changed to TSUrlRawPortGet that returns 0
if the port is not explicitly present in the URL.
On Tue, Sep 29, 2020 at 9:28 AM Walt Karas
wrote:
> This gets the port string in the URL. If the port is not in the URL, it
> returns nullptr (and sets length to zeor). Not
where the
scheme can be set in an HTTP/2 field. OTOH if it is a field that could be
handled the same way as for "Host" currently, which is by leaving the.
burden of checking that to the plugin.
On Tue, Sep 29, 2020 at 9:38 AM Alan Carroll <
solidwallofc...@verizonmedia.com> wrote:
28, 2020 at 10:02 PM Walt Karas
> > wrote:
> >
> >> You mean, for example, the name is passed as a plugin parameter or in a
> >> plugin config file? Is this for txn box? Is it obvious to everyone but
> >> me
> >> that a use for this will come up?
>
I don't see how this would depend on a cache hit or miss. If two requests
map to the same object, that's the cache key, not the request scheme. This
returns the scheme in hdr->m_http->req.m_url_impl.scheme or
hdr->m_http->req.m_url_impl.m_url_type if the former is nullptr.
The point here is to pro
pect it may need to
> become a float?
>
> On Mon, Sep 28, 2020 at 2:43 PM Alan Carroll
> wrote:
>
> > Suppose you want to fetch a configuration value, and want to know whether
> > to call TSMgmtIntGet or *TSMgmtFloatGet*. There is currently no way to
> know
> > pr
Suppose you want to fetch a configuration value, and want to know whether
to call TSMgmtIntGet or *TSMgmtFloatGet*. There is currently no way to know
programmatically. The code has to "just know" which it is.
On Mon, Sep 28, 2020 at 2:10 PM Walt Karas
wrote:
> Can you describe an example situati
3 values of these. Notice that the above
> >> are
> >> generic to the specific HTTP protocol type used by the transaction.
> >>
> >> I'll hold off on updating the docs in the PR until I get confirmation
> that
> >> this looks OK to the c
Sorry for chiming in late -
Note this is extremely similar to IP addresses and I recommend we use the
same solution. That is, there is a class HttpPriority which has just a
type/style/family value and possibly a length. This is an abstract class
like sockaddr (which no one actually instantiates).
It may be simpler but it is still not completely determined.
On Wed, Jul 8, 2020 at 10:28 AM Sudheer Vinukonda
wrote:
> Right, I understand that. But, the server side protocol stack isn’t as
> varied or has anywhere as many combinations as the client side and is
> largely determined by system wi
+1
On Sun, Jun 14, 2020 at 11:27 AM Leif Hedstrom wrote:
> +1
>
> > On Jun 14, 2020, at 09:32, Bryan Call wrote:
> >
> > I would like to propose that we switch to "Squash and Merge" for GitHub
> as the only option for merging pull requests. This would mean we would
> remove the options “Rebas
OK, let's discuss it here:
https://github.com/apache/trafficserver/issues/6633
On Wed, Apr 8, 2020 at 4:22 PM David Calavera
wrote:
> I'm very interested in having a much more open control plane.
>
> On Wed, Apr 8, 2020 at 12:52 PM Alan Carroll
> wrote:
>
> >
We (Damian and I) are starting work on replacing the current administrative
control channel with an JSON-RPC based one, as I have mentioned at previous
summits. The basic write is here:
https://solidwallofcode.github.io/RPC.en.html.
I would prefer to not discuss this on the mailing list. If there
depends on how much work you're doing in task
> threads, but it'd be very good to have some suggestions from people's
> experience changing that setting in real production environments.
>
> On Fri, Mar 27, 2020 at 9:03 AM Alan Carroll
> wrote:
>
> > I put mos
I put most of my discussion on the PR 6577, but discussing this with
Sudheer and Fei, I think the consensus is
1) Accept the PR for ATS 9.
2) For ATS 10 (or maybe 9.1?), deprecate TSContSchedule. Make it explicit
to schedule on a pool or thread.
On Thu, Mar 26, 2020 at 2:51 PM Walt Karas
wrote:
-time type checking.
>
>
> Not sure I follow that… The type safety stuff is in the Get() / Set()
> functions void*, not the index, and this doesn’t help that ? Also, seems
> non-ATS API to require this additional struct .
>
> — Leif
>
>
> >
> > On Wed, Mar
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
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
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,
Ship it.
On Fri, Feb 14, 2020 at 11:46 AM John Rushford wrote:
> Good idea +1
>
> On Fri, Feb 14, 2020 at 3:36 AM Damian Meden
> wrote:
>
> > Context
> >
> > If there is any problem with traffic server which causes the server not
> to
> > start, traffic manager will retry using an exponential s
IN the long run, yes, we may want to make the signal different or
configurable. Our current plan is to try this internally first and see how
the ops guys like it, or if they have problems making it work. At this
point, going with SIGUSR2 is IMHO the best option, because the cost of
fixing it later
In general, if it is necessary need to wait on an (externally) asynchronous
event then the plugin should spawn a thread to do the waiting. That is what
I did for the "SSL bump" work where the plugin has to wait on an external
connection to provide data.
On the wait thread, when the wait completes,
at 7:02 PM Dk Jack wrote:
> Thanks Alan. Would be nice to have in future if possible. We have an nginx
> module as well, where the module can access to original raw string. We’ll
> have live with this for now.
>
> Dk.
>
> > On Dec 17, 2019, at 3:56 PM, Alan Carroll
>
ort anomalies to tease out the good from the bad.
> Not able extract the exact string that was sent by the client reduces our
> effectiveness. Hope you now understand the motivation behind my question.
> Thanks.
>
>
>
> > On Dec 17, 2019, at 7:23 AM, Alan Carroll
> wrote:
&
You are seeing them "as is" - the view is literally the memory in which
those values are stored. The space between the colon and the value is not
part of the value, it's part of the syntax no different than the colon.
That is, you
used "%s:%s" to print the name/value for the field. Note the litera
This behavior is intrinsic to the plugin API. The values returned are the
equivalent of `std::string_view` and directly reference the appropriate
parts of the header. The spaces aren't "stripped" per se, it is simply that
the views don't include the spaces. When constructing a new field the space
i
I think any additional documentation of the HTTP state machine and its
transitions would be very useful. However, I'd much prefer it to be in
plant-UML format. As a first pass, just sequencing the basic states would
be good. If needed, sub-state diagrams showing particular states would be
the next
ink this is what we have to do to resolve the
issue.
On Wed, Nov 20, 2019 at 3:52 PM Alan Carroll <
solidwallofc...@verizonmedia.com> wrote:
> For event processing style programming, it's standard to have two event
> scheduling "styles" - an immediate "do as soon
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
That doesn't seem to account for the proto object used in the class
allocator. I think you might be OK with std::unique_ptr anyway, because it
default constructs to a nullptr.
On Wed, Nov 20, 2019 at 12:03 PM Walt Karas
wrote:
> Does this, https://godbolt.org/z/4muzR3 , satisfy everyone that ins
How is data put in to the MIOBuffer in that API?
How is that better than MIOBuffer::write and IOBufferReader::read? You can
already interact with MIOBuffers without having to directly manipulate
IOBuffers. However, it is significantly more performant (in most cases) to
work with the IOBuffer block
remental improvement for the
> current approach. I'm just offering alternatives approach for
> consideration.
>
> Were any measurements sent to this mailing list or recorded somewhere else?
>
> On Thu, Oct 3, 2019 at 9:14 AM Alan Carroll
> wrote:
>
> > I didn'
It's essentially
> the
> >> same idea as having a single line to pay even when there are multiple
> >> cashiers.
> >>
> >>
> >> >
> >> > >
> >> > > We're making complex thread affinity changes, on top of an
You need to talk to the L7R group at the summit. What does it do if no
upstream is available? That's the actual issue my change would address. I
do think we should either make this change, or simply remove support for
handling dead upstrreams - the current implementation is worse than useless
IMHO.
erstand and work on. Simplification and
> more modularity is obviously a goal. Seems like it would be simpler if all
> the Continuations in a to-run list where actually ready to run.
>
> On Tue, Oct 1, 2019 at 9:22 AM Alan Carroll
> wrote:
>
> > Do you have any more specifi
Do you have any more specific information on mutex contention? We have in
fact already looked at doing this, I think back in 2015 with Dan Xu. The
goal there was to have queues with the mutexes to avoid rescheduling. As a
precursor Dan did some profiling and the only significant lock contention
he
read my mind though :) )
> Anyway, will this work?
>
> milestones[SSN_START] = ua_txn->get_proxy_ssn()->ssn_start_time;
>
>
> On Thursday, September 19, 2019, 03:31:14 PM PDT, Alan Carroll
> wrote:
>
> No, that won't work - the start time is for the sessi
just saying it seems something that's relevant/related to existing
> milestones as well and seemed like a natural fit.
>
>
>
>
> On Thursday, September 19, 2019, 02:07:29 PM PDT, Alan Carroll
> wrote:
>
> Currently, the start time is stored in ProxySession. How wo
d if there is
> and it does seem like a reasonable thing to support though.
> I'm +0 on adding `TSHttpSsnStartTime`, but, would like to hear from others
> too on what they think.
>
> On Thursday, September 19, 2019, 11:58:32 AM PDT, Alan Carroll
> wrote:
>
> It's not reall
it make sense to add this as a milestone and extend the
> existing API `TSHttpTxnMileStoneGet` (and `TSMilestonesType`) to support
> session start time and possibly other session level context associated to
> that Txn?
> Thoughts?
>
>
> On Thursday, September 19, 2019, 11:38:47
I'm playing with some session stuff and I'd like to add this, since the
data is already stored in the session, it's trivial to access.
Although the epoll_wait timeout defaults to 10ms, it can be much longer
between calls to do I/O. After calling epoll(), for each data transfer a
callback is invoked on a VConnection, and therefore I/O will not be done
again until all of the pending I/O has been handled. This can take a
non-trivial
I thought when we discussed this you were going to segregate these by type.
One might consider splitting the current TSMLoc in to TSHdrLoc and TSMLoc,
the latter requiring a release. I agreed with your view that it was best to
have distinct types to avoid confusion about what should be passed to wh
Is ATS actually receiving FINs on those connections? Can ATS know the
session is dead before trying a transaction on it?
On Thu, Aug 15, 2019 at 7:45 PM Sudheer Vinukonda
wrote:
> Use case - We’ve some origins behind our proxy that get very low qps. Our
> server session sharing is set to Host ba
Looking at this PR, it would be better if it could use "nullptr" instead of
"0", but that depends on the requirement that plugins be built with a C++
compiler. I know that's been discussed on and off and if I recall correctly
we did commit to that. Is my memory correct? Can we require a C++ compile
heir client-side VConn, and see if it's
> internally-generated. But there is currently no API function that takes a
> TSVConn parameter and returns whether or not it is internally-created.
>
> On Thu, Jul 25, 2019 at 5:48 PM Alan Carroll
> wrote:
>
> > We certainly need s
We certainly need some API to determine if a connection and/or a state
machine is an internal request. That's used heavily.
On Thu, Jul 25, 2019 at 3:16 PM Walt Karas
wrote:
> The old Mexican saying el que calla otorga applies here.
>
> On Thu, Jul 25, 2019 at 1:44 PM Walt Karas
> wrote:
>
> >
Looking at the current API in this area, I think it might be better to
model it on TSStatFindName and related functions. This would mean something
like
TSReturnCode TSSslStatFindName(const char * name, int * idx);
TSMgmtInt TSSslStatGet(idx);
On Wed, Jul 17, 2019 at 12:39 AM Valentín Gutierrez <
Yes, a session is an inbound connection. Tracking all requests on an
inbound connection is precisely what the traffic_dump plugin does using
that hook.
On Sat, Jul 13, 2019 at 11:55 AM Dk Jack wrote:
> Interesting. Would a session mean TCP/ssl session? Would this allow
> for keeping track of all
I'll try to take a look. Did the slides help at all?
On Tue, Jul 2, 2019 at 9:52 PM Dk Jack wrote:
> Hi All,
> Can someone take a look at the iptables trace below and see if I am making
> an error with my ATS linux bridge mode configuration? I've been trying to
> configure ATS in linux bridge mo
Although the old name has never been used, since it wasn't just
undocumented, it was inaccessible.
On Tue, Jul 2, 2019 at 2:25 PM Sudheer Vinukonda
wrote:
> +1
> I definitely like the idea of preserving the API name that's already
> existed and throwing away the unimplemented one!
> On Tues
Triggered by a recent email exchange on this subject, and Watl's proposal
in this are, and due to the fact that I was doing plugin work that also
needed that sort of API, I realized the current API is rather dismal in
this regard. I propose adding this function.
TSReturnCode TSHttpHdrEffectiveURL
I don't think this went through so I'm sending it again.
These are slides from an ApacheCon talk I gave about transparency. Among
the details is a nice check list of things to check when it doesn't work.
https://www.dropbox.com/sh/h7erczfbt8ug8kn/AADJAqNz_xizurIHE6hx8Q8ka?preview=ApacheCon-2013.p
My mistake, TSHttpTxnEffectiveUrlStringGet is documented here -
https://docs.trafficserver.apache.org/en/8.0.x/developer-guide/api/functions/TSUrlStringGet.en.html#c.TSHttpTxnEffectiveUrlStringGet
On Mon, Jun 24, 2019 at 10:08 AM Alan Carroll <
solidwallofc...@verizonmedia.com> wrote:
rhaps
TSHttpTxnEffectiveUrlStringGet() is the best option. It is, of course, not
documented. Yay. Let me fix that.
On Fri, Jun 21, 2019 at 12:09 PM Alan Carroll <
solidwallofc...@verizonmedia.com> wrote:
> Yes, it's a problem that TSIOBufferReaderRead doesn't exist yet. What you
>> should do i
See if this helps - among other things it has a check list of issues to
check.
https://www.dropbox.com/sh/h7erczfbt8ug8kn/AADJAqNz_xizurIHE6hx8Q8ka
This is available from the wiki, under "Presentations", back from 2013.
On Sun, Jun 23, 2019 at 11:54 PM Dk Jack wrote:
> Hi Susan,
> yes, I've enab
>
> Yes, it's a problem that TSIOBufferReaderRead doesn't exist yet. What you
> should do is
>
TSIOBufferBlock block = TSIOBufferStart(iobuff);
char const* text = TSIOBufferBlockReadStart(block);
text now points at the URL string. For the length you can use
TSUrlLengthGet() or TSIOBufferReadAvail
There's TSUrlStringGet(), which unfortunately returns an allocated buffer.
Internally there is url_string_get_buff but it's apparently not accessible
from the C API. I should fix that.
On Fri, Jun 21, 2019 at 11:21 AM Alan Carroll <
solidwallofc...@verizonmedia.com> wrote:
>
Does TSUrlPrint not work for you? If you set up the TSIOBuffer to have a
large block size (say >= 128K) it should fit in a single block. We also
might want to push on adding TSIOBufferReaderRead() which would make that
easier as well.
On Fri, Jun 21, 2019 at 11:11 AM Eric Friedrich -X (efriedri -
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
> >>>> compare. I had put up a PR to simply change the behavior of
> > >>>> TSHttpTxnEffectiveUrlStringGet() but it was pocket vetoed by lack of
> > >>>> reviews.
> > >>>>
> > >>>> On Tue, Jun 11, 2019 at 12:03
The issue is, what is the correct normalization to perform? If that's
non-trivial, there's an argument for embedding that in the API rather than
requiring every plugin to hand roll it. It would be the same reason
`realpath` exists.
? Nobody else seems to care.
On Thu, May 2, 2019 at 9:25 AM Walt Karas
wrote:
> 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
meone has to shepherd that and start working on it. If not, I think we
> should drop all Doxygen in favor of just Sphinx. Unless Sphinx and Doxygen
> work together in some way that is above my pay grade ?
>
> — Leif
>
> Found this: https://breathe.readthedocs.io/en/latest/
>
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
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
>
As always, these are my personal notes and views. Others are actively
encouraged to do their own write ups and share them with the community.
https://solidwallofcode.github.io/notes/ATS-2019-Spring-Summit.en.html
Well, there would be two instances of ATS running, one as the "server" and
another as the test object. I think the bigger problem is that your testing
is much less reliable, since errors could get dropped between the two
instances of the same software, or be hard to track down. You get better
resul
This could enable a significant speed up for debug tags. One point is that
when the debug tag string is set, at that point the debug objects could be
updated to the correct state according to the debug tag string, rather than
checking it every time a debug message is logged.
I have to ask, why is
1 - 100 of 391 matches
Mail list logo
