jersey
  1. jersey
  2. JERSEY-2297

Memory leak caused by unique multipart boundaries

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.6
    • Component/s: core
    • Labels:
      None
    • Environment:

      RHEL 6.4 and Ubuntu 12.04, both 64 bit.

      Description

      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

        Activity

        Hide
        brunteman added a comment -

        The tests fail for the pull request I made, but they also fail for a "clean" repository of jersey, so I'm not sure what the problem is there.

        Show
        brunteman added a comment - The tests fail for the pull request I made, but they also fail for a "clean" repository of jersey, so I'm not sure what the problem is there.
        Hide
        Michal Gajdos added a comment -

        Waiting for OCA.

        Show
        Michal Gajdos added a comment - Waiting for OCA.
        Hide
        Marek Potociar added a comment -

        Going to solve this one by internal commit. The pull request submitter has been quiet for too long now.

        Show
        Marek Potociar added a comment - Going to solve this one by internal commit. The pull request submitter has been quiet for too long now.

          People

          • Assignee:
            Marek Potociar
            Reporter:
            brunteman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1 hour
              1h
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 minute Time Not Required
              1m