[swd847]

I only had a real quick look at the code but it looks like where page scoped elements are stored depends on weather client or server side state saving is in use. If client side state saving is in use then the page scoped elements will be serialised and send to the client in compressed form (have a look at the page source, there will be a hidden form element with the data). If server side state saving is in use then the state (including page scoped elements) will be stored in HttpSession, taking up memory on the server.

this setting is determined by a context-param in web.xml.

[meetoblivion]

So, what you're saying is that we have 2 options:

1. Use server side state saving, and each session grows insanely huge.
2. Use client side state saving, Leave open the possibility of the objects being manipulated on the client.

Am I right?

[swd847]

With server side state saving you can limit the number of views that are stored on the server, for the RI I think the default is 15.

With client side state saving the RI also lets you encrypt as well as compress the state on the client, which should provide protection against object manipulation on the client side.

These issues only arise if you are using page scoped objects.

[meetoblivion]

Then what happens with EVENT, SESSION, APPLICATION scoped?

I also want to point out that you're saying all of this is possible but without any examples.  I've searched a bit, I can't find anything relevant.

[swd847]

Have a look at the JSF RI FAQ. It contains a lot of info on how client and server side state saving work, and the pros and cons of each.

EVENT scope objects do not survive the current request, so they are not really stored anywhere (they are in memory while the request is active).

SESSION scoped objects are stored in HttpSession.

APPLICATION scoped objects are stored in the servlet context.

[meetoblivion]

I actually saw that info on mojarra in my search.  i still don't see, from reading that, how you would enable client side state storage.  to be honest though, i've been thinking that it's not the solution.

the curious thing that i'm seeing the second time around is how the defaults line up.  essentially, the default behavior is to store it on the server compressed.  This is Low/Medium in session size, high CPU, and low bandwidth.  I'd say that's fairly ideal for any server and I can't think of any reason to not do it that way.

it still appears though that in this configuration, seam is serializing objects to the session in a very verbose way.  Maybe it's how the code's written?  I've got an interesting question - what does seam do if the object's not serializable?  i've been expecting to see serialization exceptions, but none have popped up.

[makeitfast]

I am using Richfaces and added following context params to the web.xml and reduced the used session size seriously:
                <param-name>com.sun.faces.numberOfViewsInSession</param-name>
                <param-value>2</param-value>
and
                <param-name>com.sun.faces.numberOfLogicalViews</param-name>
                <param-value>2</param-value>

Everything seems to work fine und I have encountered no negative side effects so far.

[makeitfast]

For the estimation of the heap size you can use various tools.
I used JProfiler, which is really great and you can do a lot of memory analyzing.
JConsole ist also a good choice and of course the Server-Info in the JMX-Console if you just want a raw overview.

[damianharvey.damianharvey.gmail.com]

I've just come across the same issue. I'm also using MessAdmin and am seeing my Session sizes approx 55MB as soon as the User logs in.

I have removed everything from the Authentication method and am redirecting to an empty page on login. I have tried removing all classes annotated with @Startup (including those that are application scoped). The session size is consistently above 55MB.

I have also tried upgrading to the lastest Mojarra JSF release and changing the JSF state saving parameters eg

     <context-param>
          <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
          <param-value>server</param-value>
     </context-param>

     <context-param>
          <param-name>com.sun.faces.serializeViewState</param-name>
          <param-value>true</param-value>
     </context-param>

     <context-param>
          <param-name>com.sun.faces.compressViewState</param-name>
          <param-value>true</param-value>
     </context-param>

If I change my Authenticator class to be nothing other than this:

@Name("authenticator")
public class Authenticator {
  //small session size
  public boolean authenticate() {
    return true;
  }

Then my session size stays low (approx 400KB). As soon as I inject the EntityManager (and change nothing else) then the session size shoots up to 52MB.

eg.

@Name("authenticator")
public class Authenticator {
  //huge session size
  @In private EntityManager entityManager;
  
  public boolean authenticate() {
    return true;
  }

Here is a screenshot of the MessAdmin session profile.

Can anyone suggest a course of action to fix this or are large session sizes something that we are all currently living with?

Thanks,

Damian.

[walterjwhite]

Hi,

I agree partially with what you're saying that the entity manager does eat up quite a bit of memory, but in my case, it is all for caching.  I'm using EHCache and it does cache entities I have marked with the Cache annotations.

Without seeing all of your source code, it is really difficult to determine what the root cause of the problem is, if indeed there is a problem.

The server I am using has about 300MB of ram and the only time I've run out of memory is  because I improperly coded a file servlet for sending the client files.  I load test my application with JMeter and have hit it with 10 and 100 concurrent users and the application responded quite well.  I attribute most of that due to the fact I had enabled QoSFilter and DoSFilter in Jetty.

You need to run some tests to see how many concurrent users you can have before you start to lose performance.  The results should be clear enough to point you in the right direction.

If you have a process to follow (scientific method), you can isolate problems easily and quickly.  Take a day to write JMeter tests for you application, and then tweak the settings to test 10 users, 100 users concurrently and you should see a noticeable difference.  Do the same for the number of threads for the http listener and database pool.

Walter

[damianharvey.damianharvey.gmail.com]

Thanks Walter.

Unfortunately, JMeter won't help me fix this issue. I have a 2GB heap and my Session sizes are hitting up to 75MB and we are definitely seeing issues with 30 concurrent users.

I have no caching on at all. I have 151 entities at present though and I'm thinking that this is probably what the EntityManager is doing. I'll do some tests with an empty project and then with a 75 entities to confirm (not that reducing the number of entities is really an option....)

Cheers,

Damian.

[walterjwhite]

Well, the issue is that you are holding onto your references somewhere.  If all references are gone to an object, eventually the JVM will remove it.  Even if the heap is full and there are objects that still sit out there waiting to be reclaimed by the JVM, you won't get an out of memory error until none of that can be freed.

I am guessing that the entity manager may have some internal caching using a weak hash map or something that can be reclaimed as needed.  I wouldn't point the finger at that though.

Without your source code or component definitions, it is difficult to diagnose just as it is to fix a car without seeing it or hearing it run.  Make sure the air pressure is where it should be and that you have the correct amount of oil in the engine.  Also, make sure there is gas ...

That being said, properly scope your components.  If everything is setup properly and you cannot reduce memory consumption, then you need to scale out with more hardware or a remote JVM / memory cluster.

JMeter will help you see how much your system can handle.  You're right, it won't help you discern exactly where the memory is being hogged.  That is where a profiler comes into play.  Netbeans works well for free.  If you have money, try Yourkit.

I use JMeter to see how well the application performs in various settings.  Since I'm using Jetty for testing, it is trivial to configure the number of threads and other parameters.  Write a plugin that iterates over a few configurations and then generates a chart with performance.  I'm graphical.

Walter

[gonzalad]

Hello,

Just don't use MessAdmin to calculate session size, it computes incorrectly ManagedPersistence size.

See HugeSessionSizeOfJBossSeamExample.