In This Section

Overview

Before jumping into this section, be sure to read through The Talon Application Flow.

Listing of Threads

Talon Applications

Thread	Name	Critical Path	Description
AEP Engine Input Multiplexer	X-STEMux-<appName>-<instanceid>	Yes	The engine thread that dequeues and dispatch application messages and events. This is the main application thread on which application events are dispatched. They are suffixed with a global counter to allow differentiating between stats emited by multiple instances of the same application running in the same jvm. The detached threads described outlined below can offload work from this thread which can improve throughput and latencies in your application.
AEP Engine Input Multiplexer	X-EventMultiplexer-Wakeup-<appName>	No	A timer thread use to wake up and dispatch events scheduled via the engine's input queue.
Detached Inbound Message Logger		No	When the application is configured with a detached inbound message logger, this thread offloads the work of writing to disk from the engine's input multiplexer which can serve as a buffer against disk I/O spikes. As Inbound message loggers aren't used for HA purposes they are not on the critical path, If your application's inbound message load is not high, a detached inbound message logger may not be needed. The tleg3 transaction latency statistic covers inbound message logging. High values or spikes is an indicator that a detached inbound message logger can help
Detached Outbound Message Logger		No	When the application is configured with a detached outbound message logger, this thread offloads the work of writing to disk from the engine's input multiplexer which can serve as a buffer against disk I/O spikes. If your application's outbound message load is not high, a detached outbound message logger may not be needed. The tleg3 transaction latency statistic covers outbound message logging. High values or spikes is an indicator that a detached inbound message logger can help
Bus Threads	Each bus configured for your application is managed by a Bus Manager internal to the aep engine. In addition to application configured buses an engine create several internal buses which are not on the critical processing path: control-<uuid>: used for attaching internal aep control events to transactions (for exampling fault tolerant timer related events). client: used as a bus to which admin clients can connect to the application via an XVM rather than over a messaging. Bus binding instances will generally create additional threads specific to the binding type.
Detached Bus Send Thread	X-AEP-BusManager-IO-<appName>.<busName>	Yes	When the bus is configured for detached send, this thread offloads the work of serialization and writing of outbound messages from the engine's input multiplexer which serves as a buffer against spikes caused by message bus flow control. High values in the 'o2p, s, s2w, ws' message bus bindings stats are indicators that a detached bus sender can improve performance
X-AEP-BusManager-BindingOpener-<appName>. <busName>		No
Store Threads	Each store instance will minimally create a replication reader thread which handle reading from peers.
Store Reader Thread	X-ODS-StoreReplicatorLinkReader-<storeName>-<memberName>	Yes	The IO thread for the store which is used to read replication traffic from cluster peers.
Store Detached Persister		No	When the store is configured for detached persistence, this thread offloads the work of writing recovery data to disk from the engine's input multiplexer which can serve as a buffer against disk I/O spikes. High values in the 'pers' (Persistence) store binding stats is an indicator that a detached store sender can improve performance
Store Detached Send Thread		Yes	When the store is configured for detached send, this thread offloads the work of writing recovery data to the network for backup instances from the engine's input multiplexer which can serve as a buffer against network I/O spikes. High values in the 's2w' (Serialize To Wire) store binding stats is an indicator that a detached store sender can improve performance
Store Detached Dispatch Thread		Yes	When the store is configured for detached dispatch, this thread allows the store reader thread to offload work of dispatching deserialized replication traffic to the engine for processing this is useful in cases where the cost of deserializing replication traffic is high. A high value for the the store binding deserialize stat ('d'), can indicate that setting this property could improve throughput or latency.
Stats Printer Threads	X-Stats-Printer [<statName>-<instanceid>.stats]	No	Several components can be configured to trace stats (independently) from XVM collected stats. When such stats threads are enabled a thread is created to periodically print stats. This is typically useful if an app is run outside of an XVM.

Discovery Threads

Thread	Thread Name	Critical Path	Description
Discovery Timer	X-EDP-Timer	No	Each discovery provider that is opened will create a timer thread that will periodically wakeup to perform discovery broadcasts

XVM Threads

Thread	Name
The XVM main thread	X-Server-<xvmName>-Main	This thread creates and starts applications at startup and upon completion will driver server acceptors for accepting admin and direct connections to the xvm
The XVM stats collector	X-Server-<xvmName>-StatsRunner	Collects stats for applications, and populates them into heartbeats that can be traced, logged, dispatched, and emitted.

	X-Scheduler-<instance-count>	A timer thread used for scheduling events. An AepEngine uses this, for example to perform period engine health checks.