> For the complete documentation index, see [llms.txt](https://docs.xplatform.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xplatform.com/release-notes/3.16/3.16.41/talon-3.16.79.md).

# Talon 3.16.79

<mark style="color:green;">Release Date: Monday, August 24, 2026</mark>

## Compatibility Notes

No issues have compatibility implications

## Change Summary

* [Improvement](#improvement)
  * [TALON-153 - ADM: add @JsonProperty and @JsonIgnore annotations to generated interfaces for consistency with impls](#talon-153)
* [Bug](#bug)
  * [TALON-154 - NullPointerException in latency-optimized AEP Engine with per-transaction stats enabled](#talon-154)
  * [TALON-155 - Native lib auto-extraction races between concurrent JVMs](#talon-155)
  * [TALON-156 - Messaging docs do not contain the wire-format reference](#talon-156)
  * [TALON-161 - Messaging docs do not explain how an inbound message is mapped back to a channel](#talon-161)
  * [TALON-162 - Modeling-language docs points to a 'poolable string types' section that does not exist](#talon-162)

## Improvements <a href="#improvement" id="improvement"></a>

### TALON-153 <a href="#talon-153" id="talon-153"></a>

<mark style="color:orange;">ADM: add @JsonProperty and @JsonIgnore annotations to generated interfaces for consistency with impls</mark>

Prior to this release, the ADM code generator placed @JsonProperty and @JsonIgnore annotations only on generated implementation classes. The corresponding generated interfaces lacked these annotations, leading to inconsistent Jackson serialization behavior when the interface type was used as the serialization target. This release updates the generator to emit matching @JsonProperty and @JsonIgnore annotations on generated interfaces.

## Bugs <a href="#bug" id="bug"></a>

### TALON-154 <a href="#talon-154" id="talon-154"></a>

<mark style="color:orange;">NullPointerException in latency-optimized AEP Engine with per-transaction stats enabled</mark>

An AEP engine running with a latency optimized configuration could shut down with a NullPointerException while committing a transaction. The problem was most readily observed with per-transaction statistics capture enabled, and some deployments worked around it by disabling that capture in production.

You are affected if you run a latency optimized engine configuration and have seen an engine shut down with a stack trace of the following shape:

```
java.lang.NullPointerException
  at com.neeve.aep.AepEngine$Transaction.doSendCommit(AepEngine.java:...)
  at com.neeve.aep.AepEngine$Transaction.onStoreCommitComplete(AepEngine.java:...)
  at com.neeve.aep.AepEngine.onStoreCommitComplete(AepEngine.java:...)
  at com.neeve.aep.AepEngine.onEvent(AepEngine.java:...)
  at com.neeve.ods.impl.StoreBindingImpl.onCommitComplete(StoreBindingImpl.java:...)
  at com.neeve.ods.impl.StoreReplicator.handleCommitAck(StoreReplicator.java:...)
  ...
```

Engines that are not tuned for latency are not affected.

This has been fixed. Per-transaction statistics capture can be left enabled in production.

Two engine configuration settings have been added as part of the fix, `leg2InStoreThread` and `leg2CompletionTimeout`. Both default to values that require no action on upgrade. They are described in the Transaction Commit Legs section of the Transactions concept guide and in the Configuration Reference.

See [Transaction Commit Legs](/talon/concepts-and-architecture/transactions.md#transaction-commit-legs) and the [Configuration Reference](/talon/reference/configuration.md).

### TALON-155 <a href="#talon-155" id="talon-155"></a>

<mark style="color:orange;">Native lib auto-extraction races between concurrent JVMs</mark>

Two or more JVMs starting at the same time could race while extracting the bundled native libraries, and a JVM could load a library file that had only been partially written.

You are affected if you start multiple processes concurrently that share the native library directory configured by `nv.native.libdir`. The failure appears during JVM startup, as a library load error or a crash, and is intermittent because it depends on the relative timing of the starting processes.

This has been fixed and concurrent starts against a shared directory are now safe. The previously documented workaround of extracting the libraries separately and setting `nv.native.suppressextraction=true` is no longer required for multi-instance deployments, and continues to work where it is already in use.

Extraction is now skipped when the destination directory already holds the current set of libraries, so repeat starts no longer re-extract unnecessarily. Any change to the bundled libraries, including SNAPSHOT and locally rebuilt versions where the version string does not change, is detected and triggers a fresh extraction.

See [Native Libraries](/talon/operating-applications/deployment/native-libraries.md).

### TALON-156 <a href="#talon-156" id="talon-156"></a>

<mark style="color:orange;">Messaging docs do not contain the wire-format reference</mark>

Prior to this release, the Talon documentation site did not have a foundational reference page for message serialization at the wire level — the legacy "Understanding Message Serialization" Confluence page was not ported, and only per-binding integration recipes were available on the new site. This release adds a standalone "Understanding Message Serialization" reference page covering the engine-independent serializer API exposed by com.neeve.sma.MessageView, the SMA MessageMetadata field reference (with corrected MessageEncodingType values), and the V1/V2 byte-by-byte wire layout. The same page is published on the Rumi documentation site under the messaging-model section, with Rumi terminology applied.

See [Understanding Message Serialization](/talon/concepts-and-architecture/messaging-model/understanding-message-serialization.md).

### TALON-161 <a href="#talon-161" id="talon-161"></a>

<mark style="color:orange;">Messaging docs do not explain how an inbound message is mapped back to a channel</mark>

Prior to this release, the messaging documentation described how messages are mapped to channels and how channel keys become topics, but did not describe how a received message is mapped back onto a channel. The messaging model documentation now covers inbound channel resolution: the channel id and name carried in message metadata, the rule that an id of -1 or 0 means no id was sent, resolution by name or by id, the catch-all channel and its default-off behaviour, and the fact that a message which resolves to no channel is reported as unhandled without invoking any message handler.

See [Messaging Model](/talon/concepts-and-architecture/messaging-model.md).

### TALON-162 <a href="#talon-162" id="talon-162"></a>

<mark style="color:orange;">Modeling-language docs points to a 'poolable string types' section that does not exist</mark>

Prior to this release, the modeling-language documentation referred readers to a "poolable string types" section that did not exist in the documentation, leaving the one exception to the semantic-type rule unexplained and the poolable-string code-generator directives documented without any description of the feature they configure. This release restores that section.

See [The Modeling Language](/talon/developing-applications/modeling-messages-and-state/the-modeling-language.md).