-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add serializer-cache size limit to avoid Metaspace issues from caching Serializers #3311
Comments
There is nothing specific, except that I think there were some concrete talks about exposing cache sizes through builders -- so at least you could limit maximum number -- and I think also ability to specify custom cache implementations. Latter would then allow more advanced handling if cache could determine how to clear references to obsolete instances. |
Is this consideration being made for the codehaus jackson implementation? There is a serializercache there as well, which will lead to pretty much the same impact. |
@cjimenez1 The codehaus implementation is Jackson 1.x and hasn't seen a release for 8 years. You should upgrade to Jackson 2. |
The cache limit hasn't been backported to Jackson 2 either. Could that be considered as well? |
Yeah, Jackson 1.x has not been modified in literally years and I have no way to actually publish any of jars even if I did change the copy Github has. So issues it has will remain issues unless someone forks the build (or implements proper Maven build). As to 2.x, sure, PRs welcome! I do not necessarily have time to make changes but can usually help others get PRs merged. |
@pjfanning @ben-manes I think I'll try to do this (basically backport of #1994) |
I know this is a topic that has been discussed before (#489 & #1905), but it has been a few years so I wanted to open the discussion again.
I see that there are changes coming in 3.0 to limit the size of the serializer cache to 4000 (#1994). Are there any other plans to allow tuning this size, adding a 'super flush', or letting the consumer provide the cache implementation (ex. with weak references)?
Our app servers have a lot of
DelegatingClassLoaders
sticking around due to reflection methods being stored in theSerializerCache
(like_accessorMethod
inBeanPropertyWriter
) and it would be great if we had more control over the caching strategy so metaspace doesn't grow unbounded.The text was updated successfully, but these errors were encountered: