220 likes | 374 Views
Thread Management in Application Servers. JACQUARD. JACQUARD. Wednesday, October 11, 2006. RNTL JOnES Meeting – Paris - France. Nicolas DOLET (nicolas.dolet@inria.fr) Philippe MERLE ( philippe.merle@inria.fr ) Jacquard Project - INRIA Futurs,
E N D
Thread Management in Application Servers JACQUARD JACQUARD Wednesday, October 11, 2006 RNTL JOnES Meeting – Paris - France NicolasDOLET (nicolas.dolet@inria.fr) Philippe MERLE (philippe.merle@inria.fr) Jacquard Project - INRIA Futurs, Laboratoire d‘Informatique Fondamentale de Lille (LIFL), Université des Sciences et Technologies de Lille (USTL), Villeneuve d’Ascq, France
Outline • Context • Problem & Motivation • Objectives • Control threading activity • Our approach • Thead Management Framework (TMF) • Area Management Framework (AMF) • Framework organization • Conclusion • Perspectives
Context • Application servers host Application Components (AC): • OSGi: • Bundles • JOnAS: • EJBs • Servlets • PEtALS: • JBI Binding Components • JBI Service Components
Context • Application servers are composed of Middleware Components (MC): • JOnAS = Web and EJB containers for application components + ( JacORB & Axis & JORAM for communication ) + ( JORM & JOTM/MEDOR/Speedo & C-JDBC for services ) + … • PEtALS = Enterprise Service Bus (ESB), JBI compliant + JBI containers + JORAM for communication
Context AC3 AC2 Application Server MC2 AC1 MC3 MC1 hosted by composed of Both AC & MC components can create Threads !
Problem & Motivation • Problem: • Creation of a large number of threads can cause: • Performance degradation due to thread context switches • Partial crash of the JVM / Application Server • Motivation: need to control Thread allocation • Ensure the property: “Never more than X threads simultaneously”
Objectives • Monitor Thread allocation... • of (embedded) Middleware Components • of (user) Application Components • ... with several statistics: • Number of active threads • History of threads allocation • List of classes using threads • Protecting Application Servers • against MC (e.g. JMS could create too many threads) • Thread pool solution drawback: ∑MC thread pools > JVM Threads limit • against AC (e.g. EJB should not create threads) • There is currently no solution for the control of AC threading activity • Future public Application Server could be hacked by a viral AC
Middleware Components Integration –The Pool Solution’s Drawbacks MC1 MC2 MCn Configurable Thread Pool Configurable Thread Control Thread Management ? Thread Thread Thread • Developpers have to implement the thread control for each new component... Application Server configures (in a property file) configures (via JMX) how toconfigure ?
Thread Management Framework with APIs MC2 AC MC1 MC2 Explicit Thread Management No Thread Management Configurable Thread Management Configurable Thread Management • Modify all MC for using TMF APIs • Manual patches of source code of existing components • Using Aspect Oriented Programming to modify existing components uses uses uses Thread Management Framework
TMF with the Thread Class Adaptation AC MC1 MC2 No Thread Management Configurable Thread Management Configurable Thread Management • Transparency: • Do not have to change MC / AC • Activation on demand Thread Management Framework Java Thread Class
Our Approach • Modification of the java.lang.Thread class • Bytecode injection using the ASM tool • Any thread includes these modifications and can be controlled by areas • Area Management Framework • Each thread is assigned to an area when it starts, according to a criterion • e.g., the package of the instance that create the thread • Each area defines a manageable limit, and can trigger an alarm when the limit is reached
Area & Alarm Concepts • An area • is an entity for monitoring a pool of resources (eg. Threads) • can support children areas • counts the number of Threads for itself and each child recursively • can block the execution of the thread • can trigger alarms • An alarm can have several behaviours: • save alarm messages in a log file • throw exceptions • send a mail to an administrator • composition of different features
Where to Adapt the Thread class ? Before thread starts After thread exits • Thread activity. Never more than X Threads
How to Rewrite the Thread Class ? • Bytecode injection (ASM) • org.objectweb.area.thread.AdaptThreadClass class Thread{ public void start(); private void exit();} class Thread{ public Area area; public void start(); private void exit();} ASM
Framework Organization • API • AreaProvider : management of the areas • Area : management of the resources • AreaProperties : management of the area features • AreaStatistics : build statistics on the resources • Alarm : send alerts • Current implementation of TMF: • lib • SingletonAreaProvider: JVM bootstrap • DefaultArea, DefaultAlarm, DefaultXXX,… : all interfaces default implementation • SAXHandler: area configuration • NoLimitArea, OutOfMemoryAlarm • thread • AdaptThreadClass: ASM patch • ThreadManager: static class for the delegation of the management to AMF
TMF Default Implementation • DefaultArea • enter (resource) • parent.enter (resource) • If (counter == 0) • alarm.alert (this, resource) • wait () • counter = counter -1 • exit (resource) • counter = counter + 1 • notify () • parent.exit (resource)
AMF Architecture • Graph of Areas / Alarms • Managed by an AreaProvider • Configurable by users (XML) • Global view from the root Area <area name="OTM" description="ObjectWeb Thread Management" limit="500"> <alarm class="org.objectweb.area.lib.DefaultAlarm"/> <!– Alarm2 --> <area name="java" description="Java packages" limit="100"> <java package="java."/> <java package="javax."/> <java package="sun."/> <alarm class="org.objectweb.area.lib.OutOfMemoryAlarm"/> <!– Alarm1 --> </area> <area name="ObjectWeb" description="ObjectWeb packages" limit="100"> <java package="org.objectweb."/> </area> <area name="local" description="Local packages" limit="100"> <java package=""/> </area> </area>
Fractal Component Based Approach • TMF can be built either in an Object version or in a Component one • Area configuration via Fractal ADL
Integration into PEtALS • Basic integration for monitoring Middleware Components (MC) activity • Add TMF libraries in the java.endorsed.dirs property • Fine grain integration for monitoring Application Components (AC) activity • Modify the JBI Installer component in order to notify AMF for a reconfiguration of its Areas • String componentClassName = componentDescription.getComponentClassName(); • int lastSeparator = componentClassName.lastIndexOf('.'); • String packageName = • componentClassName.substring(0, lastSeparator + 1); • PetalsService.addPackageInPetalsArea(packageName);
Conclusion • Overhead < 1 sec • Benchmark : • + 20% when classical launch • + 4 % with a SingletonAreaProvider • Tested with RUBiS : non measurable overhead • Threads allocation can be managed • transparently inside the Application Server, for Middleware Components • with minor modifications (of the Application Server source code) for Application Components Mean time is 13767 milliseconds. 16593 milliseconds. 14373 milliseconds.
Perspectives • Other software monitoring change the AreaProvider • Integration into other middleware: • JORAM • DREAM • Manage other resources, e.g. : • Messages • Sockets • DBConnections Requires ‘only’ to adapt the resource class, to use the Area Management Framework
Thank You • Any questions ? • TMF available at: • http://tmf.gforge.inria.fr • TMF for JOnAS available at: • http://jonas.objectweb.org • TMF for PEtALS (soon) available at: • http://petals.objectweb.org