Out Of Memory ...

With -3- users running my app, I get an out of memory.

Tomcat 7
Windows 7 Home Premium (32 bit)
Java 7

SetEnv.Bat has the following
set JAVA_OPTS = -Xms1024m -Xmx1024m -XX:PermSize=512m -XX:MaxPermSize=512m

I need about 10 people to connect.

Any ideas?

You are loading something BIG into your applications memory. Without seeing your applicaiton it is hard to say what would be the best thing to do, but probably some sort of paging or lazy loading to large DB listings. Check out
this webinar
that might give you hints how you could profile the issue and fix it.

Of course if two users are ok with 1gig, 5gigs should be enough for 10. Getting that much memory might be cheaper to invest than to invest more to your app development :slight_smile:

cheers,
matti

You should get a dump and then analyze it. You may have to check if the flag is different under Java 7 (we use Java 8), but I think it’s the same:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/somepath/tcdump

The idea is it will write a dump to the specified directory. You can then profile it in Eclipse memory analysis or the like. It will tell you where the most memory is being used.

Obviously, if you load a lot into memory (like big containers) for Vaadin, it will use it up. This is one of the downsides of Vaadin containers and such compared to old JSP days when we’d loop through our data to generate the listing, but we wouldn’t need to keep any of the data once we streamed it out as HTML. With Vaadin, if your table/grid shows 1000 rows, it keeps all 1000 rows of data in memory on the server. I’ve not done much with lazy containers or the like to know if they can just keep a primary key value or the like to allow it to be tracked without having to keep the entire Item in memory or not.

Okay. Thanks for the tips.

In most data access, I get a connection from the pool, get a result set, return connection to the pool.

Then I turn the result set into an indexed container and send it to the component requesting the data. (Typically under 200 records).

It should all be disconnected.

I’m thinking I have too many components going on - it is a big application with a number of views, tabs, lists.

Think profiling is next up. Will advise.

Yeah, 200 records isn’t a lot (unless they are big records), but the data put into the indexed container remains there for as long as the container exists (which is at least long enough for the view that shows the widget that makes use of the container is in the browser).

When we started, we created a TAB view because it seemed very cool, and it is, but the downsize is that all of the data retrieved to populate those TAB views remains in memory for the user’s session until the tab is closed or they logoff. So even though most of the data is not visible, it’s still held in the server in the vaadin containers and related widget objects.

By the way, this also meant that stuff like “default buttons” that are clicked when ENTER is pressed don’t work as expected because it’s possible that a tab that is not even in view will have it’s button executed because all of the views are present at the same time (they are not true windows, for example, just DIVs in a single HTML DOM).

Not sure if it’ll help in your case but you should have a look at SQLContainer and FreeformQueries/TableQueries. This way you don’t have to manually iterate over a ResultSet. It might also offer a way of lazy loading that might not cause OutOfMemory-Exceptions.