Posts Tagged ‘architecture’

In a reflective talk at Devoxx Belgium 2024, Gregor Hohpe, a veteran architect, shared insights from two decades of experience in “Thinking Like an Architect.” Hohpe debunked the myth of architects as all-knowing decision-makers, instead portraying them as “IQ boosters” who enhance team decision-making through models, metaphors, and multi-level communication. Despite a minor issue with a clicker during the presentation, his engaging delivery and relatable examples, like the “architect elevator,” offered practical strategies for navigating complex organizational and technical landscapes.

Connecting Levels with the Architect Elevator

Hohpe introduced the “architect elevator,” a metaphor for architects’ role in bridging organizational layers—from developers to executives. He argued that the most valuable architects connect business strategy to technical implementation, translating complex trade-offs into terms executives understand without oversimplifying. For example, automation and frequent releases (developer priorities) enable security and cost-efficiency (executive concerns). This connection counters the isolation caused by layered organizations, where management may assume all is well due to buzzwords like Kubernetes, while developers operate with unchecked freedom.

Seeing More Dimensions in Decision-Making

Architects expand solution spaces by revealing additional dimensions, Hohpe explained. Using a sketch of a cylinder mistaken as a circle or rectangle, he showed how architects resolve debates—like speed versus quality—by introducing options like automated testing. At AWS, Hohpe tackled vendor lock-in by framing it as a two-dimensional trade-off: switching costs versus benefits. This approach, inspired by Adrian Cockcroft’s analogy of marriage as “accepted lock-in,” fosters rational discussions, avoiding binary thinking and helping teams find balanced solutions.

Selling Options to Defer Decisions

Hohpe likened architects to options traders, deferring decisions to reduce uncertainty. For instance, standard APIs allow language flexibility, sacrificing some protocol options to gain adaptability. In a financial firm, he explained this to executives using options trading, noting that options’ value rises with volatility—a concept they instantly grasped via the Black-Scholes formula. This metaphor underscores architecture’s increasing relevance in uncertain environments, aligning it with agile methodologies, which thrive under similar conditions. However, options come at the cost of complexity, a trade-off architects must weigh.

Zooming In and Out for System-Wide Perspective

To tackle complexity, architects must zoom in and out, balancing local and global optima. Hohpe illustrated this with two systems using identical components but different connections, yielding opposite characteristics (e.g., latency versus resilience). Local optimization, like perfecting a single component, often fails to ensure system-wide success, as seen in operations where “all lights are green, but nothing works.” By viewing systems holistically, architects ensure decisions align with broader goals, avoiding pitfalls like excessive layering that propagates changes unnecessarily.

Using Models to Navigate Uncertainty

Hohpe emphasized models as architects’ best tools for simplifying complexity. Comparing geocentric and heliocentric solar system models, he showed how the right model makes decisions obvious, even if imperfect. Models vary by purpose—topographical maps for hiking, population density for logistics—requiring architects to choose based on the question at hand. In uncertain environments, models shine by forcing assumptions, enabling scenario-based planning (e.g., low, medium, high user loads). Hohpe urged architects to avoid absolutes, embracing shades of gray to find optimal trade-offs.

Links:

• Devoxx Belgium 2024
• The Architect Elevator
• Cloud Strategy by Gregor Hohpe
• Adrian Cockcroft’s Blog
• Black-Scholes Formula

Hashtags: #SoftwareArchitecture #ArchitectMindset #AgileArchitecture #DevoxxBE2024

In the ever-shifting sands of software demands, where agility trumps rigidity and evolution outpaces stasis, Chris Sainty, a distinguished software architect and Microsoft MVP, advocates for a paradigm that embraces flux: Vertical Slice Architecture (VSA). With a wealth of experience in .NET ecosystems, Chris dissects the frailties of conventional layered paradigms, illuminating how VSA fosters adaptability, accelerates onboarding, and scales with success. His exposition, laced with pragmatic examples, challenges developers to reimagine structures that prioritize features over foundations, ensuring applications remain responsive to the inexorable tide of transformation.

Chris commences by lauding the endurance of layered architectures—presentation atop business logic atop data—yet probes their perils in contemporary contexts. As customer whims whirl and scaling surges demand swift pivots, layers ossify into obstacles, encumbering change with cross-tier tangles. VSA, conversely, carves applications into self-contained verticals—end-to-end features encapsulating all concerns—streamlining modifications and magnifying modularity. This feature-centric ethos, Chris argues, aligns with modern mandates: rapid iterations, effortless extensions, and intuitive ingress for new contributors.

Deconstructing Layers: Pitfalls of Traditional Tiering

Layered designs, Chris elucidates, excel in abstraction but falter in flux. Modifications ripple across strata—tweaking data access mandates presentation perturbations—breeding brittle bonds. Scaling amplifies agony: monolithic services swell, onboarding overwhelms with navigational nightmares. Chris recounts teams ensnared in “god classes,” where logic leeches into controllers, defying single-responsibility tenets.

VSA liberates by slicing vertically: each feature owns its orchestration, from input validation to persistence, minimizing interdependencies. In ASP.NET Core, MediatR handlers embody this, encapsulating requests with validators, mappers, and repositories. Chris demonstrates: a “Create Order” vertical integrates all facets sans layer leaks, easing evolution as requirements refine.

Trade-offs temper triumph: VSA risks redundancy in shared utilities, yet Chris counters with judicious extraction—domain entities for rules, infrastructure abstractions for emails—preserving purity without proliferation. His verdict: layers for legacy, VSA for vitality.

Embracing Verticals: Accelerating Agility and Onboarding

VSA’s virtues shine in speed: altering a feature confines chaos to its silo, slashing cycle times. Chris illustrates with e-commerce: updating checkout logic spans one slice, not sprawling services. Onboarding accelerates—newcomers grasp endpoints holistically, sans layer labyrinths—fostering faster fluency.

Scaling surges seamlessly: verticals deploy independently, microservices materialize modularly. Chris cautions misconceptions: VSA isn’t anarchy—tests tether slices, conventions coerce cohesion. In .NET, minimal APIs map verticals directly, ditching controllers for clarity.

His horizon: VSA as mindset, marrying DDD’s domains with feature focus, empowering teams to thrive amid tumult.

Navigating Nuances: Sharing Savvy and Strategic Choices

Code sharing, a VSA specter, resolves via domains: encapsulate business invariants—aggregates, entities—reusable across verticals, insulating infrastructure. Chris debunks duplication dogmas: external concerns like databases or notifications warrant abstraction, not replication, ensuring efficiency without entanglement.

Strategic selection: VSA suits volatile domains; layers linger in stable spheres. Chris’s compass: assess change cadence—frequent flux favors verticals.

Forging Forward: Building for the Inevitable

Chris’s capstone: architectures architect for alteration. VSA, with its slice-centric simplicity, equips ensembles to navigate novelty, nurturing nimble, navigable codebases that celebrate change.

Links:

• Chris Sainty on LinkedIn

In the dynamic crucible of organizational transformation, where business and technology converge, Vilde Opsal, an architect at FINN.no, narrates a saga of redrawing domain boundaries amidst a Nordic merger. As FINN.no and Schibsted Nordic Marketplaces shifted from horizontal silos to vertical units, Vilde orchestrated a domain-driven design (DDD) odyssey, harmonizing legacy maps with new strategies. Her case study, vibrant with real-world trials, illuminates how to craft domain boundaries that evolve with stakeholders, blending art, agility, and audience empathy.

Vilde frames her talk as a TV show, casting herself as the architect alongside product leads, developers, and a “big boss.” FINN.no’s reorganization—merging four marketplaces into a Nordic entity—demanded a new domain map to support independent verticals. Her mission: align historical domains, new teams, and strategic shifts, ensuring boundaries serve both immediate needs and long-term visions.

Crafting the Canvas: Principles of Domain-Driven Design

