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

["James Peach (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792727#comment-13792727 ] 

James Peach commented on TS-2271:
---------------------------------

The TSThreadInit() and TSThreadDestroy() APIs are provided for plugins to integrate their own threads with the Traffic Server threading model. When the plugin spawns a thread, the first thing that thread should do is call TSThreadDestroy().

As for the OpenSSL callbacks, I think that you need to examine your linking options to ensure that your plugin links it's own, independent copy of OpenSSL (including static data). There's no guarantee that Traffic Server links to OpenSSL and there's no guarantee that Traffic Server configures the OpenSSL runtime in a way that works for your plugin. If there's no way to give the plugin an independent copy, I'd be happy to discuss further, but that's my initial reaction ;)

> 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)