Generally speaking, we schedule Continuations for 2 main use cases.
1) Make async sideways calls
2) Some offloading of heavy CPU work (such as encrypting/decrypting a token etc)
For (1) we don't use separate thread pools and just schedule them on the Net
threads. As these involve i/o, it's more
Yes, that's a problem. One of the many things on my list.
On Fri, Mar 27, 2020 at 12:42 PM David Calavera
wrote:
> Something I find challenging about TSContScheduleOnPool and others is that
> there is no much documentation about good practices to configure thread
> pools. For example the only do
Something I find challenging about TSContScheduleOnPool and others is that
there is no much documentation about good practices to configure thread
pools. For example the only documentation I found about task threads only
says that you must have at least 1 task thread:
https://docs.trafficserver.ap
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:
I was having problems with this too in a new plugin I was writing. I had
to make this small change to get it to work:
https://github.com/apache/trafficserver/pull/6489/files#diff-8c09c39a3b13e183ba1bfd1e590cfb21
I found that I had to use TSContScheduleOnPool() instead of
TSContSchedule().
On Thu
While investigating a core dump that we ran into during our ATS9 migration, we
discovered a couple of problems with the thread affinity changes and the
TSContSchedule API.
1) It looks like the API TSContSchedule() and TSContScheduleEvery() now don't
work unless TSContSetThreadAffinity() was call
