Are you sure ? I see that the QueryResult is initialized right after the check for null: https://github.com/wicketstuff/core/blob/core-1.5.x/jdk-1.5-parent/inmethod-grid-parent/inmethod-grid/src/main/java/com/inmethod/grid/common/AbstractPageableView.java#L213 So I don't expect that the second call to #initialize() will enter the body again and lead to StackoverflowError
I don't think this is related to the OOME. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Dec 23, 2016 at 2:44 AM, durairaj t <durairaj....@gmail.com> wrote: > I found recursion in the inmethod API. I'm not sure whether this is the > reason for the memory leakage. > > Java file name: AbstractPageableView.java > > at > com.inmethod.grid.common.AbstractPageableView.initialize( > AbstractPageableView.java:244) > [classes:] > at > com.inmethod.grid.common.AbstractPageableView.getItemCount( > AbstractPageableView.java:85) > [classes:] > at > com.inmethod.grid.common.AbstractPageableView.getPageCount( > AbstractPageableView.java:119) > [classes:] > at > com.inmethod.grid.common.AbstractPageableView.setCurrentPage( > AbstractPageableView.java:143) > [classes:] > > *Recursive call*: initialize() -> getPageCount() -> getItemCount() > -> initialize() > > JVM throwing "java.lang.StackOverflowError". > > > Do I need to increase the stack size instead a fix? > > > On Wed, Dec 21, 2016 at 3:02 AM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > Forgot to mention that once you have the heap dumps you should compare > them > > with tools like Eclipse Memory Analyzer or JProfiler, or similar. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, Dec 21, 2016 at 9:01 AM, Martin Grigorov <mgrigo...@apache.org> > > wrote: > > > > > Hi, > > > > > > There are no known memory related issues with Wicket 1.5.x! > > > > > > The best way to debug out of memory issues is to create heap dumps just > > > after starting the application and another when the OOM occurs with > > > -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump file>. > > > > > > ResponseIOException is not related. It occurs when the browser closes > the > > > connection before the server has the chance to write the response back > to > > > it. > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Wed, Dec 21, 2016 at 3:28 AM, durairaj t <durairaj....@gmail.com> > > > wrote: > > > > > >> I'm migrating my application to wicket7.x, but it is still running in > > >> wicket1.5 in production and logging following error frequently and > > >> throwing OutOfMemoryError later. I'm still analyzing wicket1.5 code > for > > >> the > > >> root cause of the memory leakage. > > >> > > >> Is it an existing error with the wicket1.5.x? did any one faced this > > error > > >> in wicket1.5 and got solution for this? > > >> > > >> I found a problem ticket in JIRA for this issue, " > > >> https://issues.apache.org/jira/browse/WICKET-3869";, but I did not > find > > >> any > > >> solution in it. > > >> > > >> Error: > > >> org.apache.wicket.DefaultExceptionMapper] Connection lost, give up > > >> responding.: org.apache.wicket.protocol.http.servlet. > > ResponseIOException: > > >> ClientAbortException: java.io.IOException: JBWEB002012: Socket write > > >> failed > > >> > > >> Server details: > > >> > > >> JVM Arguments: -D[Standalone] -XX:+UseCompressedOops -Xms2048m > -Xmx2048m > > >> -XX:MaxPermSize=512m > > >> > > >> jdk1.7.0_75 > > >> > > >> JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8) > > >> > > >> Browser IE 11 running in compatibility mode IE 7. > > >> > > >> Any help? > > >> > > > > > > > > >
