Gliffy Diagram |
---|
name | ApplicationLifecycle Copy |
---|
|
div |
---|
|
div |
---|
| Table of Contents |
---|
maxLevel | 4 |
---|
indent | 16px |
---|
style | none |
---|
|
|
|
...
An X application's lifecycle starts when the application main class is loaded by a Talon XVM and ends when the server invokes the method on the application's main class annotated with the @com.neeve.server.app.annotations.AppFinalizer annotation. The following depicts the application flow from a Talon XVM's standpoint.
div |
---|
style | margin-left:auto; margin-right:auto; text-align:center; |
---|
|
Gliffy Diagram |
---|
| |
---|
chrome | min |
---|
html5 | false |
---|
name | ApplicationLifecycle |
---|
|
|
Load Phase
Anchor |
---|
| TalonApplicationLoadPhase |
---|
| TalonApplicationLoadPhase |
---|
|
...
After config injection, the Talon XVM moves onto parsing the application's command handlers. This is done by first using the following method on the application's main class to fetch the set of application objects that contain the application's command handlers and then parse those objects for command handlers.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppCommandHandlerContainerAccessor
public void addCommandHandlerContainerObjects(Set<Object> containers) {...} |
Discover Command Handlers
Command handler methods are annotated with the @com.neeve.server.app.annotations.AppCommandHandler annotation. The following is an example of a command handler.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppCommandHandler(command="printhelloworld")
public String helloWorld(String command, String[] args) {
System.out.println("Hello World!");
} |
After collating all the command handler container objects obtained via the previous step, the server then parses the objects for command handlers.
Note |
---|
Command handler container objects can also contain non-command handler methods. Those methods will be ignored by the server command handler parser machinery. |
Get AppStat Containers
Along with discovering command handlers, the Talon XVM also discovers additional objects that contain @AppStats. This is done by first using the following method on the application's main class to first fetch the set of application objects that contain the application's AppStats, and then introspecting those objects.
Code Block |
---|
|
// Note that the method name is unimportant.
@com.neeve.server.app.annotations.AppStatContainerAccessorAppStatContainersAccessor
public void addAppStatContainerObjects(Set<Object> containers) {...} |
Discover AppStats
AppStats can be be exposed by either methods or fields on the App's main class or in one of the AppStatContainers exposed above by annotating the field or method with the @com.neeve.server.app.annotations.AppStat annotation. Introspection for application stats is done just before the AepEngine is injected into the application. See User-Defined App Stats for additional details.
Get Event Handler Containers
After parsing the command handlers, the Talon XVM parses the application's event handlers. This is done by using the following method on the application's main class to first fetch the set of application objects that contain the application's event handlers and then parsing those objects for event handlers.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppEventHandlerContainerAccessorAppEventHandlerContainersAccessor
public void addEventHandlerContainerObjects(Set<Object> containers) {...} |
Discover Event Handlers
Event handler methods are those that are annotated with the @com.neeve.aep.annotations.EventHandler annotation. Event handlers are single argument methods that contain an event or a message type as their argument. The Talon XVM and AEP engine dispatch events to the application event handlers. The following are some examples of event handlers.
Code Block |
---|
|
@com.neeve.aep.annotations.EventHandler
public void onEngineActivated(final com.neeve.aep.event.AepEngineActiveEvent event) {...); |
Code Block |
---|
|
@com.neeve.aep.annotations.EventHandler
public void onOrder(final NewOrderMessage message) {..}; |
After collating all the event handler container objects obtained via the previous step, the server then parses the objects for event handlers. The parsed event handlers are used by both the server and the AEP engine to dispatch events to the application.
Note |
---|
Event handler container objects can contain non event handler methods. Those methods will be ignored by the server and AEP engine event handler parser machinery. |
Get Default Event Handler
Next, the server fetches the application's default event handler via the method annotated with @com.neeve.server.app.annotations,AppEventHandlerAccessor on the application main class.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppEventHandlerAccessor
public IEventHandler getDefaultEventHandler() {...} |
Depending on configuration, the default event handler is used to either dispatch events that are not handled by any other event handler (DefaultHandlerDispatchPolicy=DispatchIfNoAnnotatedHandlers (default)) or to always dispatch events regardless of whether the event was dispatched to other annotation based event handlers or not (DefaultHandlerDispatchPolicy=DispatchAlways)
Get Application State Factory
The final step performed by the server before creating the application's engine is to fetch the application's state factory (for State Replicated applications). This is done via the method on the application's main class annotated with the @com.neeve.server.app.annotations.StateFactoryAccessor annotation.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppStateFactoryAccessor
public IAepApplicationStateFactory getStateFactory() {...} |
Create Engine
At this point, the server has all the information needed to create the application's AEP engine. The engine is thus created in this step. See below for more detail on the engine creation flow.
Inject Engine
After creating the engine, the server injects the engine into the application's main class. This is done by using the engine injection method in the main application class.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppInjectionPoint
public void setEngine(final com.neeve.aep.AepEngine engine) {...} |
Initialize Application
The final step in this phase of the application lifecycle is to initialize the application. This is done via the method on the application's main class annotated with the @com.neeve.server.app.annotations.AppInitializer annotation.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppInitializer
public void initialize() {...} |
Start Phase
Start Engine
The only act performed in the start phase is to start the engine. The act of starting the engine will determine whether the started engine is the primary or a backup in the application's cluster. If primary, messages will start flowing to the application. If backup, messages and/or state will be replicated in real time from the primary to the backup to keep the backup's state in sync with the primary. If the primary fails, the backup elected as primary will open its messaging machinery and messages will start flowing to the application for processing. See below for more detail on the engine start flow.
Run Phase
Event Driven Applications
X Applications are message/event driven applications. For such applications, nothing additional needs to be done to enter the run phase. Once the engine has been started, messages and/or events will be dispatched to the application thus driving its operation.
Synchronous Applications
For applications that are not event driven, i.e. "sender" only type applications that synchronously drive their own operation, the server provides the facility for the applications to implement the "main" method. The server identifies the method in the application's main class annotated with @com.neeve.server.app.annotations.AppMain to be the application's main method. If such a method is discovered, then the server spins up a separate thread that invokes the application main method. The following is an example of an application main method.
Code Block |
---|
|
@com.neeve.server.app.annotations.AppMain
public void main() {...} |
Stop Phase
Stop Engine
The only act performed in the stop phase is to stop the engine. See below for more detail on the engine stop flow.
Close Phase
Finalize Application
The last step executed by the Talon XVM in the application lifecycle is to invoke the application's finalize method, i.e. the method in the application's main class annotated with the @com.neeve.server.app.annotations.AppFinalizer annotation
Code Block |
---|
|
@com.neeve.server.app.annotations.AppFinalizer
public void finalise() {...} |
Engine Lifecycle
The following depicts the overall lifecycle of an AEP engine.
Gliffy Diagram |
---|
| |
---|
chrome | min |
---|
html5 | false |
---|
name | EngineLifecycle |
---|
|
Create Engine
The following depicts the creation flow of an AEP engine.
...