PermGen memory isn't the same thing as regular heap memory. For Tomcat, the default PermGen space is "only" 128MB, but if you're using an ORM or other systems that do a lot of static objects, it's often advisable to double that.
If you are running Tomcat, search the Tomcat forum for more on this particular issue.
I find it worrying that this 'out of memory' is happening inside a Servlet. If the Servlet handles many simultaneous requests then it is possible that two or more FOP transformation will be active at the same time and if you are short of memory with just one request then, obviously, you are going to be worse off with two or more simultaneous requests. You may have to consider having a process, maybe external to the Servlet container, which queues FOP transformations to make sure that you limit the number of active transformations. Of course this could mean that your average response time will increase but that must be better than an 'out of memory' condition.
Richard Tookey wrote:I find it worrying that this 'out of memory' is happening inside a Servlet. If the Servlet handles many simultaneous requests then it is possible that two or more FOP transformation will be active at the same time and if you are short of memory with just one request then, obviously, you are going to be worse off with two or more simultaneous requests. You may have to consider having a process, maybe external to the Servlet container, which queues FOP transformations to make sure that you limit the number of active transformations. Of course this could mean that your average response time will increase but that must be better than an 'out of memory' condition.
Depending on the size and complexity of the request, running FOP inside a servlet is not an unrealistic thing to do. If you want a web request to generate a PDF via FOP, ultimately, it's going to be a servlet receiving the request anyway. The apache Cocoon webapp framework relies on FOP for its PDF functionality, for example.
The issue here isn't "running out of memory", it's running out of PermGen memory. PermGen space isn't the same thing as general space. It's allocated differently, and, as I mentioned before, it's not as big as the regular heap memory pool. Nor can adjusting the heap limits help, since there's a completely separate parameter that sets the PermGen size.
Tim Holloway wrote:
The issue here isn't "running out of memory", it's running out of PermGen memory. PermGen space isn't the same thing as general space. It's allocated differently, and, as I mentioned before, it's not as big as the regular heap memory pool. Nor can adjusting the heap limits help, since there's a completely separate parameter that sets the PermGen size.
OK it is not running out of general memory but 'PermSpace' but surely this doesn't change the fact that FOP is consuming a too much of the container's resources for just one request and simultaneous requests will make it far worse. Many year ago when I first used FOP in earnest the FOP transformation took so much memory (JDK1.4 so not PermGen involved) that the FOP processing was done in a separate computer.
Actually, we have no idea how much general heap memory this particular transformation is using. All we truly know is that it wants more PermGen space. And lacking actual breakdowns, I can't even guarantee that FOP is what's eating PermGen. I've never had FOP blow out that particular resource, although ORM-based apps are a perennial nuisance in that regard for me. So FOP+Hibernate could be more a Hibernate problem than a FOP problem, as an example.
I would definitely monitor system resource usage, however. There may be FOP-related issues. Although a "lot" of memory is something whose absolute size changes from year to year. Still, in order to measure how much heap memory is being eaten - and whether it's worth the expense to redesign for an external processor - first we need to resolve the immediate problem. That can be done with a simple VM setting, which is a lot faster and easier than re-architecting the app for gains which may or may not materialize.
Tim Holloway wrote:, which is a lot faster and easier than re-architecting the app for gains which may or may not materialize.
I have voiced my concerns about FOP memory resource usage and have not suggested a "re-architecting". Having worked on a project that employed an IBM high volume web site consultant I know that establishing a client usage pattern is paramount in deciding on an architecture. Knowing the usage pattern allows one to model various architectures to establish resources required. My experience is that FOP is (or at least was) a very resource hungry process and may be bad news when used in a web site. I know little about the more recent garbage collectors and bow to your experience but I wanted the OP to be aware of possible resource shortage problems. I don't want to get into an argument over this.
MaxPermSize defaults to 128m. 256m will almost always do if you need more, although I did have to do a bump up to 384m on a complex system this morning.
Fortunately, PermGen space is not used for most memory needs and it's pretty much all shared memory, so adding more users is unlikely to require massive amounts of PermGen.
Post by:autobot
Looky! I'm being abducted by space aliens! Me and this tiny ad!
a bit of art, as a gift, that will fit in a stocking
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
