Browse Prior Art Database

A statistical approach to discovering memory leaks in Java Web Applications

IP.com Disclosure Number: IPCOM000022692D
Original Publication Date: 2004-Mar-25
Included in the Prior Art Database: 2004-Mar-25
Document File: 3 page(s) / 82K

Publishing Venue

IBM

Abstract

Disclosed is a system for discovering memory leaks in Web Applications. The invention relies on the fact that it is statistically more likely for an an application to lose memory when a leaky component is invoked. This invention relies on analysis of log files and does not require running a debug or instrumented version of the application code. Unlike most other solutions (such as Jprobe, etc.), It is well suited for production environments, since it involves no performance degradation. The logs can be analyzed asynchronously. High loads are actually beneficial, since the more data the system analyzes the more accurate it becomes.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

A statistical approach to discovering memory leaks in Java Web Applications

Main Idea

The invention can be used with any web application server. For simplicity, we are limiting our discussion here to Java-based web applications.

To identify the leaky component(s) we can rely on two or three logs: the http access log, which contains the list of dynamic (servlets, jsps) requested and associated timestamps, and the standard error log, which contains standard verbosegc output (each event of garbage collection, available heap before and after the garbage collection, the exact time of the gc). The third, optional log, could collect information on new and expired user sessions.

Consider the amount of available heap at the end of each garbage collection. When there are no leaky components, this number will fluctuate, but remain constant on average. When there are leaky components present, this number will also fluctuate, but gradually decline, until eventually, the JVM runs out of heap memory.

Consider now a time interval between two consecutive garbage collections. In a complex environment there can be many components executing simultaneously. Some may consume heap, and some may release heap. New user sessions may be created, and some old sessions may expire. If a leaky component was called during the time interval, the amount of available heap should decline. But because of the other processes running at the same time, we may not witness a decline at all. In fact, there can be an increase in the amount of the availabl...