-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Should JsonSerializerOptions have bounds in its cache size? #35084
Comments
Tagging subscribers to this area: @jozkee |
Typically there are a finite number of types in an app that are serialized so it isn't an issue. But dynamic type generation plus serialization could create caching issues. In Newtonsoft.Json the DefaultContractResolver holds the cache. Because it is an instance type it is possible to create a new contract resolver for serialization of dynamic types and then throw it away. |
This is also important in the context of assembly unloading |
As @JamesNK points out the existing caches are all rooted to a given Type that was previously (de)serialized. Currently it is not possible to "unload" a given Type from the serialized, but that could certainly be done. For example, a To unload all Types for a given assembly a |
I understand the implications, I was pointing out assembly unloading as another angle to keep in mind. |
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process. This process is part of the experimental issue cleanup initiative we are currently trialing in a limited number of areas. Please share any feedback you might have in the linked issue. |
This issue will now be closed since it had been marked |
What prevents the caches inside of this instance from growing unbounded? Do we need to place a limit on the size of the cache, making it an LRU cache or something like that?
Originally posted by @stephentoub in #35040 (comment)
cc @steveharter @layomia
The text was updated successfully, but these errors were encountered: