[
https://issues.apache.org/jira/browse/TS-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792990#comment-13792990
]
Heikki Hannikainen commented on TS-2271:
----------------------------------------
That said, I totally understand if you prefer to keep threads strictly to
ATS-managed threads, we'll just live with our own private branch then. I mainly
wanted to push the patches for you to see, and maybe for someone to utilize if
they run into the same issue. I'm not claiming they'd be good for inclusion in
ATS as-is.
> 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)
