-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Unregister runtime artifacts #2485
Comments
like a garbage collector?.
|
Tip: After removing the artifact, make sure the extension point also remove it from cache/rebuild the cache e.g. Routing table watches the view of controller, make sure it refresh the cache when controller goes. Suggestion: The scope of this story is too big, we can have a spike for all artifacts and figure out the scope of unregistering them. |
We need to delete all references to the artifact we want to remove, so that the garbage collector can reclaim the memory used by that artifact.
Yes, they should close their connections as part of the unregistering workflow.
I think that's something we need to find out, probably in a spike story. |
This should leverage the lifecycle support mentioned in : #1928 |
Created #2619 for the spike. |
This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the |
This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the |
This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the |
When discovering & defining models at run-time (see #2484), it's often important to allow applications to remove artifacts that are no longer used.
In LoopBack 3.x, we provide the following API:
The situation is more complex in LB4, because there are multiple artifacts involved in exposing a data table/collection via REST API:
Acceptance criteria
Application
-level API for removing the following artifacts:This should include artifacts created automatically by the infrastructure implemented in From model definition to REST API with no custom repository/controller classes #2036, Spike: From datasource config to Service REST API with no proxy/controller classes #2481, [EPIC] From relation definition to REST API with auto-generated repository/controller classes #2483 and possibly other related stories.
A stress-test application that can be executed in a memory profiler to verify that no memory is leaked when an artifact is unregistered. The application should implement define+unregister scenarios to cover all different artifact types we support.
Should have: an automated test invoked as part of
npm test
that will run the stress-test application created above in a memory profiler and verify that we are not leaking any memory. Alternatively, verify this fact manually and create a follow-up story to implement an automated check.The text was updated successfully, but these errors were encountered: