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