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

Make KE Runtimes better deal with Knowledge Directory being unavailable. #478

Open
bnouwt opened this issue Feb 13, 2024 · 2 comments
Open

Comments

@bnouwt
Copy link
Collaborator

bnouwt commented Feb 13, 2024

When stopping the knowledge-directory while running the unreachable-runtimes example, the KER gives a lot of errors and seems to not update its OtherKnowledgeBaseStore. Therefore it keeps trying to send messages to KBs that it no longer knows. What behavior would we expect here? Do we want to KERs to keep exchanging messages while the knowledge-directory is unavailable? Because they can easily do that. Or do we want the KERs to remove all RemoteKerConnection's and no longer be able to send any messages to any remote KER?

Also, when the knowledge-directory becomes available again, it does not recover properly, but it remains in the state of not being able to send messages to KBs in other KERs.

@bnouwt
Copy link
Collaborator Author

bnouwt commented Feb 13, 2024

Eventually the unreachable-runtimes example seems to recover fully, but it seems to take a while.

@bnouwt
Copy link
Collaborator Author

bnouwt commented Feb 13, 2024

Maybe introduce the following additional Inter-KER REST operations:

  • remove all RemoteKerConnection's from the KER and empty the OtherKnowledgeBase. This way, we can temporarily shut down the knowledge-directory and then remove RemoteKerConnection's.
  • add mechanism to manage a list of KERs to ignore by a particular KER. But then this ignored KER should also ignore all other KERs, otherwise it will keep sending messages to them.

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

1 participant