Hi Walt, A1: The `TransformVConnection` is a pipe/chain which consisted by multiple `INKVConnInternal` and a `TransformTerminus` at the end. The Transform Plugin is a Continuation which will be called back by `INKVConnInternal`.
At least one transform plugin hooked into a HttpSM, 1. The TXN may closed before any transform plugin be triggered. 2. The TXN closed after transformVC closed. The `HttpSM` always perform a check at https://github.com/apache/trafficserver/blob/d9f647ca7c15d0eb4687fa59706ab246f49ece1b/proxy/http/HttpSM.cc#L6898 which handle the 1st situation. The `TransformVConnection` will be closed by `transform_cleanup()`. For the 2nd situation, the `TransformVConnection` will be closed by calling `TransformVConnection::do_io_close()`when it finished. https://github.com/apache/trafficserver/blob/d9f647ca7c15d0eb4687fa59706ab246f49ece1b/proxy/Transform.cc#L451 The `TransformVConnection::do_io_close()` will close the 1st `INKVConnInternal` by calling `INKVConnInternal::do_io_close()`. https://github.com/apache/trafficserver/blob/d9f647ca7c15d0eb4687fa59706ab246f49ece1b/src/traffic_server/InkAPI.cc#L1210 The `INKVConnInternal::do_io_close()` continues to close the next `INKVConnInternal` by calling `m_output_vc->do_io_close()`, and calls the Transform Plugin asynchronously. It means that the Transform plugin should check if `INKVConnInternal` has been closed first. (https://github.com/apache/trafficserver/blob/d9f647ca7c15d0eb4687fa59706ab246f49ece1b/example/plugins/c-api/null_transform/null_transform.c#L192) It is its responsibility to clean up the resources of the plugin after `TransformVConnection` is closed. A2: All `INKVConnInternal` created by Transform Plugin share the mutex from HttpSM. The `TransformVConnection` is a one way tunnel chain, HttpTunnel writes data into `TransformVConnection` and read from `TransformTerminus`. It means the Continuation of VIO is HttpTunnel which share the mutex from HttpSM too. It is safe when you call back to the VIO of `INKVConnInternal` inside the Transform Plugin because the mutex of Transform Plugin and/or HttpSM get locked already. - Oknet Xu Walt Karas <wka...@verizonmedia.com.invalid> 于2020年3月7日周六 上午11:18写道： > > Some questions about null_transform.c (the mother of all transform plugins). > > Is this, > https://github.com/apache/trafficserver/blob/d9f647ca7c15d0eb4687fa59706ab246f49ece1b/example/plugins/c-api/null_transform/null_transform.c#L192 > , really a reliable way to make sure all transform-related resources get > cleaned up, in both success and failure cases. Seem like there would be an > explicit VCONN_CLOSE event. Perhaps we should just use TXN_CLOSE to > reliably do cleanup? > > There are 3 TSContCall() calls on the continuation returned by > TSVConnWriteVIOGet(). TSContCall() does a try-lock on the continuation's > mutex, and a release assert if the try-lock fails ( > https://github.com/apache/trafficserver/blob/d9f647ca7c15d0eb4687fa59706ab246f49ece1b/src/traffic_server/InkAPI.cc#L4792 > ). What logic prevents this release assert from being triggered? -- - Oknet Xu
