Hi,
I am trying to understand the ssl cache timeout in ATS. According to the
documentation for proxy.config.ssl.session_cache, a default value of 2 is
chosen if its not configured. For proxy.config.ssl.session_cache.timeout, a
default value of 0 is chosen, if its not configured which means ssl
cach
Hi all,
this questions keeps coming up frequently, most recently at the ATS Summit this
last week.
Q: Should I vote / comment even if I’m not a committer?
The answer is unequivocally: YES!
True, only votes are binding, but honestly, some of the most useful votes are
those from use
Hi all,
as presented and discussed at the ATS Summit, I’d like to propose a small, but
important, change to the LTS release process:
- We can make minor releases, with small, safe feature additions,
without resetting the LTS support timer.
What this means is that we can make e.g. an
I've browsed through the PR, and I see where you've used the proposed hooks in
ssl_hook_test.cc, but I am missing what the use case for these hooks would be.
Can you elaborate a bit?
Thanks,
Steven
On 10/9/18, 4:12 PM, "Susan Hinrichs" wrote:
I am proposing changes to enable a plugin to
By explicit continuation locking, I mean code like your example -
before();
TSMutexLock(mutex);
critical_section();
TSMutexUnlock(mutex);
after();
The call to TSMutexLock() is an explicit lock of the mutex. It address the
issue by noting that it rarely, if ever, comes up. However what you suggest
To what "explicit continuation locking" do you refer?
How does this address the issue that using TSMutexLock() or MutexLock
in a currently running continuation function (unnecessarily) blocks
all other events waiting in a thread event queue? Whereas the
inability to lock a continuation mutex caus
> On Oct 9, 2018, at 2:44 PM, Alan Carroll
> wrote:
>
> It's a bit more complex than that. One key thing is that if you schedule an
> event for a continuation, when the event handler is called the continuation
> mutex will be locked. Therefore it's rarely the case a plugin needs to lock
> its
It's a bit more complex than that. One key thing is that if you schedule an
event for a continuation, when the event handler is called the continuation
mutex will be locked. Therefore it's rarely the case a plugin needs to lock
its continuations explicitly. For that reason, simply scheduling handle
I am proposing changes to enable a plugin to access the outbound SSL object
and override elements as it likes before the outgoing TLS handhake
completes.
To acheive this, I have put up PR #4377, which adds the following hooks
* TS_VCONN_OUTBOUND_START_HOOK
* TS_VCONN_OUTBOUND_CLOSE_HOOK
These are
In TS, is it important to favor use of continuation mutexes to avoid
thread blocking. For example, should code like this:
before();
TSMutexLock(mutex);
critical_section();
TSMutexUnlock(mutex);
after();
be replaced with code like:
int contf_after(TSCont, TSEvent, void *)
{
after();
return
> On Oct 9, 2018, at 6:56 AM, Fieck, Brennan wrote:
>
> Idk if I get a vote, but +1
Of course you get a vote!! Honestly, everyone has a vote, don’t get hung up on
the “binding” votes or not. In fact, in many cases, getting votes from
non-committers / PMC members has a lot more value!
>
>
Idk if I get a vote, but +1
CentOS with 'elrepo' installed is capable of pulling the latest 3.4 release,
and Sphinx should work for anything between 3.4.1 and 3.6.x.
Be careful about building with 3.7, syntax highlighting doesn't work because
Pygments does things it shouldn't do that were disc
12 matches
Mail list logo
