Announcement Announcement Module
Collapse
No announcement yet.
Memory leak around RedirectView? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Memory leak around RedirectView?

    Hi,

    I've just started investigating this, but it looks like "something" is leaking RedirectView objects in my spring-mvc/web application (no web-flow). We are using spring v2.5.5

    It seems like the number of RedirectView objects grows over time, and eventually may kill our servers.

    This is how a histogram dump looks after a day online. (count-number | instance-count | retained-heap)
    13: 297871 30978584 org.springframework.web.servlet.view.RedirectView

    And our Full GC has run pretty recently. So basically I have 30MB of RedirectView objects in 300K instances. Now 30MB will not kill me, but in 10 more days this will become 300MB and that's a problem.

    I am creating a heap dump from prod to analyze the memory and understand who is retaining these objects, but I wanted to first check the forums and see if anybody had a similar issue, or may help me get started. It is quite possible that we are incorrectly using Spring's redirect mechanism. (we have no direct dependency on that class)

    Thanks in advance
    AB
    Last edited by sotretus; Jul 25th, 2009, 02:17 PM. Reason: explained numbers

  • #2
    Workaround

    Ok, so this took some time, but here are the results.

    One instance of "org.springframework.web.servlet.view.InternalReso urceViewResolver" loaded by "org.apache.catalina.loader.WebappClassLoader @ 0x2aaaf00c1510" occupies 209,085,192 (11.30%) bytes. The memory is accumulated in one instance of "java.util.HashMap$Entry[]" loaded by "<system class loader>".

    mm...and everything comes to place now. InternalResourceViewResolver extends (grandson of) AbstractCachingViewResolver, which has a field called viewCache. The problem seems to be that we are redirecting to views with QueryString parameters, like so
    redirect:/myapp/view?userid=1
    We are even doing redirects to other websites that have mandatory URL parameters (i.e. paypal)

    Additionally, there is nothing actually to "resolve" because it is just a redirect; I think it shouldn't be cached (i.e. I don't have to translate a key to an actual view, like a jsp a pdf or whatever).

    Unless we are the only ones doing this, it looks pretty serious. Any very-simple workarounds for this?

    My current attempt will be at extending InternalResourceViewResolver (resolveViewName) and if this is a redirect then I'll skip caching.

    Any other suggestion? Am I thinking something wrong?

    Regards
    AB
    Last edited by sotretus; Jul 26th, 2009, 12:33 AM. Reason: typos

    Comment


    • #3
      That was my take also when I read your initial post, one of the ViewResolvers probably holds on to the instances because they are cached.

      The problem lies (imho) in the fact HOW you are using the redirects. You should add the userid to the model and redirect to /myapp/view, spring will append the userid=1 part for you and that way you will only get 1 instance of the RedirectView for that particular URL. If you don't do it you will get a cached view per userId.

      Comment


      • #4
        Resolved

        Well, if that's the case, then I'd rather no modify anything, as it is unlikely anybody will change the current behavior.

        It would have been nice to receive a warning at least, but that's ok.

        Thanks for the update
        Regards
        AB

        Comment


        • #5
          Originally posted by Marten Deinum View Post
          That was my take also when I read your initial post, one of the ViewResolvers probably holds on to the instances because they are cached.

          The problem lies (imho) in the fact HOW you are using the redirects. You should add the userid to the model and redirect to /myapp/view, spring will append the userid=1 part for you and that way you will only get 1 instance of the RedirectView for that particular URL. If you don't do it you will get a cached view per userId.
          Wow.. we got caught by this one too. This seems rather... dangerous! We'll be fixing our code, but the fact that the framework is doing this caching including query parameters and consumers of the framework 'gotta dig' to find this out.. scary.

          Comment

          Working...
          X