10 Replies Latest reply on Jan 18, 2011 4:27 PM by gonzalad

    Huge Session Size of JBoss Seam example

    Josef Müller Newbie

      Hi there,

      we have been struggling with the session size of Seam for quite a few days now and we hope you can help us.

      We downloaded and installed the booking example with JBoss Application Server 4.2.3 / Seam 2.1.2. If we check the session size with Apache MessAdmin we observe that the session size jumps to more than 30 Mbyte per session after a user has logged in.

      The memory consumption can also be observed with JConsole.

      It seemed to us that the huge memory consumption is related to the long conversation scope.

      We have not changed any configurations of this example.

      Can anyone give us some insights on this behaviour?

      Thank you very much!

      The philosoph

      Here is the extract from MessAdmin:

      403 B org.jboss.seam.security.rememberMe org.jboss.seam.security.RememberMe@74a2da
      62.8 KB org.ajax4jsf.application.AjaxStateHolder org.ajax4jsf.application.AjaxStateHolder@e0cfe1
      145 B org.jboss.seam.core.conversationEntries ConversationEntries([])
      72 B org.jboss.seam.international.localeSelector org.jboss.seam.international.LocaleSelector@e7a905
      12 B org.ajax4jsf.application.AjaxStateManager.view_sequence 2
      38.27 MB bookingList   
      64 B org.jboss.seam.international.timeZoneSelector org.jboss.seam.international.TimeZoneSelector@de92fc
      1.69 KB org.jboss.seam.security.identity org.jboss.seam.security.Identity@ba3f29
      50 B javax.faces.request.charset UTF-8
      38.27 MB hotelSearch   
      66 B org.jboss.seam.security.credentials org.jboss.seam.security.Credentials@188d37c
      96 B bookings org.jboss.seam.jsf.ListDataModel@2e761f
      15 B org.jboss.seam.web.session org.jboss.seam.web.Session@141c5c
      174 B user User(demo)

        • 1. Re: Huge Session Size of JBoss Seam example
          Sean Tozer Newbie

          It seems to say pretty clearly right in your quoted text what the issue is:

          38.27 MB bookingList
          38.27 MB hotelSearch

          Those components are gigantic. Is your app loading far too much data into those results, for some reason?

          • 2. Re: Huge Session Size of JBoss Seam example
            Josef Müller Newbie

            Yes, that is what we figured, too. But we have no clue what we can optimize because we did not make any (!) changes to the offical booking application example. As soon as we log one user in, the session size explodes.

            • 3. Re: Huge Session Size of JBoss Seam example
              Josef Müller Newbie

              Hi there,

              just a few more information:

              The session size shoots up without even having done a hotel search.

              We deployed the booking example on different computers, same results.

              We asked friends of us to install it, just to cross-check if we made any mistakes: same result.

              Has anyone tested the memory consumption of the example before and got a different result?

              While researching we have found two or three forum threads where this phenomenon was discussed, but without finding a solution.

              As our application will have to manage hundreds and thousands of concurrent users logged in, we cannot compensate the memory consumption with hardware.

              We would really appreciate it, if anyone has a hint.

              Thank you!


              • 4. Re: Huge Session Size of JBoss Seam example
                Serkan Eskici Novice

                I won't be surprised if the memory consumption becomes huge and huger, since the following classes are all hold in the session:

                1. BookingListAction

                2. HotelSearchingAction

                3. Identity

                4. User

                Both 1) and 2) contain a Datamodel, which is also hold in the session. Thus the search results are in the session !

                Bad implementation imho.

                • 5. Re: Huge Session Size of JBoss Seam example
                  Josef Müller Newbie

                  Thank you for your thoughts on this. But we still cannot understand this behaviour, as we had used the pure example and we did not add any additional data. The session size explodes as soon as the demo user logs in (we did not even execute a search for example).

                  If we use only the login and remove the HotelSearchAction Class and cleared the main.xhtml from any code, the session size is about 13 kbytes. Fine!

                  After that, We did some experimenting and changed the HotelSearchAction and the main.xhtml to the following:

                  public class HotelSearchingAction implements HotelSearching
                     private String searchString;
                     public String getSearchString()
                        return searchString;
                     public void setSearchString(String searchString)
                        this.searchString = searchString;
                     public void destroy() {}
                  <div class="section">
                      <span class="errors">
                         <h:messages id="messages" globalOnly="true"/>
                      <h1>Search Hotels</h1>
                        <h:form id="searchCriteria">
                           <h:inputText id="searchString" value="#{hotelSearch.searchString}" style="width: 165px;"/>

                  And here we go again, session size is about 28 Mbyte. Can you give us a further hint how to change the code, if we want to use session scope for the HotelSearchAction. We would like to keep the searchString in the session, for instance.

                  Thank you very much!


                  • 6. Re: Huge Session Size of JBoss Seam example
                    Serkan Eskici Novice


                    Have you tried making use of POJO's instead of Stateful EJB's ?

                    • 7. Re: Huge Session Size of JBoss Seam example
                      Yasser Hawari Newbie

                      did u try to log in with more users and see the session size. a 28 MB could be a one time overhead. what i mean is, log in with 5 users for example and see the total session size, is it 28 x 5 ??

                      thanks for ur post though! 

                      • 8. Re: Huge Session Size of JBoss Seam example
                        demetrio812 Apprentice

                        I recently noticed the same thing while working on a big application with a lot of users.

                        It happens only if I use the entity manager: the more I execute queries the bigger it is (so I suppose it's the Hibernate 1st level cache that contribute a lot).

                        What I think is that the value is shared among the users. In fact if I see a value of let's say 34MB in one user, analyzing the orther users I find the same value. I made some test and if I load something for a single user MessAdmin seems to calculate the increase for all user session I measure. Also it happened to have, during my tests, 50 session that MessAdmin measured as more then 250MB each and obviously this is impossible even if I set 2GB for the Heap.

                        So I suppose there is something shared that MessAdmin includes in the calculation of the size.

                        I still have to find the time to go deep in this topic but I'm glad you opened.


                        • 10. Re: Huge Session Size of JBoss Seam example
                          gonzalad Apprentice

                          The solution is don't use MessAdmin :

                          It computes inaccurately HTTP Session Size for ManagedPersistenceContext.

                          I've used it today on my application : 10 Mb in each session for ManagedPersistenceContext (and I didn't fetch ANY entity).

                          So, I use JConsole :

                          1. restart my application.

                          2. create a first HTTP session.

                          3. use JConsole to do a GC, write the heap size on paper (h0).

                          4. create a second HTTP session.

                          5. use JConsole to do a GC, write the heap size on paper (h1).

                          And h1 - h0 are pretty much the same (and not the 10 Mb from MessAdmin).

                          I wrote a little helper which serialize all session attributes (using SerializationUtils) and write the total bytes to sysout, call it as a page action (for all view-ids) and find that ManagedPersistenceContext is between 10 and 100 ko.