# Revision history [back]

when suspecting a memory leak: one way to find the source of the problem is to take a memory dump. This can be done easily with $JAVA_HOME/bin/jvisualvm. Then look into the dump to see which objects hold references to the largest byte-arrays. Usually that leads to the root of the problem. Btw: your original idea ... Execution currentExec = Executions.getCurrent(); currentExec.sendRedirect("DownloadServlet"); ... will not stop the client engine if you define a target frame (either an iframe or a new browser tab) Execution currentExec = Executions.getCurrent(); currentExec.sendRedirect("DownloadServlet", "_blank"); //or use the id of a hidden download frame (which is what ZK does when using FileDownload.save() to avoid the unload event) Then the client engine will not stop due to an onBeforeUnload event triggered by the browser when starting a download in the same frame when suspecting a memory leak: one way to find the source of the problem is to take a memory dump. This can be done easily with$JAVA_HOME/bin/jvisualvm. Then look into the dump to see which objects hold references to the largest byte-arrays. Usually that leads to the root of the problem.

Execution currentExec = Executions.getCurrent();

... will not stop the client engine if engine. If you define a target frame (either an iframe or a new browser tab)tab) it will continue to work:

Execution currentExec = Executions.getCurrent();