-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Apologies in advance if I'm overthinking this! I think there are two issues to work on:
error messages scoped to multiple requests?
If error messages are scoped to a fluxion context (e.g., here) that might mean that with many requests (using the same context) when we call GetErrMsg:
fluxion-go/pkg/fluxcli/reapi_cli.go
Lines 298 to 302 in bbe5b38
// GetErrMsg returns a string error message from the resource api | |
func (cli *ReapiClient) GetErrMsg() string { | |
errmsg := C.reapi_cli_get_err_msg((*C.struct_reapi_cli_ctx)(cli.ctx)) | |
return C.GoString(errmsg) | |
} |
we can't be certain we are only getting back messages from a call we just did (or we might miss some). This isn't an urgent issue, because we can either do a "best effort" and get/clear the messages to print to the console for informational purposes (and assume there could be some race conditions with a high throughput of jobs) but it would be something to consider a strategy for scoping error messages to specific requests.
grpc connection should be done once?
I think we are creating a new grpc connection for each match request, e.g., here and I'm wondering if there is supposed to ideally be one connection that is re-used (see here).
I'm working on an integration with the fluxion service, and using a client interface that creates the connection once, which isn't something I've tried beyond simple examples, so I can try that in a more orchestrated context and report back.
Ping @cmisale and @milroy for thoughts! Apologies for all the questions - I'm working on these two projects at once and have open PRs and am going to put in some fixes and want to make sure I get the details right. If it's the case that we should have one grpc connection that is used across the lifecycle of some running server, we might want to tweak the current fluence (flux-k8s) to do that too.