You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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
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!
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
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.
The text was updated successfully, but these errors were encountered: