In This Section

Overview

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

Understanding Detached Threads

Understanding Disruptors

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. Note that when running in an XVM you will see aep engine threads created for the XVM's admin application which is used to handle xvm admin requests.
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	X-ODS-StoreLog-<appName>.in	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	X-ODS-StoreLog-<appName>.out	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
Bus Binding Opener	X-AEP-BusManager-BindingOpener-<appName>. <busName>	No	Each bus configured for your application is managed by a Bus Manager internal to the aep engine. Handles establishment of the bus connects and reconnects.
Store Threads	Each store instance will minimally create a replication reader thread which handle reading from peers. When a store is clustered
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	X-ODS-StoreLog-<storeName>-<instanceid>	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	X-ODS-StoreReplicatorSender-<storeName>-<memberName>	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	X-ODS-StoreReplicatorDispatcher-<storeName>-<memberName>	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.
Store Acceptor Thread	X-ODS-StoreLinkAcceptor-<instanceid>	No	Each store configured for clustering will create a thread that will listen for connection requests from other store members. Once the connection is established it is handed off to the store reader thread for processing.
Miscellaneous
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.
Scheduler	X-Scheduler-<instance-count>	No	A timer thread used for scheduling events. An AepEngine uses this, for example to perform period engine health checks.

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.

Each discovery provider typically will create additional threads specific to the discovery provider type. For example when using an SMA based discovery provider message bus binding threads will be created.

XVM Threads

Thread

Name

Critical Path

XVM main thread

X-Server-<xvmName>-Main

No

This thread creates and starts applications at startup and upon completion will drive server acceptors for accepting admin and direct connections to the xvm.

XVM stats collector

X-Server-<xvmName>-StatsRunner

No

Collects stats for applications, and populates them into heartbeats that can be traced, logged, dispatched, and emitted.

XVM dedicated IO thread

X-Server-<xvmName>-IOThread-<threadNumber>

Yes

When the server is configured for multithreading, additional IO threads beyond the XVM main thread are created that service connections that are affinitized to it.

When using the direct binding the IO thread is on the critical path for received messages.