How does AMPS handle invalid FIX/NVFIX?

AMPS is designed to balance performance and flexibility. In most cases, AMPS does not guarantee specific behavior with invalid messages.

One common problem with FIX and NFVIX messages is failure to terminate the final field with the FIX SOH character.

The way AMPS deals with these invalid messages differs depending on the release as follows.

Releases before AMPS 4.0

Prior to AMPS 4.0, these messages will be processed by AMPS, but there can be unexpected side effects to sending these invalid FIX/NVFIX messages into AMPS. This is especially true with regards to the use of a SOW file.

For example, consider a SOW with a SOW key configured to be /5. The publisher takes the following actions:

Delta Publish:

1=FOO\x015=TEST1

Delta Publish:

5=TEST1\x012=BAR

Notice that neither of these messages is terminated with an SOH. In this case, it is possible for these messages to be merged into:

1=FOO\x015=TEST12=BAR\x01

This is because AMPS does not add the FIX SOH character to the end of the message when using a version of AMPS older than 4.0.

If AMPS were to be restarted with this message in the SOW file, upon reboot it would not recognize the /5 field as having the original value of TEST1. With this in mind, delta publishing "1=FOO\x015=TEST1" again would not update the message in the SOW file. Instead, it would place a new message in the SOW file.

After the additional message is inserted, issuing a SOW query would return the following results:

1=FOO\x015=TEST1 
1=FOO\x015=TEST12=BAR\x01

Releases 4.0 and newer

Publishing the same data into an AMPS server version 4.0 or newer would create the following message in the SOW file:

1=FOO\x015=TEST1\x012=BAR\x01

Upon restart, AMPS will be able to properly parse this message and identify the /5 field as having a value of TEST1. This will allow delta publishing to work as expected.

Keywords: FIX, NVFIX, missing SOH, invalid FIX, invalid NVFIX