7 Replies Latest reply on Jul 18, 2011 7:00 PM by pgmjsd

    Huge amount of ajax4jsf object arrays are stored in memory and never dissapear

    boraldo1
      Here is the stack of libraries in my application:
      jboss-seam-ui:2.2.0.GA
      richfaces-ui:3.3.2.SR1
      jsf-facelets:1.1.15.B1
      jsf-api:1.2_14

      When I log into application and start opening pages in one conversation (and do it many times) java process memory increases infinitely.

      In profiler I saw that when I open pages huge amount of arrays of type Object are created.
      The most of them contain ajax4jsf stuff. As I understand they are objects from AjaxStateHolder conversation attribute.

      How can I prevent increasing memory ?
        • 1. Re: Huge amount of ajax4jsf object arrays are stored in memory and never dissapear
          aareshchanka

          Try to avoid conversation scope, it take lots of resources to start/end conversation.
          Use it only when you need to store data across multiple pages with navigation.
          If you want to use ajax on the page use page scope.
          Also if you are using conversation check that they are closed when you leave page where conversation is needed.


          Regards, Alex.

          • 2. Re: Huge amount of ajax4jsf object arrays are stored in memory and never dissapear
            kragoth

            How much memory are we talking about here? How many conversations? How many sessions?


            The app I work on has been done completely with conversations. There are probably only 1 or 2 beans that are Page scope out of 300-400 beans and we have pretty much the same stack as you. A bit of a4j stuff on a lot of pages and we have no memory issues.


            With regards to your question.


            How can I prevent increasing memory ?
            



            Every new conversation is obviously going to increase your memory usage. However, the increase should be quite small. If you are getting large memory increases from new conversations then maybe you need to check what you are storing in your conversations. Make sure your application is not at fault here. It's fairly unlikely that Seam/Ajax is doing this as there are many people using Seam with Ajax(Richfaces) and I haven't seen anyone else complaining about this particular issue.


            Also make sure you are ending your conversations when they are no longer needed. Remembering of course that ending a conversation doesn't mean that it will be cleaned up straight away. It's just gets flagged as no longer being a long running conversation.


            Anyways, ultimately you need to provide more information to get better feedback.
            So collect some stats and give details of what you are loading in each conversation and how many Seam beans we are talking about here etc.

            • 3. Re: Huge amount of ajax4jsf object arrays are stored in memory and never dissapear
              boraldo1

              Thanks for interest to my issue!



              My application uses single conversation for all pages that were opened during test.
              Therefore there's no leak for creating/destroying conversation.


              Profiling shows that objects that are stored in conversation by my code don't increase in sizes and amounts.
              Therefore there's no leak for my conversation objects.


              The most strange thing is that even when conversation dies due to conversation-timeout and even session-timeout, process memory doesn't decrease...
              That's why my unique explanation is some issues with ajax4jsf.


              Please, specify which additional information could be helpful..

              • 4. Re: Huge amount of ajax4jsf object arrays are stored in memory and never dissapear
                pgmjsd

                boris romashov wrote on Jul 15, 2011 09:30:

                The most strange thing is that even when conversation dies due to conversation-timeout and even session-timeout, process memory doesn't decrease...


                Then answer depends on what you mean by process memory.   If you mean the memory usage reported by the operating system for the server-side JVM process, then this depends on your JVM vendor/version/settings and how the OS reports memory usage. If you mean free heap reported by the JVM, then you should see an increase in free memory once the GC gets a chance to reclaim the unused objects.  In general, a JVM process will not 'shrink' (release memory back to the OS) when the GC reclaims unused heap space.   This is because allocating objects from it's own heap space is much faster than growing the heap.


                • 5. Re: Huge amount of ajax4jsf object arrays are stored in memory and never dissapear
                  boraldo1

                  I use Windows OS. I look at process memory in Task Manager.
                  In applications that don't use seam-jsf, memory is stable and doesn't increase such a lot.
                  If it increases permamently, it decreases in some minutes.
                  In this application it increases up to 1 MB per page and never decreases back.

                  • 6. Re: Huge amount of ajax4jsf object arrays are stored in memory and never dissapear
                    kragoth

                    Boris,


                    You need to carefully read what Joshua wrote. The JVM is not going to (unlikely to) release the heap space back to the OS. So your task manager will always show an increasing amount of memory used by the JVM as time goes on. If you actually monitored the JVM (using jConsole or equivalent) you will probably see that most of this memory usage is very short before returning back to the heap after the GC runs. So your JVM theoretically can use as much memory as you specified in the max memory argument even though it may never use all that memory at once or even hold more then 10% of it after a GC run.


                    You have to think of the JVM as almost it's own operating system with regards to memory. It tries its best to manage it and optimise it's usage of it. Releasing memory back to the OS is something it will probably try to avoid in case it needs that memory again. Remember that this memory may in fact be empty. But, the JVM knows about it so it can use it without having to ask the underlying OS for more memory. This is why it keeps it. It is much faster to use memory it knows about then wait for the OS to give it some.


                    When I monitor my application there are some actions that for many number of reasons (large datasets are one) that my increase my memory usage by over 100MB but it only lasts seconds before the GC comes along and reclaims all that memory for the JVM. Our production environment with 20-50 users connected consistently fluctuates between 600MB and 1.5GB of used heap space in a 20 second cycle. (lowest is probably due to a minimum size argument we have provided).


                    To prove this to yourself set your max heap size to something small. Then you will see your JVM process not grow beyond that point. But, I would recommend reading about how you can monitor your JVM with something like jConsole or VisualVM so you can understand what's going on for yourself.

                    • 7. Re: Huge amount of ajax4jsf object arrays are stored in memory and never dissapear
                      pgmjsd

                      FWIW, our app has pretty heavy A4J traffic every day, and none of the JVMs in the cluster have any issues staying up for months (although we restart them every weekend just to be safe) - CentOS, JBoss AS 5.0.1 GA, Mojarra 1.2, Seam 2.x, Rich Faces / A4J 3.x


                      Personally, I wouldn't run any Java server side systems on WinDoze.  Even for development.   Just asking for trouble.   I do realize that it's not always possible to do that, but since we can use Java-on-Linux everywhere, that's what we do.