Search
Calendar
May 2017
S M T W T F S
« Sep    
 123456
78910111213
14151617181920
21222324252627
28293031  
Your widget title
Archives

Posts Tagged ‘architecture’

PostHeaderIcon Thread leaks in Mule ESB 2.2.1

Abstract

The application I work on packages Mule ESB 2.2.1 in a WAR and deploys it under a WebLogic 10.3 server. My team mates and I noticed that, on multiple deploy/undeploy cycles, the PermGen size dramatically decreased. The cause of this was the number of threads, which hardly decreased on undeployment phases, unlike the expected behaviour.
Indeed, Mule is seldom deployed as a WebApp. Rather, it is designed to be run as a standalone application, within a Tanuki wrapper. When the JVM is killed, all the threads are killed, too, and therefore no thread survives ; hence, the memory is freed and there is no reason to fear a thread leak.

Moreover, when the application is redeployed, new threads -with the same names as the “old” threads- are created. The risk is that, for any reason, a thread-name-based communication between threads may fail, because the communication pipe may be read by the wrong thread.

In my case: on WebLogic startup, there are 31 threads ; when the application is deployed, there are 150 ; when the application works (receives and handles messages), the number of threads climbs to 800 ; when the application is undeployed, only 12 threads are killed, the other remaining alive.

The question is: how to kill Mule-created threads, in order to avoid a Thread leak?

WebLogic Threads

I performed a thread dump at WebLogic startup. Here are WebLogic threads, created before any deployment occurs:

