简体   繁体   English

Quickfix无法读取重复组

[英]Quickfix failing to read repeating group

I am using quickfix in Windows with python bindings. 我在Windows中使用带有Python绑定的quickfix。 I have been able to make market data requests in the past. 我过去曾提出过市场数据请求。 I recently changed to a different API provider (Cunningham, aka CTS) and am encountering a lot of issues. 我最近改用了其他API提供程序(坎宁安,又名CTS),遇到了很多问题。 At least one of them, however, seems to be internal to quickfix. 但是,其中至少有一个似乎在quickfix内部。 It is baffling me. 这让我感到困惑。

When I send a market data request, I get back a response. 发送市场数据请求时,我会返回响应。 It is a typical 35=W message, a market snapshot. 这是典型的35 = W消息,即市场快照。

Quickfix is rejecting this message because tag 269 appears more than once! Quickfix拒绝此消息,因为标签269出现多次!

Of course, tag 269 is MDEntryType, it is supposed to occur more than once. 当然,标签269是MDEntryType,它应该出现多次。 Notice also that tag 268, NoMDEntries, is defined and says there are 21 entries in the group. 还要注意,定义了标签268 NoMDEntries,并说该组中有21个条目。

I think this is internal to quickfix because quickfix is generating an error message and sending it back to CTS. 我认为这是quickfix的内部功能,因为quickfix会生成错误消息并将其发送回CTS。 Also, this error aborts the message before it can get passed to the fromApp function. 同样,此错误会中止消息,然后才能将其传递给fromApp函数。 (I know because my parsers which apply themselves to the message whenever fromApp is called are not even getting this message). (我知道,因为每当fromApp时将自己应用于消息的解析器甚至都没有得到此消息)。

Any ideas? 有任何想法吗? The message is below. 该消息如下。

(edit -- I have turned off the data dictionary in the config file -- could it have anything to do with that?) (编辑-我已经关闭了配置文件中的数据字典-可能与此有关吗?)

<20140915-22:39:11.953, FIX.4.2:XXXXX->CTS, incoming> (8=FIX.4.2 ☺ 9=836 ☺ 35=W ☺ 34=4 ☺ 49=CTS ☺ 56=XXXXX ☺ 52=20140915-22:39:11.963 ☺ 48=XDLCM E_F ZN (Z14) ☺ 387=2559 ☺ 965=2 ☺ 268=21 ☺ 269=0 ☺ 270=124156250 ☺ 271=646 ☺ 1023=1 ☺ 269=0 ☺ 270= 124140625 ☺ 271=918 ☺ 1023=2 ☺ 269=0 ☺ 270=124125000 ☺ 271=1121 ☺ 1023=3 ☺ 269=0 ☺ 270=124109375 ☺ 271=998 ☺ 1023=4 ☺ 269=0 ☺ 270=124093750 ☺ 271=923 ☺ 1023=5 ☺ 269=0 ☺ 270=124078125 ☺ 271=1689 ☺ 1023=6 ☺ 269=0 ☺ 270=124062500 ☺ 271=2011 ☺ 1023=7 ☺ 269=0 ☺ 270=124046875 ☺ 271=1782 ☺ 1023=8 ☺ 2 69=0 ☺ 270=124031250 ☺ 271=2124 ☺ 1023=9 ☺ 269=0 ☺ 270=124015625 ☺ 271=1875 ☺ 1023=10 ☺ 269=1 ☺ 27 0=124171875 ☺ 271=422 ☺ 1023=1 ☺ 269=1 ☺ 270=124187500 ☺ 271=577 ☺ 1023=2 ☺ 269=1 ☺ 270=12420312 5 ☺ 271=842 ☺ 1023=3 ☺ 269=1 ☺ 270=124218750 ☺ 271=908 ☺ 1023=4 ☺ 269=1 ☺ 270=124234375 ☺ 271=1482 ☺ 1023=5 ☺ 269=1 ☺ 270 <20140915-22:39:11.953,FIX.4.2:XXXXX-> CTS,传入>(8 = FIX.4.2☺9 = 836☺35 = W☺34 = 4☺49 = CTS☺56 = XXXXX☺52 = 20140915 -22:39:11.963☺48 = XDLCM E_F ZN(Z14)☺387 = 2559☺965 = 2☺268 = 21☺269 = 0☺270 = 124156250☺271 = 646☺1023 = 1☺269 = 0☺270 = 124140625☺271 = 918☺1023 = 2☺269 = 0☺270 = 124125000☺271 = 1121☺1023 = 3☺269 = 0☺270 = 124109375☺271 = 998☺1023 = 4☺269 = 0☺270 = 124093750☺ 271 = 923☺1023 = 5☺269 = 0☺270 = 124078125☺271 = 1689☺1023 = 6☺269 = 0 270 270 = 124062500☺271 = 2011☺1023 = 7☺269 = 0☺270 = 124046875☺271 = 1782☺1023=8☺269=0☺270=124031250☺271=2124☺1023=9☺269=0☺270=124015625☺271=1875☺1023=10☺269=1☺270 =124171875☺271= 422☺1023 = 1☺269 = 1☺270 = 124187500☺271 = 577☺1023 = 2☺269 = 1☺270 = 12420312 5☺271 = 842☺1023 = 3☺269 = 1☺270 = 124218750☺271 = 908 23 1023 = 4☺269 = 1☺270 = 124234375☺271 = 1482☺1023 = 5☺269 = 1☺270 =124250000 ☺ 271=1850 ☺ 1023=6 ☺ 269=1 ☺ 270=124265625 ☺ 271=1729 ☺ 1023=7 ☺ 269=1 ☺ 270=124281250 ☺ 271=2615 ☺ 1023=8 ☺ 269=1 ☺ 270=124296875 ☺ 271=1809 ☺ 1023=9 ☺ 269=1 ☺ 27 0=124312500 ☺ 271=2241 ☺ 1023=10 ☺ 269=4 ☺ 270=124156250 ☺ 271=1 ☺ 10=140 ☺ ) = 124250000☺271 = 1850☺1023 = 6☺269 = 1☺270 = 124265625☺271 = 1729☺1023 = 7☺269 = 1☺270 = 124281250☺271 = 2615☺1023 = 8☺269 = 1☺270 = 124296875 ☺271 = 1809☺1023 = 9☺269 = 1☺27 0 = 124312500☺271 = 2241☺1023 = 10☺269 = 4☺270 = 124156250☺271 = 1☺10 = 140☺)

