Belyenochi edited a comment 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
```
// sample code
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)
}
}
}()
}
}()
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
