[
https://issues.apache.org/jira/browse/TS-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792988#comment-13792988
]
Heikki Hannikainen commented on TS-2271:
----------------------------------------
If only it was the *plugin* which creates the threads, I would have surely used
the TS-provided TSThread functions, and all would be good. But as I wrote
above, the threads are created by a *library* which is also used in a number of
other products - the library is not written for TS specifically - so it won't
be calling TS thread API functions.
Also, I'm not sure how you'd go about loading two different copies of the same
OpenSSL shared library, which define the same symbols, in the same process. Can
you give me a hint on that?
The main problem is that my plugin does not link OpenSSL, it actually links the
previously mentioned library which then links OpenSSL. I get that library in
binary form and since it is widely deployed, doing ATS-specific modifications
in there could be tricky. Maintaining our ATS fork with these little patches
seems like a safer and easier option at this point.
I can ensure our ATS binary is built with OpenSSL, it's just a flag in my ATS
debian packaging rules.
It seems to me that the issues can not be worked around in my plugin - they
need to be worked around in either the library the plugin links with, which is
mostly used by deployed applications which are not ATS, *or* in the ATS code
(which I did, since I had the ATS source code in hand).
> 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)
