Java Runs out of Memory (Heap Space)

[devsforev]

Hey Everyone,

I recently ran the Software Update on one of my clients FileMaker Servers, and ever since then it's been very unstable. First, I was having trouble with the java applet causing the web viewer to crash. I finally found out that it I needed to upgrade SuperContainer, fixing that problem. But that's not why I'm here.

When I run SuperContianerServer.jar, it will run okay for several hours. Eventually, it will run out of memory, spitting out errors like this:

SEVERE: An error occurred while handling request /SuperContainer/Files/images in thread http-8020-Processor28

java.lang.OutOfMemoryError: Java heap space

Dec 5, 2011 4:11:31 AM com.prosc.supercontainer.LogFilter doFilter

SEVERE: An error occurred while handling request /SuperContainer/Files/images in thread http-8020-Processor32

java.lang.OutOfMemoryError: Java heap space

StandardWrapperValve[KitchenSink]: Servlet.service() for servlet KitchenSink threw exception

StandardWrapperValve[KitchenSink]: Servlet.service() for servlet KitchenSink threw exception

java.lang.OutOfMemoryError: Java heap space

java.lang.OutOfMemoryError: Java heap space

java.lang.OutOfMemoryError: Java heap space

java.lang.OutOfMemoryError: Java heap space

Watching activity monitor, it is very clear that the size of the SuperContianer process just keeps growing, and growing, never releasing any memory back to the system. Eventually it just runs out of RAM and gives up altogether.



This is becoming somewhat of an annoyance, since I am forced to remotely log in to this server and restart the process. Costing my client downtime, and me my sanity.



I read in one of the SuperContianer FAQ's that it doesn't support Java 6 well, and to use some command line options to launch the server in Java 5. Additionally, I also read that increasing the heap space may prevent it from crashing while processing large images. I have tried running using this command for the last week or so:

/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java -Xmx1000m -jntainerServer.jar

The only thing I have really noticed is that it takes longer for the server to go down, presumably since it has more heap space. But inevitably, it still crashes from being out of memory and i am forced to log in and restart it again.



Here are some specs on the system:

• SuperContianer v2.831
• Mac OS X 10.5.8
• 8GB of RAM
• Output of "java -version":

  
  

java version "1.6.0_26"

Java SE Runtime Environment (build 1.6.0_26-b03-384-9M3425)

Java HotSpot 64-Bit Server VM (build 20.1-b02-384, mixed mode)

Any help would be much appreciated. I can post a full crash log if needed, or screenshots showing the RAM usage increasing over time. Feel free to ask me any questions that may help me get this issue resolved quickly. Thank you for your time and have a great day.

-- Devsforev

[devsforev]

Sorry, but it's been a week and I'm bumping this thread.

The problem still exists. I am going on vacation for the holidays, and I'm really not looking forward to having to log in every day from the ski resort to restart SuperContainer and Apache.

Anyway, one minor correction to my original post:

/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java -Xmx1000m -jar SuperContainerServer.jar

is the command I have been running for the last few weeks. I had a minor typo in the one I listed in the original post.

Any suggestions are welcome. I'll try anything at this point. Thank you everyone for your time once again, and happy holidays.

-- devsforev

[ooparah]

Hey Devsforev,

I apologize for the delay in getting back to you.

Our products support page contains some detailed information about how to increase the size allocated to a plugin, which may be able to help resolve your issue. Also, be sure to read the SuperContainer product support entry about running out of memory (which I believe you have already), but just in case -- and for the benefit of the community -- I am posting the link below:

http://wo.360works.com/cgi-bin/support/productsupport.cgi/SuperContainer#SuperContainer40

Regards,

[bcooney]

I would love to see this page updated! "Fix! Fill this in" just isn't that helpful, lol.

[ooparah]

I would love to see this page updated! "Fix! Fill this in" just isn't that helpful, lol.

So true... I will have to work on that!

[devsforev]

ooparah,

Thank you for getting back to me. The two links you provided is indeed where I came up with the command I was executing from the terminal to run SuperContianerServer.jar. Since launching it from the terminal with the switches listed has not proved successful for me, I am going to try another approach listed.

On the http://wo.360works.com/cgi-bin/support/productsupport.cgi/Heapspace_Out_of_Memory_Error page, it mentions two locations where I can place a "memorysize" file that should adjust the heap space. Both locations listed did not exist. I chose to go with the first method, and created the directory /Library/Application Support/360FmKit/. I then used vim to create the memorysize file, and simply wrote in "1536" (without the quotes, of course). Both the 360FmKit directory and the memorysize file have the ownership root:admin.

On a side note, this thing is serving a lot of images. The /Users/Shared/SuperContainer/Files folder has 61,339 items consuming 11.45GB of space according to Finder. I don't know if this helps nail down the problem at all, but it can't hurt to provide that info for you.

With the new builds of SC, is there still an incompatibility with Java 6? I'm going to be launching SC from within the Finder on this trial of testing now, and this machine is running Java 6. I'm curious if I should still be using the work-around in the terminal to force version 5.

