[jira] [Created] (TS-2271) Threaded plugin support with 3rd party libraries

["Heikki Hannikainen (JIRA)" <ji...@apache.org>]

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)