是不是可以做一些增强 nginx upstream 部分的功能，例如在保证处理效率的前提下又能在 lua 处理响应的 body，例如管理对上游的链接池等。

    282441848
    多谢报告，这里应该只需要很小的改动，应该很快就可以修复更新到 opm

        firlas
        你是希望在 timer 里面使用 ngx.location.capture 么？
        这个理论上也可以搞，不过可能相对改动大一些。
        timer 里面选择使用 location.capture 而不使用 cosocket 是出于什么目的呢

        还有其他希望在 timer 里面支持的么？

          imilli
          哈哈，有点多，也欢迎大家一起来贡献，齐头并进发展更快

              doujiang24 目前只遇到ngx.location.capture这个限制.

              原因是原本content_by_lua阶段的逻辑使用了很多capture, 因为考虑capture比完整请求要轻量.
              随着项目发展, 这些逻辑其中一些要跑在timer里了, timer不支持capture, 只好到处去ngx.get_phase()区分.

              看文档时我在想, 既然timer已经"will take one (fake) connection"了, 那不能干脆 take one (fake) request么, 然后timer逻辑发生在这个fake request的content_by阶段, 能使用content阶段所有功能.

              毕竟没看过源码, 很可能想的过于简单.

                feng
                这个 PR 只是完成 shdict 在 stream 和 http 之间共享呢
                完全的合并两个 lua vm，这是另外一个话题，其实合并也不太好

                    firlas
                    确实 timer 还不是完整的请求，没有 content phase 这个概念了呢，执行上也没有了呢
                    要支持的话，还是有一些改动量的，当然也不是要引入 content phase 才可以，有其他路子

                        tweyseo 这个功能太有用.

                        如果考虑到nginx的设计, 请求到所有worker这个改动太大的话, 那一个可以广播自定义数据到所有worker的api怎样

                          tanjinhua 这个我已经用来代替kong的resty-event用在mlcache里了，算上编译过程，整个不算简单易用。要是OR本身可以支持，比如，直接配置listen 9527 BCST;，然后不管外部还是内部，只要是到这个端口的数据都是给所有worker都处理的，这样岂不是更好。

                            tweyseo 是的，系统本身自带肯定更好的，也是比较基本和使用的功能了；但是这个估计要修改 nginx 本身，工作量会比较大的。

                                6 days later
                                6 days later

                                jils2013
                                这个工程量也有一些，需要加入有 upstream zone 的概念，与此同时，搞了 keepalived_timeout 的支持，一直一起搞的也有 pool_size 的支持了

                                    6 days later