+openresty
多谢agent帮忙看代码。
>> 1. 你的数据通信局限于单个 nginx worker 进程内部，所以当配置了多个 nginx worker 时，就会出现问题。
由于目前是PoC, 仅仅为了尽快跑通，然后完善。这个得用共享内存的 :-p
>> 2. 你没有在 ngx_http_pubsub_body_handler 中检查 lcf->latest_subscriber 为空的情形。
>> 5. subscriber 的最后一次 ngx_http_finalize_request 调用应当由 publisher 来完成（即在
ngx_http_pubsub_body_handler 函数中输出数据后立即调用），而不是推迟到下一个 subscriber.
这中间的延时可能很大，在此期间你的 subscriber 连接存在泄漏的风险（如果客户端没有主动关闭连接的话）。
多谢，latest_subscriber也是 PoC的做法。之后会支持多对多的pub sub，而PoC中仅支持一个subscriber，第二个连上来就会踢掉第一个。这样的话，是不是不应该由publisher主动断开呢？在设计中，有两种subscriber需要断开的情况：
(a) subscriber主动断开，不再需要订阅
(b) subscriber读的太慢，导致内部缓冲区不足，被强行踢掉
对于(a), 就涉及到你说的第3点了
>> 3. 你没有及时响应客户端 subscriber 提前断开连接的情形（比如客户端超时）。
本来我以为这个不需要自己处理。如果需要相应，如何做到呢？
>> 4. subscriber 在自增 r->main->count 后返回 NGX_DONE 更合适一些。
恩，我看到在ngx_http_finalize_request中NGX_DONE会更早进入ngx_finalize_connection，而NGX_OK会多走一些。他们俩设计上是有什么区别呢？
>> 另外，你的 lcf 在创建时可以直接使用 ngx_pcalloc 而不是分开写成 ngx_palloc 与 ngx_memzero.
多谢提醒！
>> 如何充分测试你的代码是很重要的问题。可以考虑 no-pool 补丁、valgrind、mockeagain 还有 Test::Nginx 这些工具。
多谢，搞定基本问题后我回去研究一下测试工具。
LS
2013/3/11 agentzh
<age...@gmail.com>
Hello!
2013/3/9 laye:
貌似有几个比较大的问题：
1. 你的数据通信局限于单个 nginx worker 进程内部，所以当配置了多个 nginx worker 时，就会出现问题。
2. 你没有在 ngx_http_pubsub_body_handler 中检查 lcf->latest_subscriber 为空的情形。
3. 你没有及时响应客户端 subscriber 提前断开连接的情形（比如客户端超时）。
4. subscriber 在自增 r->main->count 后返回 NGX_DONE 更合适一些。
5. subscriber 的最后一次 ngx_http_finalize_request 调用应当由 publisher 来完成（即在
ngx_http_pubsub_body_handler 函数中输出数据后立即调用），而不是推迟到下一个 subscriber.
这中间的延时可能很大，在此期间你的 subscriber 连接存在泄漏的风险（如果客户端没有主动关闭连接的话）。
另外，你的 lcf 在创建时可以直接使用 ngx_pcalloc 而不是分开写成 ngx_palloc 与 ngx_memzero.
如何充分测试你的代码是很重要的问题。可以考虑 no-pool 补丁、valgrind、mockeagain 还有 Test::Nginx 这些工具。
最后欢迎到 openresty 中文邮件列表中交流这样的问题：https://groups.google.com/group/openresty
Best regards,
-agentzh
