Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: (and question) error messages associated with specific request #14

Open
vsoch opened this issue Jan 5, 2025 · 2 comments
Open

Comments

@vsoch
Copy link
Member

vsoch commented Jan 5, 2025

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:

// 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.

@cmisale
Copy link
Contributor

cmisale commented Jan 7, 2025

I think that's totally fine to reuse one connection.. I don't see any downsides to it.
I remember I tried doing that but something was off, and I switched back to a new connection every time.
Sure that my knowledge of programming such things was different, so I might just have made mistakes on my own

@vsoch
Copy link
Member Author

vsoch commented Jan 10, 2025

Sure that my knowledge of programming such things was different, so I might just have made mistakes on my own

@cmisale I don't think I'd call this a mistake - I've been testing the two designs this week, and although the single connection is hypothetically more "efficient" it also seems to be more flaky (it doesn't persist sometimes). I think likely you came to this decision after observing something similar, and I would not call that a mistake but a reasonable choice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants