RE: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem
Brought to you by:
orenmnero
Menu
▾
▴
RE: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem
|
From: Steve B. <sb...@sm...> - 2006-05-03 16:15:58
|
Wenchao, =20 There is some documentation on the data dictionary, validation, and related topics at... =20 http://www.quickfixengine.org/quickfixj/doc/usermanual/usage/validation. html =20 Yes, the custom field is indirectly causing the problem. You can add the field to the data dictionary by adding a field element with the fields section of the dictionary and then add a reference to the custom field in the group definition for the snapshot message. =20 Note that you don't necessarily have to regenerate the classes after adding the custom field. Just modifying the data dictionary XML will support the validation and parsing of the=20 message. =20 Steve ________________________________ From: Wenchao Tao [mailto:wy...@me...]=20 Sent: Wednesday, May 03, 2006 6:05 PM To: Steve Bate Subject: RE: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem =09 =09 Hi Steve, =20 Thanks for the quick response. For the custom tags, I basically disabled the validation by setting ValidateUserDefinedFields to N in the property file for now. I haven't attempted to modify the default data dictionary files yet. By looking at the trace, the incoming message does seem to put the SecurityType field in the NoMDEntries group, which should be ok, right? Any suggestions as to how to go about resolve this problem in my situation? =20 I'd also like to know the steps in modifying the default data dictionary. I tried to rename the NoMDEntries to NoMDEntriesX (was a simple test), but the quickfixj package failed to compile. So it seems dictionary is also being reference somewhere else. Can you let me know where I can find some info on how to modify the dictionary?=20 =20 I really appreciate your help on this. =20 --Wenchao- =20 =20 =09 ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: Wednesday, May 03, 2006 7:51 AM To: qui...@li... Subject: RE: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem =20 Wenchao, =20 The group information is looked up using the message type and the group count field number. If the group is defined differently for different messages is will be validated differently. Is there any possibility that the security type is defined outside the group? For example, it appears there is a custom tag in the group, 10455=3D6JM6. = I'm guessing you may have added this field to the data dictionary or it would have failed validation. However, if you didn't add the custom field reference inside the NoMDEntries group definition it will trigger the termination of the group parsing. The next field is the security type which is not valid /outside/ the group. =20 Steve =20 =09 ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Wenchao Tao Sent: Wednesday, May 03, 2006 9:10 AM To: qui...@li... Subject: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem Hi,=20 =20 I started coding fix using quickfixj just a few days ago. I am implementing a client that gets realtime data feed from the fix server at our broker. In my program, I send MarketDataRequest, and expect MarketDataSnapshotFullRefresh and MarketDataIncrementalRefresh back. I have no problem with the MarketDataSnapshotFullRefresh, but quickfixj always rejects the MarketDataIncrementalRefresh complaining that tag 167 (SecurityType) is not defined for this message type. I checked the FIX42.xml, and verified that tag 167 is defined for MarketDataIncrementalRefresh under group NoMDEntries. I took a look at the DataDictionary.java, and it seems the validation step searches group definition by name. And the group name is not unique in FIX42.xml. For example, group NoMDEntries appears in MarketDataSnapshortFullRefresh as well as in MarketDataIncrementalRefresh, and the set of tags are different for the two groups. Can this be the cause to the problem? I am attaching the quickfixj trace for reference. Any advice would be greatly appreciated. =20 --Wenchao- =20 =20 =20 [java] <20060503-06:16:06, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D172 35=3DV 34=3D3 49=3DPRICE = 52=3D20060503-06:16:06.776 56=3Dfc 262=3D2001 263=3D1 264=3D1 265=3D1 266=3DY 146=3D1 55=3D6J = 48=3DCME000040287 167=3DFUT 200=3D200606 207=3DCME 267=3D4 269=3D5 269=3D4 269=3D7 269=3D8 = 10=3D110 ) [java] <20060503-06:16:06, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00200 35=3DW 49=3Dfc 56=3DPRICE 34=3D132 52=3D20060503-06:16:06.884 55=3D6J 48=3DCME000040287 10455=3D6JM6 = 167=3DFUT 207=3DCME 262=3D2001 387=3D2087 200=3D200606 268=3D4 269=3D4 270=3D8873 = 269=3D5 270=3D8892 269=3D7 270=3D8893 269=3D8 270=3D8870 10=3D128 ) [java] <20060503-06:16:36, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00056 35=3D0 49=3Dfc 56=3DPRICE 34=3D133 52=3D20060503-06:16:36.884 10=3D207 ) [java] <20060503-06:16:36, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D54 35=3D0 34=3D4 49=3DPRICE = 52=3D20060503-06:16:36.964 56=3Dfc 10=3D217 ) ... [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00161 35=3DX 49=3Dfc 56=3DPRICE 34=3D149 52=3D20060503-06:24:22.472 262=3D2001 268=3D1 279=3D1 55=3D6J = 48=3DCME000040287 10455=3D6JM6 167=3DFUT 207=3DCME 269=3D7 270=3D8894 387=3D2115 = 200=3D200606 10=3D061 ) [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, event> (Message 149 Rejected: Tag not defined for this message type:167) [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D123 35=3D3 34=3D20 49=3DPRICE = 52=3D20060503-06:24:22.556 56=3Dfc 45=3D149 58=3DTag not defined for this message type 371=3D167 = 372=3DX 373=3D2 10=3D118 ) =20 =20 =09 =09 ---------------------------------------------------------- IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the recipient, please immediately notify us by return email, and delete this message from your computer. =09 ----------------------------------------------------------=20 ---------------------------------------------------------- IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the recipient, please immediately notify us by return email, and delete this message from your computer. ----------------------------------------------------------=20 |
