Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Add serializer-cache size limit to avoid Metaspace issues from caching Serializers
See original GitHub issueI 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 the SerializerCache(like _accessorMethod in BeanPropertyWriter) and it would be great if we had more control over the caching strategy so metaspace doesn’t grow unbounded.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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.
@cjimenez1 The codehaus implementation is Jackson 1.x and hasn’t seen a release for 8 years. You should upgrade to Jackson 2.