he
> > >>>>>> lack of
> > >>>>>> contention elsewhere, it wasn't worth the complexity.
> > >>>>>>
> > >>>>>> I think thread affinity is a better choice because no lock
> > contention
> &g
Sounds very interesting.
But what is the problem we're trying to solve here, I like the thread
affinity because it gives us head ache free concurrency in some cases, and
I'll bet that there is some code which doesn't have the proper continuation
mutexes because we know it runs on the same thread.An
Sounds very interesting.
But what is the problem we're trying to solve here, I like the thread
affinity because it gives us head ache free concurrency in some cases, and
I'll bet that there is some code which doesn't have the proper continuation
mutexes because we know it runs on the same thread.
I know for sure the forward proxy crowd is using those hooks as well :)
Tracking on a TCP level is better done with connection level hooks BTW.
On Fri, 12 Jul 2019, 06:51 Sudheer Vinukonda,
wrote:
> SSN_START and SSN_CLOSE hooks can be useful for tracking/managing session
> level attributes suc
The codebase of the microserver is easier to debug and less volatile than
ATS, you'd want the codebase on that side to be reliable.
We should also worry about subtly changing behaviour of the ATS origin
which would break the tests not so subtly I guess.
Making the origin a moving target might not b
Great...
This is exactly the location to do all the nasty stuff, this callback
happens before all the other callbacks and you should be able to setup some
stuff for the following callbacks.
@Susan : are there plans to make the client hello callback an async hook
for plugins? We were planning to d
On Thu, Aug 16, 2018, 20:39 Alan Carroll
wrote:
> "getting the TSEventThread from a vconn, txn, ssn instead of implicitly
> trusting that the current thread is relevant?"
>
> I'm not sure what this means. Those objects don't have threads explicitly
> associated, it's more implicit. If the code i
Adding to that, we might need have to look into this:
- getting the TSEventThread from a vconn, txn, ssn instead of implicitly
trusting that the current thread is relevant?
- moving a client vconn to a certain thread (we've seen that the thread
jumping in plugins can really kill performance with p
+1, we currently have it implemented but did not come around to make a pull
request and a proposal.
Some remarks, instead of current thread we should be able to schedule on an
arbitrary thread (*OnThread)
This can also improve performance by preventing thread jumping and provide
simpler concurren
Disregard, wrong mailinglist... Apologies
On Jan 21, 2018 00:48, "Kees Spoelstra" wrote:
I don't know, actually having an option to pull in the pre made pagespeed
automatic library would be great... But that could be done from one repo
also.
Compiling pagespeed or a plugin are
I don't know, actually having an option to pull in the pre made pagespeed
automatic library would be great... But that could be done from one repo
also.
Compiling pagespeed or a plugin are two completely different things in
compile time, complexity and dependencies.
Will we be moving ngx_pagespee
We had a PR for https://issues.apache.org/jira/browse/TS-5108 on master, on
which branch do we need to PR for 7.1.0. (7.0.x?)
-Original Message-
From: Leif Hedstrom [mailto:zw...@apache.org]
Sent: Wednesday, January 4, 2017 02:52
To: dev@trafficserver.apache.org
Subject: Branching for v7.
+1 ,but ideally we'd like to see
https://issues.apache.org/jira/browse/TS-5108 included, anything we can do to
make this happen?
-Original Message-
From: Phil Sorber [mailto:sor...@apache.org]
Sent: Tuesday, January 3, 2017 16:11
To: dev@trafficserver.apache.org
Subject: Re: [VOTE] Re
We are seeing some strange behavior in 6.2.0, which might be related to
TS-4387 and we did not see this in 6.1.x.
In the case of long running processing on a continuation we run into the
problem that a TSContSchedule for this continuation will be waiting for the
continuation to end.
If I re
14 matches
Mail list logo