DDD, Vilde asserts, is an art, not a science. She begins with core tenets: domains as cohesive problem spaces, bounded contexts as clear partitions. At FINN.no, legacy boundaries—tied to functional areas like payments or listings—clashed with vertical ambitions. Her approach: engage stakeholders collaboratively, mapping domains via workshops that blend business goals with technical realities.

Vilde’s toolkit includes event storming, visualizing user journeys to delineate domains. For instance, real estate verticals prioritized distinct user journeys, while cars focused on transactional flows. This divergence necessitated tailored boundaries, ensuring each vertical’s autonomy while maintaining shared services like authentication.

Adapting to Audiences: Evolving Boundaries Over Time

Boundaries evolve, Vilde notes, as teams and goals shift. Early in the merger, real estate teams preserved legacy setups, minimizing disruption, while car verticals embraced user-centric journeys. She experimented with visualizations—temperature gauges, tables—to communicate progress, finding simplicity trumped flair. A table, mapping current versus aspirational states, resonated most, aligning diverse stakeholders.

Her insight: meet audiences where they are. Developers craved technical granularity; executives sought strategic clarity. By tailoring visualizations—diagrams for tech, narratives for business—Vilde bridged divides, ensuring domain maps clicked and stuck.

Balancing Pragmatism and Vision: Iterative Refinement

Pragmatism guided FINN.no’s journey. One vertical, pressed for time, made local decisions, deferring holistic reviews. Another, post-transformation, leaned on jobs-to-be-done, aligning domains to user needs. Vilde’s lesson: flexibility fosters progress. Iterative refinements, validated through experiments, ensured boundaries adapted to new stakeholders, like Nordic partners.

Her capstone: DDD thrives on dialogue. By fostering continuous feedback—workshops, retrospectives—teams co-create boundaries, balancing agility with coherence.

Embracing the Art: Making Domains Click

Vilde’s finale underscores DDD’s artistry: no universal blueprint exists. Success lies in experimentation, stakeholder alignment, and persistent iteration. Her challenge: craft domains that resonate, guiding teams from chaos to clarity with empathy and precision.

Links:

• FINN.no company website
• Schibsted company website
• Vilde Opsal on LinkedIn

In the sprawling digital expanse of Norway’s welfare agency, NAV, where 143 million lines of code burgeon, Audun Fauchald Strand and Trond Arve Wasskog, principal engineers, confront the Sisyphean challenge of maintenance. Their discourse, a clarion call for strategic reuse, dissects NAV’s labyrinthine codebase, advocating for shared components to curb redundancy. With a nod to domain-driven design and Conway’s Law, Audun and Trond weave a narrative of organizational alignment, technical finesse, and cultural recalibration, urging a shift from ad-hoc replication to deliberate commonality.

NAV, serving Norway’s social safety net, grapples with legacy sprawl. Audun and Trond, seasoned navigators of this terrain, challenge the mantra “reuse should be discovered, not designed.” Their thesis: intentional reuse, underpinned by product thinking, demands ownership, incentives, and architecture harmonized with organizational contours. From open-source libraries to shared services, they map a spectrum of reuse, balancing technical feasibility with social dynamics.

Redefining Reuse: From Code to Culture

Reuse begins with understanding context. Audun outlines NAV’s scale: thousands of developers, hundreds of teams, and a codebase ballooning through modernization. Copy-pasting code—tempting for speed—breeds technical debt. Instead, they champion shared libraries and services, like payment gateways or journaling systems, already reused across NAV’s ecosystem. Open-source, they note, exemplifies external success; internally, however, reuse falters without clear ownership.

Trond delves into Conway’s Law: systems mirror organizational structures. NAV’s fragmented teams spawn siloed solutions unless guided by unified governance. Their solution: designate component owners, aligning incentives to prioritize maintenance over novelty. A payment service, reused across domains, exemplifies success, reducing duplication while enhancing reliability.

Technical Tactics and Organizational Orchestration

