0x161e-swei commented on PR #176: URL: https://github.com/apache/openwhisk-runtime-go/pull/176#issuecomment-1254517757
> Did you experience an issue with it? Can you show the bug and let me replicate it? I experienced a bug when I enable concurrent actions. I was using helm to deploy OW (https://github.com/apache/openwhisk-deploy-kube) with a yaml config: ```yaml whisk: ... limits: actions: concurrency: max: 100 ... ``` And I created action using `wsk -i action create hello hello.go --main hello --docker openwhisk/action-golang-v1.18:nightly --web true` and inside `hello.go` I have ``` go package main func Hello(obj map[string]interface{}) map[string]interface{} { msg := make(map[string]interface{}) msg["body"] = "Hello World!" return msg } ``` I am using [wrk2](https://github.com/giltene/wrk2) to drive the load: `wrk -t 1 -c 20 -R 500 -d 10s https://127.0.0.1:31001/api/v1/web/guest/default/hello.http` The above command opens 20 connections and issues to total load of 500 requests per second. [runHandler.go:90](https://github.com/apache/openwhisk-runtime-go/blob/master/openwhisk/runHandler.go#L90) gets executed from time to time as the response from line 72 `response, err := ap.theExecutor.Interact(body)` returns `{"body": "Hello World!"}\n{"body": "Hello World!"}\n` >"However the concurrency is already handled by the goroutines that > serve each of the HTTP requests." No. The goroutine there is used only to avoid a blocking behaviour when the underlying processs does not answer becuause the function crashed or is taking too much time. Sorry about the confusion, I was referring to the goroutines that are created in serving the HTTP requests in the net.http package [here](https://github.com/golang/go/blob/master/src/net/http/server.go#L3072). So there will be one goroutine running the `runHandler` function for each of the HTTP request the proxy receives. This PR is not aiming to enable concurrent execution of the actions, but it tries to improve the safety of concurrent processing of the activataions. The actions are still serially executed by one executor process. Concurrent processing of the activations (e.g. parsing request header and body) improves performance as otherwise a second request can only be processed/parsed after the first request completes. I agree with the "out of sync" challenge: goroutine-1 for the http-req-1 could have written to the stdout of the "action process" first, and spawns up goroutine-3 waiting for response. And goroutine-2 for the http-req-2 writes the request body to the stdout of the action process and spawns up goroutine-4 waiting for response. It is possible goroutine-4 gets scheduled before goroutine-3 and actually reads back the response for http-req-1. So Perhaps a mutex wrapping the write line and read line operation in the `executor.Interact` could solve this? Thanks again! -- 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: issues-unsubscr...@openwhisk.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
