To avoid waiting until the memory usage gets high, start the JVM with the following options which will write the heap dump when an out of memory error occurs. I use them in production systems, there is no overhead.
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/diskWithFreeSpace/dumps Note that the heap dump size will be equal to the memory size (12GB in your case). > On 14 Dec 2017, at 00:53, Alexios Giotis <alex.gio...@gmail.com> wrote: > > Hi Normen, > > The Java Thread Model does not support forcefully stopping a thread executing > arbitrary code. Thread.stop() is deprecated as it unlocks all the monitors it > has locked and other threads may view an inconsistent state of protected > objects. Thread.interrupt() does not guarantee when or if the thread will be > interrupted. There are some tricks what work in certain cases but not in > general. > > To implement reliably such functionality, you may spawn a new process (e.g. > Process p = processBuilder.start()) and keep a reference to the Process p. > The new process will execute the transformation using Xalan or any other > code. When needed, you may kill it (p.destroy()). > > But this is not enough. You will need to choose a way for interprocess > communication (sockets ? files ? or better some library) and implement it. > > It is much easier and better to find what is causing the memory leak. There > are plenty of tools in Java to help with this task. Xalan and FOP work quite > well and I am not aware of any memory leak. I suggest to let the application > run for some time and when the memory usage is getting high, connect to it > using Java Mission Control or jVisualVM or even JConsole or jmap to take a > heap dump. Then analyze the heap dump to find out where memory is retained. > If the heap dump is several GBs, I suggest to use Eclipse MAT which works > with huge heap dumps. > > > HTH, > Alexios Giotis > > > > > > > >> On 13 Dec 2017, at 14:52, Normen Ruhrus <n.ruh...@alphasoft.biz >> <mailto:n.ruh...@alphasoft.biz>> wrote: >> >> Hey there, >> >> using FOP for quite some time now, thanks everyone for all the fine >> development. >> >> Iam running FOP 2.0 embedded into a Servlet on Tomcat 8.0.x with Java8 on a >> Windows Machine (server 2012 R2). >> Usually we have no problems but from time to time during the transformation >> org.apache.xalan.transformer.TransformerImpl.transform() process an Out of >> Memory Error occurs. >> >> When trying to recreate the problem with the same XML and same XSL we have >> no problems; the process takes a very short time (<100ms) and uses not much >> memory (<50MB). >> The application is configured so it can cosume up to 12GB(!) of RAM so it >> looks like some indefinite looping is going on, but unfortunately i have no >> further logs at this time to help me with the investigation. >> >> This is why i wanted to put the transformation into a seperate Thread and >> supervise it and kill it off if a certain timeout is reached, however iam >> not able to. >> So the question is can you think of any way to stop this processing? I have >> implemented the multithreading here with FutureTasks but can switch to just >> Threads easily, too. It would be better to kill off the Thread before it >> throws an Out of Memory error and with this affecting the whole Servlet so >> that subsequent requests cannot be processed anymore. >> >> Naturally it would be best to find the source of the problem, of course, but >> that can take me some time and i would like to have a fallback solution >> instead with forcefully stopping the Transformation. >> Hope someone is able to help me out with this; thanks in advance and best >> Greetings >> >> Normen >
