Support unsigned 64-bit integers for sequence numbers

[JohnGreenan]

Is your feature request related to a problem? Please describe. Per https://www.fixtrading.org/groups/continuousmkts/ Sequence number resets are a bore.

Describe the solution you'd like The implementation proposed is to use an unsigned 64 bit integer for a sequence number.

Using 1 billion sequence numbers per second, that will last for 584 years until they run out.

So we can leave the problem to our great, great, great (more) grandchildren to solve!

Describe alternatives you've considered See attached "Continuous Markets WG- 24x7 FIX Best Practise Working Draft_v0.014.docx"

Additional context Add any other context or screenshots about the feature request here. Continuous Markets WG- 24x7 FIX Best Practise Working Draft_v0.014.docx

[chrjohn]

Note to self:

• fields with data type SeqNum need to be changed (this will probably only work with a custom build, just like with BigDecimal for decimal fields, but need to investigate)
• we should make sure that there are no endless resends or OOM conditions so we should also add a configuration which can restrict resends to n messages (this will also be helpful today already)

[JohnGreenan]

FIX 4.3 added a “datatype” of SeqNum FIX 4.4 uses a “datatype” of SeqNum for the following fields: 7, 16, 34, 36, 45, 369, 630, 789 FIX 5.0 SP2 EP276 uses a “datatype” of SeqNum for the following fields: 1182, 1183, 1350, 1399, 1181, 7, 16, 630, 369, 34,36, 789, 1357, 45 So the full solution is to change the SeqNum datatype to uint64

[chrjohn]

Thanks @JohnGreenan

[JohnGreenan]

See also https://github.com/da4089/simplefix/issues/50 https://github.com/quickfix-j/quickfixj/issues/621 https://github.com/quickfix/quickfix/issues/419 https://github.com/ferrumfix/ferrumfix/issues/108 https://github.com/connamara/quickfixn/issues/760 https://github.com/paritytrading/philadelphia/issues/365 https://github.com/jcass77/WTFIX/issues/8 https://github.com/real-logic/artio/issues/480

[chrjohn]

(at least) one more thing: database setup scripts need to change (and to check which data types need to be chosen). E.g. Postgres script only has INTEGER now. Probably need to use NUMERIC. See https://www.postgresql.org/docs/current/datatype-numeric.html

One more other thing: as written here https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html the Long datatype can be used to represent an unsigned integer:

In Java SE 8 and later, you can use the long data type to represent an unsigned 64-bit long, which has a minimum value of 0 and a maximum value of 2^64-1. Use this data type when you need a range of values wider than those provided by int. The Long class also contains methods like compareUnsigned, divideUnsigned etc to support arithmetic operations for unsigned long.

[chrjohn]

Fields.xsl needs to change to not use int.

In general I think changing the data type should not affect most users because the seqnum fields shouldn't be processed by user applications anyway. Maybe for logging or monitoring?!

[chrjohn]

Another thing to take care of: getting messages from the store for resends is usually done through some kind of list with max capacity of Integer.MAX_VALUE. But getting such large lists should probably be forbidden anyway to guard against OOME.

[philipwhiuk]

I'd have saved myself some bother had I fixed the aside you pointed out above! As it is the above issue covers the resend problems.

[JohnGreenan]

Now adopted https://www.fixtrading.org/packages/fix-recommended-practices-24x7-sessions/