[GitHub] [apisix-go-plugin-runner] Belyenochi commented on issue #34: request help: Introduce context to run plugin
Belyenochi commented on issue #34: URL: https://github.com/apache/apisix-go-plugin-runner/issues/34#issuecomment-1038125204 > the timer will be reset Sorry, I didn't make it clear, I don't understand whether the timer on the Nginx side can be reset by the client -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [apisix-go-plugin-runner] Belyenochi commented on issue #34: request help: Introduce context to run plugin
Belyenochi commented on issue #34: URL: https://github.com/apache/apisix-go-plugin-runner/issues/34#issuecomment-1038125204 > the timer will be reset Sorry, I didn't make it clear, I don't understand whether the timer on the Nginx side can be reset by the client -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [apisix-go-plugin-runner] Belyenochi commented on issue #34: request help: Introduce context to run plugin
Belyenochi commented on issue #34: URL: https://github.com/apache/apisix-go-plugin-runner/issues/34#issuecomment-1035929748 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [apisix-go-plugin-runner] Belyenochi commented on issue #34: request help: Introduce context to run plugin
Belyenochi commented on issue #34: URL: https://github.com/apache/apisix-go-plugin-runner/issues/34#issuecomment-1035851566 > Thanks for your design. My original thought is simpler: we can add a method in the Request to return a Context. It works like the one from the standard library: https://pkg.go.dev/net/http#Request.Context. > > People can fetch it only when they need the Context. And the timeout of Context is slightly smaller than 60s so people can still break the execution with a custom response before the actual timeout. > > There is a tricky place: the timeout of Nginx is per-operation, so when we communicate with Nginx again in > > https://github.com/apache/apisix-go-plugin-runner/blob/6bb1c4bd98ec374638af7ed02931e0efb2604044/internal/http/request.go#L326 > > > the timer will be reset. Maybe we can handle this in a separate PR. There is a doubt, although we have added a timeout request to the Request, but if the plugin written by the user does not handle this context, it will still cause a timeout -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [apisix-go-plugin-runner] Belyenochi commented on issue #34: request help: Introduce context to run plugin
Belyenochi commented on issue #34: URL: https://github.com/apache/apisix-go-plugin-runner/issues/34#issuecomment-1034548435 > Thanks for your design. My original thought is simpler: we can add a method in the Request to return a Context. It works like the one from the standard library: https://pkg.go.dev/net/http#Request.Context. > > People can fetch it only when they need the Context. And the timeout of Context is slightly smaller than 60s so people can still break the execution with a custom response before the actual timeout. > > There is a tricky place: the timeout of Nginx is per-operation, so when we communicate with Nginx again in > > https://github.com/apache/apisix-go-plugin-runner/blob/6bb1c4bd98ec374638af7ed02931e0efb2604044/internal/http/request.go#L326 > > > the timer will be reset. Maybe we can handle this in a separate PR. I will submit a PR asap -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [apisix-go-plugin-runner] Belyenochi commented on issue #34: request help: Introduce context to run plugin
Belyenochi commented on issue #34: URL: https://github.com/apache/apisix-go-plugin-runner/issues/34#issuecomment-1032312691 Environment - APISIX Go Plugin Runner's version: 0.2.0 - APISIX version: 2.12.0 - Go version: go1.17.2 darwin/amd64 - OS (cmd: uname -a): Darwin MacBook-Pro.local 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64 My idea is the following in the internal/server/server.go file ``` go func() { for { conn, err := l.Accept() select { case <-done: // don't report the "use of closed network connection" error when the server // is exiting. return default: } if err != nil { log.Errorf("accept: %s", err) continue } go func() { ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() isExit := make(chan bool) go handleConn(conn, isExit) select { case <-isExit: fmt.Println("exit") case <-ctx.Done(): builder := util.GetBuilder() hrc.RespStart(builder) res := hrc.RespEnd(builder) builder.Finish(res) out := builder.FinishedBytes() n, err := conn.Write(out) if err != nil { util.WriteErr(n, err) break } fmt.Println("hello") } }() } }() sig := <-quit log.Warnf("server receive %s and exit", sig.String()) close(done) } ``` But there are two problems with this scheme First, there is no way to control APISIX's return to the user at this time (maybe I should take a look at ext-plugin-proto) Second, there is no fine-grained control over the operation of a single plugin, and the serialization between plugins may cause some plugins to be starved all the time (should we allow parallelism between pugins) 中文版本: 代码如上 这个方案存在两个问题 第一没法控制APISIX此时对于用户的返回(或许我应该去看看ext-plugin-proto) 第二没法细粒度的控制单个plugin运行,plugin之间依旧串行可能会引起部分plugin一直饥饿(我们是否应该允许pugin之间并行) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [apisix-go-plugin-runner] Belyenochi commented on issue #34: request help: Introduce context to run plugin
Belyenochi commented on issue #34: URL: https://github.com/apache/apisix-go-plugin-runner/issues/34#issuecomment-1024823046 pls assigned to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org