WSO2 APIM Shutdown Events
If you are using WSO2 API Manager for managing the API's lifecycle, it's important to understand the flow when API Manager gets shutdown.
So, whether you're running WSO2 API Manager in production or a test environment, it's critical to understand how it shuts down. A graceful shutdown ensures that no in-flight API requests are abruptly cut off, database connections are properly closed, and services stop cleanly. In this post, we’ll break down the sequence of events that occur when you shut down WSO2 API Manager, and why it matters.
Shutdown can be initiated in several ways:
1. Running the shutdown script:
./wso2server.sh stop
Or
./api-manager.sh stop
2. Sending a termination signal:
kill -15 <PID>
Any of these methods initiate a graceful shutdown via a JVM shutdown hook, which delegates the shutdown process to the Carbon runtime environment WSO2 is built upon.
Series of Events : Behind the Scenes
The process begins when a termination signal is received. This could be manual (Ctrl + C) or via a script.
2. JVM Shutdown Hook
The JVM calls WSO2’s registered shutdown hook, triggering the CarbonServer.shutdown() method. This is where WSO2’s internal lifecycle shutdown begins.
All modules that registered shutdown listeners are notified. This includes internal services like analytics, token management, throttling engines, etc.
Transport listeners (HTTP, HTTPS, JMS, etc.) are stopped. No new requests are accepted from this point.
Any in-progress API requests are allowed to finish. This prevents data corruption and ensures clients don’t receive partial responses.
The Synapse mediation engine powering your APIs, sequences, and endpoints is gracefully shut down.
- WSO2 closes connections to:
- The Registry (for configurations)
- User Stores (LDAP, JDBC)
- Databases (API store, analytics, tokens)
Worker threads, schedulers, and background services are stopped.
Finally, the OSGi container shuts down all WSO2 bundles and services.
Flow Diagram
+------------------------+ | Shutdown Triggered | | (Ctrl+C, stop script) | +----------+-------------+ | v +------------------------+ | JVM Shutdown Hook | | calls CarbonServer | +----------+-------------+ | v +------------------------+ | Notify Lifecycle | | Listeners | +----------+-------------+ | v +------------------------+ | Stop Transports | | (HTTP/HTTPS, JMS) | +----------+-------------+ | v +------------------------+ | Handle Active Requests | +----------+-------------+ | v +------------------------+ | Shutdown Axis2 Engine | +----------+-------------+ | v +------------------------+ | Stop Synapse | | (APIs, Sequences) | +----------+-------------+ | v +------------------------+ | Close DB/Registry Conn | +----------+-------------+ | v +------------------------+ | Shutdown OSGi Bundles | +----------+-------------+ | v +------------------------+ | Shutdown Complete | +------------------------+
Why Graceful Shutdown ?
A clean shutdown helps to prevent:
- Corrupted log or token data
- Losing the API analytics
- Partially executed sequences / policies
- Issues during startup (e.g., stuck deployment synchronizers or DB locks)
It’s also essential for Kubernetes deployments, CI/CD pipelines, and when automating WSO2 lifecycle operations.
Key Takeaways
--------------------------------------------------------------- | Component | Shutdown Action | | -------------- | ------------------------------------------ | | HTTP/HTTPS | Stops accepting new requests | | Axis2 Services | Unregisters and stops message mediation | | Synapse Engine | Terminates sequences, APIs, and tasks | | DB Connections | Closed and flushed | | OSGi Bundles | All internal components stopped gracefully | ---------------------------------------------------------------
Comments
Post a Comment