Attach Listener
DoSManager
DynamicListenThread[Default[1]]
DynamicListenThread[Default]
ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'
ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'
ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'
Finalizer
JMX server connection timeout 42
RMI Scheduler(0)
RMI TCP Accept-0
RMI TCP Connection(1)-127.0.0.1
RMI TCP Connection(2)-127.0.0.1
Reference Handler
Signal Dispatcher
Thread-10
Thread-11
Timer-0
Timer-1
VDE Transaction Processor Thread
[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'
[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'
[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'
[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'
[STANDBY] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'
[STANDBY] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'
main
weblogic.GCMonitor
weblogic.cluster.MessageReceiver
weblogic.time.TimeEventGenerator
weblogic.timers.TimerThread

Dispose Disposables, Stop Stoppables…

The application being deployed in a WAR, I created a servlet implementing ServletContextListener. In the method contextDestroyed(), I destroy Mule objects (Disposable, Stoppable, Model, Service, etc.) one per one.
Eg#1:

        final Collection<Model> allModels;
        try {
            allModels = MuleServer.getMuleContext().getRegistry().lookupObjects(Model.class);
            if (LOGGER.isDebugEnabled()) {
                LOGGER.debug("Disposing models " + allModels.size());
            }
            for (Model model : allModels) {
                model.dispose();
            }
            allModels.clear();
        } catch (Exception e) {
            LOGGER.error(e);
        }

Eg#2:

    private void stopStoppables() {
        final Collection<Stoppable> allStoppables;
        try {
            allStoppables = MuleServer.getMuleContext().getRegistry().lookupObjects(Stoppable.class);
            if (LOGGER.isDebugEnabled()) {
                LOGGER.debug("Stopping stoppables " + allStoppables.size());
            }
            for (Stoppable stoppable : allStoppables) {
                stoppable.stop();
            }
            allStoppables.clear();
        } catch (MuleException e) {
            LOGGER.error(e);
        }
    }

This first step is needed because default mechanism is flawed: Mule re-creates objects that were destroyed.

Kill Threads

The general idea to kill Mule threads is the following: perform a Unix-style “diff” between WebLogic native threads, and the threads still alive once all Mule objects have been stopped and disposed.

On Application Startup

In the ServletContextListener, I add a field that will be set in a method called in the constructor:

    private List<String> threadsAtStartup;
(...)
/**
     * This method retrieves the Threads present at startup: mainly speaking, they are Threads related to WebLogic.
     */
    private void retrieveThreadsOnStartup() {
        final Thread[] threads;
        final ThreadGroup threadGroup;
        threadGroup = Thread.currentThread().getThreadGroup();
        try {
            threads = retrieveCurrentActiveThreads(threadGroup);
        } catch (NoSuchFieldException e) {
            LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
            threadsAtStartup = new ArrayList<String>();
            return;
        } catch (IllegalAccessException e) {
            LOGGER.error("Could not retrieve initial Threads list. The application may be unstable on shutting down ", e);
            threadsAtStartup = new ArrayList<String>();
            return;
        }

        threadsAtStartup = new ArrayList<String>(threads.length);
        for (int i = 0; i < threads.length; i++) {
            final Thread thread;
            try {
                thread = threads[i];
                if (null != thread) {
                    threadsAtStartup.add(thread.getName());
                    if (LOGGER.isDebugEnabled()) {
                        LOGGER.debug("This Thread was available at startup: " + thread.getName());
                    }
                }
            } catch (RuntimeException e) {
                LOGGER.error("An error occured on initial Thread statement: ", e);
            }
        }
    }
    /**
     * Hack to retrieve the field ThreadGroup.threads, which is package-protected and therefore not accessible 
     *
     * @param threadGroup
     * @return
     * @throws NoSuchFieldException
     * @throws IllegalAccessException
     */
    private Thread[] retrieveCurrentActiveThreads(ThreadGroup threadGroup) throws NoSuchFieldException, IllegalAccessException {
        final Thread[] threads;
        final Field privateThreadsField;
        privateThreadsField = ThreadGroup.class.getDeclaredField("threads");
        privateThreadsField.setAccessible(true);

        threads = (Thread[]) privateThreadsField.get(threadGroup);
        return threads;
    }

On application shutdown

In the method ServletContextListener.contextDestroyed(), let’s call this method:

    /**
     * Cleanses the Threads on shutdown: theorically, when the WebApp is undeployed, should remain only the threads
     * that were present before the WAR was deployed. Unfornately, Mule leaves alive many threads on shutdown, reducing
     * PermGen size and recreating new threads with the same names as the old ones, inducing a kind of instability.
     */
    private void cleanseThreadsOnShutdown() {
        final Thread[] threads;
        final ThreadGroup threadGroup;
        final String currentThreadName;

        currentThreadName = Thread.currentThread().getName();

        if (LOGGER.isDebugEnabled()) {
            LOGGER.debug("On shutdown, currentThreadName is: " + currentThreadName);
        }

        threadGroup = Thread.currentThread().getThreadGroup();
        try {
            threads = retrieveCurrentActiveThreads(threadGroup);
        } catch (NoSuchFieldException e) {
            LOGGER.error("An error occured on Threads cleaning at shutdown", e);
            return;
        } catch (IllegalAccessException e) {
            LOGGER.error("An error occured on Threads cleaning at shutdown", e);
            return;
        }

        for (Thread thread : threads) {
            final String threadName = thread.getName();
            final Boolean shouldThisThreadBeKilled;

            shouldThisThreadBeKilled = isThisThreadToBeKilled(currentThreadName, threadName);
            if (LOGGER.isDebugEnabled()) {
                LOGGER.info("should the thread named " + threadName + " be killed? " + shouldThisThreadBeKilled);
            }
            if (shouldThisThreadBeKilled) {
                thread.interrupt();
                thread = null;
            }
        }

    }

    /**
     * Says whether a thread is to be killed<br/>
     * Rules:
     * <ul><li>a Thread must NOT be killed if:</li>
     * <ol>
     * <li>it was among the threads available at startup</li>
     * <li>it is a Thread belonging to WebLogic (normally, WebLogic threads are among the list in the previous case</li>
     * <li>it is the current Thread (simple protection against unlikely situation)</li>
     * </ol>
     * <li>a Thread must be killed: in all other cases</li>
     * </ul>
     *
     * @param currentThreadName
     * @param threadName
     * @return
     */
    private Boolean isThisThreadToBeKilled(String currentThreadName, String threadName) {
        final Boolean toBeKilled;
        toBeKilled = !threadsAtStartup.contains(threadName)
                &amp;&amp; !StringUtils.contains(threadName, "weblogic")
                &amp;&amp; !threadName.equalsIgnoreCase(currentThreadName);
        return toBeKilled;
    }

EhCache

My application uses an EhCache. Its threads names usually end with “.data”. They are not killed by the previous actions. To get rid of them, the most elegant way is to add this block in the web.xml:

     <listener>
          <listener-class>net.sf.ehcache.constructs.web.ShutdownListener</listener-class>
     </listener>

cf EhCache documentation

With all these operations, almost all threads are killed. But Java VisualVM still displays 34, vs. 31 at startup.

Tough Threads

A thread dump confirms that, at this point, 3 rebellious threads still refuse to be kill:

MuleServer.1
SocketTimeoutMonitor-Monitor.1
SocketTimeoutMonitor-Monitor.1

Let’s examine them:

  • MuleServer.1: This thread is an instance of the inner class MuleServer.ShutdownThread. Indeed, this is the first thread created by Mule, and therefore appears among the threads available at startup, before the ServletContextListener is called… I did not succeed in killing it, even why trying to kill it namely, which makes sense: killing the father thread looks like suiciding the ServletContextListener.
  • SocketTimeoutMonitor-Monitor.1: This thread is created by Mule’s TcpConnector and its daughter classes: HttpConnector, SslConnector, etc. Again, I could not kill them.

Conclusion

We have seen Mule suffers of major thread leaks when deployed as a WAR. Anyway, most of these leaks may be sealed.
I assume MuleSoft was aware of this issue: in the version 3 of Mule, the deployment of webapps was refactored.

PostHeaderIcon Tutorial: an Event Bus Handler for GWT / GXT

Overview

Introduction

Let’s consider a application, JonathanGwtApplication, divided in three main panels

  • a panel to select animal name name
  • a panel to display, expand and collapse trees of the animal ancestors
  • a panel of information to display many indicators (colors, ages, etc.).

An issue we encounter is: how to make the different panels communicate? In more technical terms, how to fire events from a panel to another one?

A first solution would be to declare each panel as listener to the other panels. Indeed, this principle may go further, and declare each component as listener to a list of other components…
Main drawbacks:

  • the code becomes hard to read
  • adding or removing a component requires to modify many parts of the code
  • we don’t follow GWT 2’s “philosophy”, which is to use Handlers rather than Listeners.

Hence, these reasons incited us to provide a global EventBusHandler.

The EventBusHandler concept

The EventBusHandler is a global bus which is aware of all events that should be shared between different panels, and fires them to the right components.
The EventBusHandler is a field of JonathanGwtApplicationContext.

Intrastructure

  • lalou.jonathan.application.web.gwt.animal.events.HandledEvent: generic interface for a event. Abstract method:
    EventTypeEnum getEventEnum();
  • lalou.jonathan.application.web.gwt.animal.handler.EventHandler: generic interface for a component able to handle an event. Abstract method:
    void handleEvent(HandledEvent handledEvent);
  • lalou.jonathan.application.web.gwt.animal.handler.EventHandlerBus: the actual bus. As a concrete class, it has two methods:
    /**
    	 * Fires an event to all components declared as listening to this event
    	 * event type.
    	 *
    	 * @param baseEvent
    	 */
    	public void fireEvent(HandledEvent baseEvent) {
                   // ...
    	}
    
    	/**
    	 * Adds an listener/handler for the event type given as parameter
    	 *
    	 * @param eventTypeEnum
    	 * @param eventHandler
    	 * @return The List of handlers for the key given as parameter. This list
    	 *         contains the eventHandler that was given as second parameter
    	 */
    	public List<EventHandler> put(EventTypeEnum eventTypeEnum,
    			EventHandler eventHandler) {
                  // ...
            }

How to use the bus?

  1. Define an event: in JonathanGwtApplication, an event is decribed by two elements:
    • a functionnal entity: eg: “animal”, “food”, “tree node”. The functionnal entity must be isomorph to a technical DTO, eg: AnimalDTO for an entity Animal.(in the scope of this turoriel we assume to have DTOs, even though the entities may ne sufficient)
    • a technical description of the event: “selection changed”, “is expanded”
  2. Add an entry in the enum EventTypeEnum. Eg: “ANIMAL_SELECTION_CHANGED
  3. in lalou.jonathan.application.web.gwt.animal.events, create an event, implementing HandledEvent and its method getEventEnum(). The match between EventTypeEnum and DTO is achieved here. Eg:
    public class AnimalSelectionChangedEvent extends
    		SelectionChangedEvent<AnimalDTO> implements HandledEvent {
    
    	public AnimalSelectionChangedEvent(
    			SelectionProvider<AnimalDTO> provider,
    			List<AnimalDTO> selection) {
    		super(provider, selection);
    	}
    
    	public EventTypeEnum getEventEnum() {
    		return EventTypeEnum.ANIMAL_SELECTION_CHANGED;
    	}
    
    }
  • When an event that should interest other component is fired, simply call the bus. The bus will identify the event type and dispatch it to the relevant handlers. eg:
    animalComboBox.addSelectionChangedListener(new SelectionChangedListener<AnimalDTO>() {
    
    			@Override
    			public void selectionChanged(SelectionChangedEvent<AnimalDTO> se) {
    				final AnimalDTO selectedAnimalVersion;
    				selectedAnimalVersion= se.getSelectedItem();
    				JonathanGwtApplicationContext.setSelectedAnimal(selectedAnimal);
    
    						final AnimalSelectionChangedEvent baseEvent = new AnimalSelectionChangedEvent(
    								se.getSelectionProvider(), se.getSelection());
    						JonathanGwtApplicationContext.getEventHandlerBus()
    								.fireEvent(baseEvent);
    
    			}
    		});
  • Handlers:
    • easy case: the component handles only one type of event: this handler must implement the right interface (eg: AnimalSelectionChangedEventHandler) and its method, eg:
      protected void handleAnimalSelectionChangedEvent(HandledEvent handledEvent) {
          return;
      }
    • frequent case: the component handles two or more event types. No matter, make the component implement all the needed interfaces (eg: AnimalSelectionChangedEventHandler, FoodSelectionChangedEventHandler). Provide a unique entry point for the method to implement, which is common to both interfaces. Retrieve the event type, and handle it with ad hoc methods. Eg:
      public void handleEvent(HandledEvent handledEvent) {
      		final EventTypeEnum eventTypeEnum;
      
      		eventTypeEnum = handledEvent.getEventEnum();
      
      		switch (eventTypeEnum) {
      		case ANIMAL_SELECTION_CHANGED:
      			handleAnimalSelectionChangedEvent(handledEvent);
      			return;
      		case FOOD_SELECTION_CHANGED:
      			handleFoodSelectionChangedEvent(handledEvent);
      			return;
      		default:
      			break;
      		}
      	}
      
      	protected void handleAnimalSelectionChangedEvent(HandledEvent handledEvent) {
      		// do something
              }
      	protected void handleFoodSelectionChangedEvent(HandledEvent handledEvent) {
      		// do something else
              }
  • PostHeaderIcon WebLogic 10.x new features

    Recent history

    BEA WebLogic 9.0, 9.1 and 9.2 were released from 2007: the main features were: a new console, WLST (WebLogic ScriptingTool), deployment plans, WebLogic Diagnostic Framework (WLDF), new security providers (RDBMS, SAML 1.1, etc.), JMS performance improvements, support of Java EE 4, JDK 5, Spring, OpenJPA, Kodo, etc.

    Since this date, some events happened:

    • Oracle bought Sun (2009)
    • Oracle released WebLogic 10.3 (2008)
    • Oracle bought BEA (2008)

    WebLogic Server 10 General Features

    • Developer productivity ehancements
      • JDK 6, Java EE 5
      • Support of EJB3 and JPA
      • BEA enhancements
    • Web Services: more annotations, less XML
      • JAX-RPC Web Services Enhancements
      • JAX-WS 2.0 Web Services Implementation
    • Misc:
      • Better administration console
      • Auto-Record of Admin Console actions as WLST scripts
      • Automatic JTA Transaction Recovery Service (TRS) migration
      • SNMP 3.0
      • Production Application Redeployment enhancements
      • Clustering – Unicast messaging (in addition to Multicast)

    Programmer Perspective

    • New persistence engine: TopLink
    • OEPE (Oracle Entreprise Pack for Eclipse): sequence of tools and plugins for Eclipse: remote deployment, debugging,  editors for weblogic.xml and weblogic-application.xml, wizards, facets, Weblogic ClientGen, WSDLC and JAXB wizards
    • Optimizations for Spring integration and certication
    • Web 2.0:
      • Ajax / Dojo client support
      • Http publish / submit engine for collaborative applications:
        • Bayeux protocol
        • data exchange within applications over persistent connections
        • scalability for Dojo clients
    • Ad-hoc tools for:
      • Oracle Database
      • Spring
      • JAX-WS webservices

    Lightweight WebLogic Server

    WebLogic 10 offers a light weight server:

    • Install only “core” WebLogic server
    • Optionally, startup other services (JDBC, EJB, JMS, etc.)
    • FastSwap: modify classes without requiring redeployment.

    Architect Perspective

    Architects have to consider WebLogic as a complete suite, and not only WebLogic Server:

    • Oracle RAC integration: Connectivity to RAC with load balancing, failover, transactions
    • Enterprise Messaging with JMS: High performance and reliable JMS messaging engine “built-in”
    • ActiveCache with Coherence*Web and EJB/JPA: Coherence Data Grid caching included and integrated
    • Operations Automation: Tools for automating management of applications and servers
    • Operations Insight: Tools for diagnosing problems in development and production
    • Other features
      • Development tools: Choice of tools for developer productivity
      • Web Services: Enterprise Web Services for SOA
      • TopLink: Persist application data to stores with performance and productivity. It works in a way similar to Hibernate L2 cache.
      • Spring: Enable flexible choice of dev frameworks with same WebLogic QOS

    Production and Support Perspective

    WebLogic 10 provides a tool: JRockit Mission Control

    • monitors more than 150 parameters:
    • CPU
      • memory
      • leaks
      • latency spikes
      • threads
      • object references
      • JDBC connections
      • JMS
      • pools
      • clusters
      • configuration files
      • etc.
    • allows to compare WebLogic domains
    • Runtime Analyzer: runtime capture for offline analysis, Garbage Collector analysis, etc.

    Coherence – ActiveCache

    Coherence is the Data Grid offered by Oracle. It allows to store Java objects in memory, and share them between all instances. From a certain viewpoint, Coherence looks like the GigaSpaces.

    Roadmap for Future WebLogic Releases

    • Support of Java EE 6 (ratified by the community in last December)
    • OSGi deployment
    • More native integration for WebLogic Server – Coherence – Oracle Database
    • JRockit Flight Recorder for constant record
    • Virtualization
    • More integration with Maven, Hudson and Cruise Control
    • Shared Library: use the same JAR for many applications, rather than packing the same JAR in different EARs.
    • On long term:
      • IDE
        • NetBeans to be oriented onto J2ME development
        • JDevelopper to remain Oracle strategic IDE
        • Contributions to Eclipse to go on
      • JRockit and Sun HotSpot JVMs to be merged.