Browse Prior Art Database

A Load Manager System for Multithread Applications Disclosure Number: IPCOM000131137D
Original Publication Date: 2005-Nov-08
Included in the Prior Art Database: 2005-Nov-08
Document File: 2 page(s) / 62K

Publishing Venue



The "Load Manager System for Multithreaded Applications" wants to address the problem of handling the load (CPU, Memory, etc.) of an applications using any number of threads and running in a container hosting other applications. While it is more common and easy to monitor and handle applications running in their own processes it is more difficult to isolate the load due to an application that consumes only a portion of resources of the hosting environment such as a JVM. A common requirement from the majority of customers is to deploy and run applications with a "maximum" CPU usage X and memory Y. While the requirement is pretty common it is more difficult to understand which is the resource consumption due to each application running in a J2EE environment or any other common container. The system independently from the data providers (i.e. the components providing usage metric data) is able to aggregate the resource consumption data and relates the values of an application defined in a declarative way.

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 54% of the total text.

Page 1 of 2

A Load Manager System for Multithread Applications

Load Manager for embedded applications provides the following plugable functions ; gather resource consumption data of all threads running in a JVM Define an application through a definition file to describe which threads constitute an application and which are the limits in terms of resource consumption perform recovery actions to autonomically maintain the resource usage under control. For example change the thread priority. notify through callback application provided plug-in to delegate to the application itself the thread load control. The notified component can be either local as remote. For examplea a remote component may prevent additional tasks to be ran on the caller's host

The advantages of this idea are;

Static and independent definition of Java applications in terms of threads. No instrumentation needed by default
Possibility of definition of subcomponent, functions etc and their load based on the thread names patterns
Autonomic and efficient load control local and/or remote.

The following picture describes the main components and their interactions.

     The Load Manager for embedded applications is made of the following components:

Load Provider: this component is responsible for gather thread resource usage data. It may use the most appropriate mean. For example Java 1.5 provides MBeans for thread and their data. It also could be possible to add custom


[This page contains 1 picture or other non-text object]

Page 2 of 2

resource usage provider. Other...