[QFJ-88] Communication failure Market Data from HotSpot Created: 18/Oct/06  Updated: 15/Nov/06  Resolved: 15/Nov/06

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.0.3
Fix Version/s: None

Type: Other Priority: Default
Reporter: Welf Wustlich Assignee: Steve Bate
Resolution: Fixed Votes: 1
Labels: None
Environment:

linux netbeans


 Description   

We have established a connection to HotSpot to receive market data.
After session start and login, but before we receive tick data, we get a message with the buffered market data.
In the Session-Log there is a message:
SCHWERWIEGEND: Invalid message: Actual body length=120, Expected body length=680
"SCHWERWIEGEND" is german and means crucial.
After some debugging we found the reason. The following incomming message from hotspot:
8=FIX.4.29=68035=X49=HOTSPOT56=OUR-SIDE34=117252=20061018-11:13:55268=25279=0
55=CAD/JPY5071=3279=055=AUD/JPY5071=3279=055=GBP/CHF5071=5279=055=EUR/SEK50
71=5279=055=NZD/USD5071=5279=055=AUD/USD5071=5279=055=EUR/NOK5071=5279=0
55=EUR/AUD5071=5279=055=EUR/CHF5071=5279=055=GBP/JPY5071=3279=055=EUR/USD50
71=5279=055=USD/NOK5071=5279=055=CHF/JPY5071=3279=055=AUD/NZD5071=5279=0
55=USD/JPY5071=3279=055=GBP/AUD5071=5279=055=USD/SGD5071=5279=055=USD/CHF50
71=5279=055=USD/SEK5071=5279=055=USD/CAD5071=5279=055=USD/MXN5071=5279=0
55=GBP/USD5071=5279=055=EUR/GBP5071=5279=055=EUR/JPY5071=3279=055=EUR/DKK5071=510=029
is supposed to have a body length of 680 but quickfix says it has only 120.
We found the reason within the methodes Message.bodyLength and FieldMap.calculateLength.
As you can see the message contains multiple fields with the ID 055, when calculating the length within the method FieldMap.calculateLength only the last quote EUR/DKK is added to the bodylength.
We are not sure if the message from hotspot does not comply the the FIX-spec or quickfix.
It seems that the multiple fields are getting lost like when you add multiple fields into a hashmap.

Best regards, Welf
**************************************************************************************************
SESSION-LOG:
18.10.2006 13:13:54 quickfix.mina.initiator.InitiatorIoHandler sessionCreated
INFO: MINA session created: /172.16.130.130:32820
OUTGOING[13]toAdmin(), SessionID: FIX.4.2:OUR-SIDE->HOTSPOT
LOGON
8=FIX.4.29=11135=A34=1349=OUR-SIDE52=20061018-11:13:55.18856=HOTSPOT98=0108=60553=USER
554=PASSWD10=144
INCOMING[1171]fromAdmin(), SessionID: FIX.4.2:OUR-SIDE->HOTSPOT
LOGON
8=FIX.4.29=8535=A34=117149=HOTSPOT52=20061018-11:13:4956=OUR-SIDE98=0108=6010=073
OUTGOING[14]toAdmin(), SessionID: FIX.4.2:OUR-SIDE->HOTSPOT
RESEND_REQUEST
8=FIX.4.29=8435=234=1449=OUR-SIDE52=20061018-11:13:59.18956=HOTSPOT7=416=010=007
onLogon(): LOGON SUCCESSFUL, SessionID is FIX.4.2:OUR-SIDE->HOTSPOT
INCOMING[4]fromAdmin(), SessionID: FIX.4.2:OUR-SIDE->HOTSPOT
SEQUENCE_RESET
8=FIX.4.29=8935=434=443=Y49=HOTSPOT52=20061018-11:13:4956=OUR-SIDE36=1172123=Y10=043
18.10.2006 13:14:05 quickfix.mina.AbstractIoHandler messageReceived
SCHWERWIEGEND: Invalid message: Actual body length=120, Expected body length=680
OUTGOING[15]toAdmin(), SessionID: FIX.4.2:OUR-SIDE->HOTSPOT
HEARTBEAT
8=FIX.4.29=7535=034=1549=OUR-SIDE52=20061018-11:15:00.18956=HOTSPOT10=124

 Comments   
Comment by Steve Bate [ 18/Oct/06 ]

Are you sure you are using a data dictionary to parse the message. Groups cannot be parsed correctly without a data dictionary and duplicate fields are only allowed in the context of a repeating group.

Comment by Sebastian Larsson [ 01/Nov/06 ]

Think I finally got my head around this problem.
It boils down to this reasonable statement:
If your counterparty's idea of the FIX schema does not agree with what is in the appropriate FIX4x.xml file the message will fail to validate.

In my case:
MsgType(35)="W", in group NoMDEntries(268): tag MDEntryID(278) is not allowed according to FIX43.xml
In the original post:
MsgType(35)="X", in group NoMDEntries(268): tag ??(5071) is not allowed according to FIX42.xml

When the group parsing routine finds the invalid tag it drops out of the group parsing and parses the rest of the group information as if it
were fields associated with the parent. Repeated tags succesively over-write eachother resulting in a much shorter message than expected
which contains only the data in the last group entry (plus whatever was successfully parsed into the group from the first entry).

I'm not very well versed in the FIX standard(s) so I'm not able to tell if the problem is with the FIX4x.xml files being wrong or if the error is at the counterparties' end.

In short, this is not a bug in the code. If the incomming message is not valid according to the xml file specification it will fail to validate.
There might be errors in the .xml files, but I'm not qualified to say.

However, it would have been more user friendly if the parsing routine had thrown up an 'invlid tag in group' message, rather than the somewhat
more obscure 'Invalid message since it is the wrong length' error. I realize this is not trivial, since the group parsing routine uses unknown
tags as an end-of-group condition so finding one is not an error per se, but it would have saved me quite a bit of time.

Hope this will help sort out the HotSpot problem as well.

Comment by Steve Bate [ 15/Nov/06 ]

Sebastion, I wasn't able to edit the previous comment either so I deleted the comment with the reference to your counterparty.

Welf, is it possible this is the source of the problems you are having with HotSpot?

Generated at Sat May 18 08:23:26 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.