I just downloaded the latest build (v2.852) of SuperContainer and will be using that (and any other new builds) going forward in this thread. I'm going to give this a whirl loading up SuperContainerServer.jar directly within Finder (which will run on Java 6, presumably) this time and we will see what happens. This problem is not solved yet, so any continued support would be greatly appreciated. I'm willing to try anything, so feel free to throw out some ideas and i'll give it a shot. I'll keep you posted with any developments as they occur.

Thank you for your time,

-- devsforev

[exizldelfuego]

Hi, I’m having the same problem devsforev is having. Our SuperContainer, which has been faithfully serving images for a few years now, has progressively become more unstable. We’re to the point where we need to reboot the applet daily.

SuperContainer is installed on a Mac Mini running Mac OS X 10.6 with 2GB of RAM. The images reside on an external USB drive. SuperContainer is the only thing running on this machine. I completed a full wipe this past weekend hoping it might “clear the air”, but it’s had no effect.

I’ll try upping the available RAM as described above and check back in, but as mentioned, our observation has been that SC slowly consumes more RAM without ever retreating. So it seems like we’re just prolonging the periods between SC stalls rather than addressing the issue. I love the functionality SC has brought to the table, but I’m getting a bit concerned.

[jdubster]

This is kinda of a big deal for us as well, it used to be that SuperContainer was more stable even that Filemaker Server. Now it has been crashing every week. Also, once SC crashes it prevents any scheduled reboots.

On 10.6, the recommendation to target the java 5 jvm like so:

/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java

has no effect; the path just points to the java 6 jvm anyway.

It seems like this is a memory leak that was introduced by a java update. Is there anyone at 360works who would take a look at a Heap Dump if provided?

[Vaughan]

SuperContainer is installed on a Mac Mini running Mac OS X 10.6 with 2GB of RAM.

Spend $50 and put 8 GB of RAM into the machine.

[ooparah]

Is there anyone at 360works who would take a look at a Heap Dump if provided?

We made some changes to how the allocation of additional memory for our plug-ins using the "memorysize" file is handled, but have not yet released a version of SuperContainer plug-in that integrates this change. We are working on a few more changes to SuperContainer before our next release, but I can make a note to revisit this thread when a new version is released.

[jdubster]

Thanks Obinna, that would be great if you can check back on this issue after the next release. Any guidance you may have on the release schedule would also be appreciated.

I'm running SC version 2.863 on os x 10.6.8. I'm looking at the jvm using the "jconsole" memory profiler, and I can see that the "CMS Old Gen" memory pool just keeps increasing. The other memory pools look normal.

One thing that seems to help in addition to the "-Xmx1000m" flag on the command line is to add a "-d32" flag. This forces the 1.6 jvm to run in 32 bit mode. It doesn't fix the memory leak, but the initial heap size is smaller, so SC may run for longer before overflowing the heap.

[Paul D.]

We are experiencing the same issue except on Windows [Clients are Win 7 x64 w/4GB RAM; Server is FMSA11 Win2008 x64 w/8GB RAM]. We're using SuperContainer v2.864 and Java 1.6

The above links no longer work:

http://wo.360works.c...uperContainer40

http://wo.360works.c...of_Memory_Error

so I can't see if there was a Windows solution there. I'd rather not downgrade to Java 1.5 due to vulnerability issues. And we had a the spinning logo issue with Java 1.7

Is this the solution that I should use: http://docs.360works.com/index.php/SuperContainer#Out_of_Memory ? Or is there an updated version of SC coming soon?

Thanks,

Paul

[ooparah]

Is this the solution that I should use: http://docs.360works...r#Out_of_Memory ? Or is there an updated version of SC coming soon?

Yes, you can attempt to launch the SuperContainerServer.jar file with more memory allocated or also use the memorysize file approach.

Regards,

[bngoofy]

Hey All,

I have been working with Obinna on this issue for over two months and have tried all the above posts several times. None of which are working.

Every three hours I am forced to go in to three separate servers and shut down ( usually force quit ) and restart SuperContainer from terminal.

I also have seen, even with no traffic ( say.. on Sunday ), that SuperContainer will not quit and hangs there not allowing the system to restart which we do every night.

Please let me know if you have had the same issues.

Thanks

Shawn

Obinna -- ETA of a fix would be great. Lots of upset clients on my end. Would be great to put this to bed. No Pressure :)

[Valentin]

Please give this version a try: https://dl.dropbox.c...ainer-2.865.zip

I believe this thread is describing two issues:

* one: certain deployments do require more memory, b/c there is a need to render thumbnails for large files and Java default setting of 96Mb is not enough, this is usually the case when running in standalone using SuperContainer server jar, this can be addressed by increasing memory allocation. Directions for increasing memory in standalone deployment: http://docs.360works...r#Out_of_Memory

* two: version 2.86 of the companion plugin introduced a bug where the plugin was not reusing the session and every plugin request resulted in a new session being created, this preview of version 2.865 fixes the issue.

For best results update SuperContainer server and all instances of the companion plugin.