RE: [Quickfix-developers] NoRelatedSym Class
Brought to you by:
orenmnero
Menu
▾
▴
RE: [Quickfix-developers] NoRelatedSym Class
|
From: Oren M. <ore...@ya...> - 2003-04-30 16:51:03
|
Yeah, I'm thinking of making the DataDictionary required, unless you explicitly disable it. Maybe a UseDataDictionary setting that defaults to 'Y'. That way a config error will be thrown if they do not specify a DD and they don't explicitly disable it. --- Gene Gorokhovsky <mus...@ya...> wrote: > Yes, without validation (DataDict defined in > settings) > group receiving is broken. This should be > highlighted > in documentation because almost everyone has run > into > it. > > Gene > --- Mike Hepburn <mi...@an...> wrote: > > All, > > > > Some further testing reveals that without > validation > > (i.e no > > DataDictionary defined) the acceptor dump of the > > incoming message > > appears wrong: > > > > sent: > > <message> > > <header> > > <field number="8" value="FIX.4.3"/> > > <field number="35" value="V"/> > > </header> > > <body> > > <field number="146" value="1"/> > > <field number="262" value="1"/> > > <field number="263" value="0"/> > > <field number="264" value="0"/> > > <field number="267" value="1"/> > > <group> > > <field number="55" value="tsco.l"/> > > </group> > > <group> > > <field number="269" value="0"/> > > </group> > > </body> > > <trailer> > > </trailer> > > </message> > > > > > > received(no validation): > > <message> > > <header> > > <field number="8" value="FIX.4.3"/> > > <field number="9" value="94"/> > > <field number="35" value="V"/> > > <field number="34" value="3"/> > > <field number="49" value="CLIENT1"/> > > <field number="52" value="20030430-11:21:01"/> > > <field number="56" value="AM"/> > > </header> > > <body> > > <field number="55" value="tsco.l"/> > > <field number="146" value="1"/> > > <field number="262" value="1"/> > > <field number="263" value="0"/> > > <field number="264" value="0"/> > > <field number="267" value="1"/> > > <field number="269" value="0"/> > > </body> > > <trailer> > > <field number="10" value="224"/> > > </trailer> > > </message> > > > > It looks like message XML encoding still has bugs > > for repeating groups ? > > i ran ethereal over the connection to see if it > was > > the encoding or > > decoding - looks like it is the encoding: > > > > Transmission Control Protocol, Src Port: 46450 > > (46450), Dst Port: 5001 > > (5001), Seq: 1717567461, Ack: 1741597886, Len: 116 > > Source port: 46450 (46450) > > Destination port: 5001 (5001) > > Sequence number: 1717567461 > > Next sequence number: 1717567577 > > Acknowledgement number: 1741597886 > > Header length: 32 bytes > > Flags: 0x0018 (PSH, ACK) > > 0... .... = Congestion Window Reduced > (CWR): > > Not set > > .0.. .... = ECN-Echo: Not set > > ..0. .... = Urgent: Not set > > ...1 .... = Acknowledgment: Set > > .... 1... = Push: Set > > .... .0.. = Reset: Not set > > .... ..0. = Syn: Not set > > .... ...0 = Fin: Not set > > Window size: 6432 > > Checksum: 0x9704 (correct) > > Options: (12 bytes) > > NOP > > NOP > > Time stamp: tsval 250859949, tsecr > 245892923 > > Financial Information eXchange Protocol > > BeginString (8): FIX.4.3 > > BodyLength (9): 94 > > MsgType (35): V > > MsgSeqNum (34): 3 > > SenderCompID (49): CLIENT1 > > SendingTime (52): 20030430-11:21:01 > > TargetCompID (56): AM > > NoRelatedSym (146): 1 > > Symbol (55): tsco.l > > MDReqID (262): 1 > > SubscriptionRequestType (263): 0 > > MarketDepth (264): 0 > > NoMDEntryTypes (267): 1 > > MDEntryType (269): 0 > > CheckSum (10): 224 > > > > Frame 2 (66 bytes on wire, 66 bytes captured) > > > > The 'on the wire' message doesn't have the group's > > defined either. > > > > Does anyone else see this using the java bindings, > > FIX43.xml and > > repeating groups ? > > > > Cheers > > Mike > > > > > > > > > > On Wed, 2003-04-30 at 10:52, Mike Hepburn wrote: > > > Hi Oren, > > > > > > i have narrowed this down to being a java > problem. > > I added a validation > > > test in C++ for the MarketDataRequest message > and > > it passed OK. the XML > > > data structure (from toXML()) produced by C++ > and > > java is identical. > > > > > > Unfortunately there are no java bindings for the > > DataDictionary class - > > > so i couldn't repeat the test in java. i > > considered implementing > > > DataDictionary::validate via jni but thought > > something more basic must > > > be going on. > > > > > > in java the data dictionary (FIX43.xml) appears > to > > load OK and validate > > > other message types (e.g NewOrderSingle's) OK - > my > > next step is to strip > > > the DataDictionary XML file down to only have > the > > MarketDataRequest to > > > see if i get further. > > > > > > > > > Cheers > > > Mike > > > > > > > > > On Mon, 2003-04-28 at 20:13, Oren Miller wrote: > > > > Yeah. DataDictionary is a good place to > start. > > I would take a look at the DataDictionaryTestCase. > > > If there is a problem, it will probably be one of > > two things. 1) the XML file is not being loaded > > correctly2) there is a problem with the validation > > itself You can verify #2 by adding some asserts to > > the readFromFile test. If you do not detect a > > problem there, then you can add tests to > > checkIsInMessage (test for the code that > determines > > a field belongs to a message), and > checkValidFormat > > (test for full validation of a message). You may > > want to synch up with CVS so that you have the > > latest code and tests. If you want to debug or use > > trace statements instead. I would recommend > creating > > a DD XML file that only contains the message you > are > > concerned with. You can then look for problems > > reading from the file or validating. I prefer, > > however, to have a failing test that exposes the > > problem before I venture into the code. Let use > know > > if you find anything or if you need any other! > > > > pointers. If you are able to provide a small > > project that can demonstrate the error, that would > === message truncated === __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