Technically, reuse demands robust infrastructure. Audun advocates platforms—centralized APIs, standardized pipelines—to streamline integration. Shared libraries, versioned meticulously, prevent divergence, while microservices enable modular reuse. Yet, technical prowess alone suffices not; social engineering is paramount. Trond emphasizes cross-team collaboration, ensuring components like letter-sending services are maintained by dedicated squads, not orphaned.

Their lesson: reuse is a socio-technical dance. Without organizational buy-in—financing, accountability, clear roles—components decay. NAV’s pivot to product-oriented teams, guided by domain-driven design, fosters reusable assets, aligning technical solutions with business imperatives.

Navigating Pitfalls: Ownership and Maintenance

The core challenge lies in the “blue box”—NAV’s monolithic systems. Audun and Trond dissect failures: reused components falter when unowned, leading to outages or obsolescence. Their antidote: explicit ownership models, where teams steward components, supported by funding and metrics. They cite successes—journaling services, payment APIs—where ownership ensures longevity.

Their vision: an internal open-source ethos, where teams contribute to and consume shared assets, mirrored by external triumphs like Kubernetes. By realigning incentives, NAV aims to transform reuse from serendipity to strategy, reducing code bloat while accelerating delivery.

Fostering a Reuse-First Mindset

Audun and Trond conclude with a cultural clarion: reuse thrives on intentionality. Teams must evaluate trade-offs—forking versus libraries, services versus platforms—within their context. Their call to action: join NAV’s mission, where reuse reshapes welfare delivery, blending technical rigor with societal impact.

Links:

• NAV company website
• Audun Fauchald Strand on LinkedIn
• Trond Arve Wasskog on LinkedIn

Introduction

Julien Topçu, a tech lead at LesFurets, delivers a concise yet powerful Devoxx France 2023 quickie titled “L’architecture hexagonale en 15 minutes.” In this 17-minute talk, Topçu introduces hexagonal architecture (also known as ports and adapters) as a solution for building maintainable, testable systems. Drawing from his experience at LesFurets, a French insurance comparison platform, he provides a practical guide for developers navigating complex codebases.

Key Insights

Topçu explains hexagonal architecture as a way to decouple business logic from external systems, like databases or APIs. At LesFurets, where rapid feature delivery is critical, this approach reduced technical debt and improved testing. The architecture organizes code into:

• Core Business Logic: Pure functions or classes that handle the application’s rules.

• Ports: Interfaces defining interactions with the outside world.

• Adapters: Implementations of ports, such as database connectors or HTTP clients.

Topçu shares a refactoring example, where a tightly coupled insurance quote system was restructured. By isolating business rules in a core module, the team simplified unit testing and swapped out a legacy database without changing the core logic. He highlights tools like Java’s interfaces and Spring’s dependency injection to implement ports and adapters efficiently. The talk also addresses trade-offs, such as the initial overhead of defining ports, balanced by long-term flexibility.

Lessons Learned

Topçu’s insights are actionable:

• Decouple Early: Separating business logic prevents future refactoring pain.

• Testability First: Hexagonal architecture enables comprehensive unit tests without mocks.

• Start Small: Apply the pattern incrementally to avoid overwhelming teams.

These lessons resonate with developers maintaining evolving systems or adopting Domain-Driven Design. Topçu’s clear explanations make hexagonal architecture accessible even to newcomers.

Conclusion

Julien Topçu’s quickie offers a masterclass in hexagonal architecture, proving its value in real-world applications. His LesFurets example shows how to build systems that are robust yet adaptable. This talk is essential for developers aiming to create clean, maintainable codebases.

Orchestrating frontend sprawl for legions of coders while infusing modern stacks like Node.js and React demands architectural ingenuity. Ruben Casas, software engineer at American Express, chronicles their micro-frontend odyssey—a 2016 vanguard yielding seamless compositions for millions, sans monolithic morass.

Ruben’s tale unfurls with a CTO’s conundrum: ballooning teams clash against legacy behemoths, spawning coordination quagmires and sync lags. Microservices scaled backends; frontends craved analogs—autonomous squads wielding isolated codebases, horizontal velocity.

