But these are not inherently purposes. I could decide there needed to
be a special thread to execute all functions with the letter r in the
name. But that would arbitrary, not an actual purpose. Generally
speaking, in an event driven system, you only need different threads
for multiple cores and
I thought the purpose of the different threads in ATS was pretty clear.
There are many threads to handle requests (1.5x the number of HT cores).
8 threads to handle disk I/O (cache).
2-3 threads to do miscellaneous tasks.
2-3 threads to handle logging.
One thread for each port which you want to lis
Unfortunately that's like many of our explanations, too open-ended to
be very helpful when someone sits down to write some code.
On Wed, Oct 10, 2018 at 2:26 PM Alan Carroll
wrote:
>
> To accomodate different behavior requirements on the continuations
> scheduled on a thread in that pool. E.g. non
Currently there is a records.config entry,
proxy.config.ssl.client.verify.server,
which can be set to 0 (no verify), 1 (strict verify), or 2 (check but only
log).
This global setting can be overridden in the ssl_server_name.yaml file
using the verify_origin_server parameter which can be set to NO
To accomodate different behavior requirements on the continuations
scheduled on a thread in that pool. E.g. non-blocking vs. blocking for one.
On Wed, Oct 10, 2018 at 2:25 PM Walt Karas wrote:
> Why do we need thread pools?
> On Wed, Oct 10, 2018 at 2:17 PM Alan Carroll
> wrote:
> >
> > Yes, th
Why do we need thread pools?
On Wed, Oct 10, 2018 at 2:17 PM Alan Carroll
wrote:
>
> Yes, that's not well developed. However, it is the reason TS mutexes are
> shareable. If there is a resource shared between continuations the TS
> approach is to have those continuations share the same mutex leadi
Yes, that's not well developed. However, it is the reason TS mutexes are
shareable. If there is a resource shared between continuations the TS
approach is to have those continuations share the same mutex leading to
natural rescheduling for lock contention. In addition, that TS mutexes are
recusive
On Wed, Oct 10, 2018 at 1:35 PM Leif Hedstrom wrote:
>
>
>
> > On Oct 10, 2018, at 11:31 AM, Walt Karas wrote:
> >
> > It seems like ATS does not have a coherent strategy for threading and
> > mutexes.
> >
> > One pure strategy is event driven with one thread per core (processing
> > an event qu
> On Oct 10, 2018, at 11:31 AM, Walt Karas wrote:
>
> It seems like ATS does not have a coherent strategy for threading and mutexes.
>
> One pure strategy is event driven with one thread per core (processing
> an event queue). Share data structures are owned by a particular core
> (also help
It seems like ATS does not have a coherent strategy for threading and mutexes.
One pure strategy is event driven with one thread per core (processing
an event queue). Share data structures are owned by a particular core
(also helps with NUMA), and events that want to access the data
structure are
Thanks Susan!
On Wed, Oct 10, 2018 at 7:50 AM Susan Hinrichs
wrote:
> Digging through the ATS and the openssl code, the
> proxy.confg.ssl.session_cache.timeout always has effect regardless of
> whether we are using the openssl cache (proxy.config.ssl.session_cache ==
> 1) or the Traffic Server ca
I was going through the code in Diags.cc and I saw that if debug logging is
on, ATS calls vfprintf in the thread that handles the client request.
E.g.
https://github.com/apache/trafficserver/blob/master/src/tscore/Diags.cc#L301
Is this a good idea?
Or is the assumption that if you have turned on d
I think Alan is referring to the below code.
It's a try lock, so if it doesn't succeed it's just rescheduled for later.
void
EThread::process_event(Event *e, int calling_code)
{
ink_assert((!e->in_the_prot_queue && !e->in_the_priority_queue));
MUTEX_TRY_LOCK_FOR(lock, e->mutex, this, e->contin
Alan also mentioned that these hooks might be useful to implement outbound
proxy protocol. However, at the moment, these hooks are only in place for
TLS connections. Would probably need to generalize them to deal with proxy
protocol over non-TLS connections.
On Wed, Oct 10, 2018 at 11:06 AM Susa
Sure. I don't have our specific use case in the PR. Only a test
(ssl_hook_test.cc) to exercise the underlying hooks.
Our goal is to allow a plugin to arbitrarily change some config selected
attribute of an outgoing SSL object before Traffic Server sends the Client
Hello. For example, change the
Digging through the ATS and the openssl code, the
proxy.confg.ssl.session_cache.timeout always has effect regardless of
whether we are using the openssl cache (proxy.config.ssl.session_cache ==
1) or the Traffic Server cache (proxy.config.ssl.session_cache == 2). In
either case SSL_CTX_set_timeout
16 matches
Mail list logo
