1 / 22

Thread Management in Application Servers

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,

jalila
Download Presentation

Thread Management in Application Servers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. Outline • Context • Problem & Motivation • Objectives • Control threading activity • Our approach • Thead Management Framework (TMF) • Area Management Framework (AMF) • Framework organization • Conclusion • Perspectives

  3. Context • Application servers host Application Components (AC): • OSGi: • Bundles • JOnAS: • EJBs • Servlets • PEtALS: • JBI Binding Components • JBI Service Components

  4. 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

  5. Context AC3 AC2 Application Server MC2 AC1 MC3 MC1 hosted by composed of  Both AC & MC components can create Threads !

  6. 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”

  7. 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

  8. 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 ?

  9. 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

  10. 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

  11. 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

  12. 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

  13. Where to Adapt the Thread class ? Before thread starts After thread exits • Thread activity. Never more than X Threads

  14. 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

  15. 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

  16. 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)

  17. 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>

  18. Fractal Component Based Approach • TMF can be built either in an Object version or in a Component one • Area configuration via Fractal ADL

  19. 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);

  20. 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.

  21. 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

  22. 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

More Related