<20140915-22:39:12.004, FIX.4.2:XXXX->CTS, event> (Message 4 Rejected: Tag appears more than once:269) <20140915-22:39:12.004,FIX.4.2:XXXX-> CTS,事件>(消息4被拒绝:标记多次出现:269)

<20140915-22:39:12.010, FIX.4.2:XXXX->CTS, outgoing> (8=FIX.4.2 ☺ 9=102 ☺ 35=3 ☺ 34=4 ☺ 49=XXXX ☺ 52=20140915-22:39:12.009 ☺ 56=CTS ☺ 45=4 ☺ 58= Tag appears more than once ☺ 371=269 ☺ 372=W ☺ 10=012 ☺ ) <20140915-22:39:12.010,FIX.4.2:XXXX-> CTS,传出>(8 = FIX.4.2☺9 = 102☺35 = 3☺34 = 4☺49 = XXXX☺52 = 20140915-22:39 :12.009☺56 = CTS☺45 = 4☺58 =标签出现多次(☺371 = 269☺372 = W☺10 = 012☺)

(edit -- I have turned off the data dictionary in the config file -- could it have anything to do with that?) (编辑-我已经关闭了配置文件中的数据字典-可能与此有关吗?)

Yep, that's exactly the problem. 是的,这就是问题所在。

Without the DD, your engine doesn't know when a repeating group ends or begins. 没有DD,您的引擎将不知道重复组何时结束或开始。 As far as it's concerned, there's no such thing as repeating groups. 就其而言,不存在重复分组的问题。

You need a DD, and you need to make sure it matches your counterparty's message and field set. 需要一个DD,并且需要确保它与对手方的消息和字段集匹配。 If they've added custom fields or messages, you need to make sure your DD reflects that. 如果他们添加了自定义字段或消息,则需要确保您的DD能够反映出来。

I realize this thread is years old but I had this exact problem and finally resolved it so I am putting it here to help anyone else that stumbles across this. 我意识到这个线程已经存在多年了,但是我遇到了这个确切的问题,并最终解决了它,所以我将其放在这里来帮助任何偶然发现此问题的人。

The issue was that in my config I was using the 'DataDictionary=..' parameter. 问题是在我的配置中,我使用的是'DataDictionary=..'参数。 Changing this to 'AppDataDictionary=...' solved my problem. 将其更改为'AppDataDictionary=...'解决了我的问题。

Steve 史蒂夫

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM