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
da4089/simplefix#50
#621
quickfix/quickfix#419
ferrumfix/ferrumfix#108
connamara/quickfixn#760
paritytrading/philadelphia#365
jcass77/WTFIX#8
real-logic/artio#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/