Forging Modular Compositions

Amex’s OneApp framework—open-source beacon—espouses iframe-free integration: Webpack bundles modules to CDN artifacts, runtime loaders fetch per-route payloads. Ruben diagrams: root orchestrates, injecting via shadow DOM for scoped styles/scripts, mitigating clashes.

Prod hums via module maps—versioned manifests—pulling from CDNs; updates propagate sans restarts, hot-swapping in-memory. Development mirrors: Docker-spun OneApp proxies local clones amid prod stubs, isolating tweaks.

Deployment Dynamics and Cultural Catalysts

CIs per-repo trigger tests—units, integrations—publishing to CDNs; OneApp ingests, composing fluidly. Ruben lauds scalability: thousands collaborate frictionlessly, upgrades cascade independently.

Yet, patterns, not panaceas—tailor to contexts. OneApp’s GitHub invites forks, embodying Amex’s trailblazing ethos.

Links:

• Ruben Casas on LinkedIn
• American Express Website
• OneApp GitHub

Oliver Wolf, principal consultant and executive board member at INNOQ, challenges conventional architectures with CQRS (Command-Query Responsibility Segregation). A SOA and Java expert, Oliver traces CQRS’s evolution from CQS, demonstrating incremental adoption—from read-write separation to event sourcing. His session, enriched with examples, equips developers to rethink data flows, optimizing for asymmetric workloads in banking and beyond.

CQRS decouples commands (writes) from queries (reads), enabling tailored models. Oliver illustrates phased implementation, culminating in event-sourced systems for auditability and scalability.

From CQS to CQRS: Foundational Concepts

Oliver recalls CQS—Bertrand Meyer’s principle segregating mutators from inspectors. CQRS extends this, allowing distinct read/write models. He demos a simple e-commerce app, splitting a unified model into command (order placement) and query (inventory views).

This separation, Oliver explains, resolves impedance mismatches, enhancing performance.

Incremental Adoption Strategies

Phased rollout minimizes risk: start with asymmetric databases, Oliver advises, using separate stores for reads/writes. He showcases materialized views, syncing via background jobs.

Advanced steps introduce event sourcing: commands emit events, replayed for state reconstruction, ensuring immutability.

Event Sourcing and Distribution

Event sourcing captures changes as immutable logs, Oliver illustrates, rebuilding state on demand. Distribution follows: client/server variants, with web frontends querying dedicated services.

In banking, Oliver notes, CQRS optimizes configurable systems, balancing risk with extensibility.

Guidelines for Application

Oliver urges starting small: identify read-heavy operations, segregate gradually. Avoid over-engineering; CQRS suits complex domains, not simple CRUD.

Community examples, he shares, validate phased approaches, with INNOQ projects exploring hybrid models.

Links:

• Oliver Wolf on LinkedIn
• INNOQ company website

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:

[java]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
[/java]

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:

[java] 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);
}[/java]

Eg#2:

[java] 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);
}
}[/java]

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:
[java] 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;
}
[/java]

On application shutdown

In the method ServletContextListener.contextDestroyed(), let’s call this method:
[java] /**
* 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;
}
[/java]

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:
[xml] <listener>
<listener-class>net.sf.ehcache.constructs.web.ShutdownListener</listener-class>
</listener>
[/xml]
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:
[java]MuleServer.1
SocketTimeoutMonitor-Monitor.1
SocketTimeoutMonitor-Monitor.1
[/java]
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.

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:
  [java]EventTypeEnum getEventEnum();[/java]
• lalou.jonathan.application.web.gwt.animal.handler.EventHandler: generic interface for a component able to handle an event. Abstract method:
  [java]void handleEvent(HandledEvent handledEvent);[/java]
• lalou.jonathan.application.web.gwt.animal.handler.EventHandlerBus: the actual bus. As a concrete class, it has two methods:
  [java]/**
  * 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) {
  // …
  }[/java]

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:
   [java]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;
   }

   }[/java]