There is a cache of MessageBodyReader instances that grows until memory runs out.
This happens when getting lots of multipart messages (with unique boundaries). There is a cache (MessageBodyFactory.mbrLookupCache) that eventually will fill up the available memory because boundaries make the keys unique and new entries are added to the cache for each request.
We discovered this after around 700k requests. By using "jmap -histo" we managed to narrow it down and made a change to make sure the map keys would not be unique just because they had unique boundaries. After the patch, the problem went away.
I did a pull-requests for the fix. It can be found here: https://github.com/jersey/jersey/pull/50