Open JohnGreenan opened 1 year ago
Note to self:
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)n
messages (this will also be helpful today already)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
Thanks @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
(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.
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?!
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.
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.
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