Heikki Hannikainen created TS-2271:
--------------------------------------
Summary: Threaded plugin support with 3rd party libraries
Key: TS-2271
URL: https://issues.apache.org/jira/browse/TS-2271
Project: Traffic Server
Issue Type: Wish
Components: Plugins
Reporter: Heikki Hannikainen
We have created an ATS plugin which links to a library (an existing one which
is widely deployed in our other products). That library *creates threads* and
*links with openssl*. It's not an option at this point to rework that library
to use ATS threading functions.
The library will, in the end, call a callback function provided by our ATS
plugin. That call happens from a thread created by the library (outside TS and
plugin code). That callback function will then re-enable a transaction.
There are two problems:
# The library creates threads, and then calls openssl in those threads, and
openssl in turn calls mutex/thread id functions provided by ATS
(*SSL_pthreads_thread_id*, *SSL_locking_callback*). The functions provided by
ATS bail out if they don't know about the threads of the 3rd-party library.
# The callback function called by the library needs to re-enable a transaction.
The *TSHttpTxnReenable* API function bails out if called from a thread created
by the 3rd-party library.
To work around the OpenSSL-in-threads issue I changed the callbacks to use
regular pthread functions directly.
[https://github.com/hessu/trafficserver/commit/34b8455518a3e8093d935412c03cfdd3cb5ea398]
To re-enable transactions I made *TSHttpTxnReenableFromThread* which doesn't
try to look up an EThread. That would fail and the server would quit.
https://github.com/hessu/trafficserver/commit/0038e9ff1584513fdf8dc96bdd7b2fe12f046fe3
How does the ATS project feel about this use case (plugin with library which
uses threads)? Should ATS support it directly somehow?
I understand that the requirement might be pretty rare, and that the patches
are not something that should go in ATS as they are (especially the SSL
threading callbacks, it's now a bunch of almost-duplicate code). I'm just
publishing them to describe the workarounds and help discussion. We can live
with a fork with 3 patches on top.
I'd also be happy to hear about better workarounds. TSHttpTxnReenableFromThread
appears to have a measurable latency (~10ms).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
