quickfix-developers — QuickFIX developers forum

[Quickfix-developers] Memory Leaking

[Alan C. <al...@cn...>]

Hi,
    I downloaded the quickfix on the website, and I found out that there is
a memory leaking in the lib.  Any idea of how to fix it?

Detected memory leaks!
Dumping objects ->
{682022} normal block at 0x01F7A478, 33 bytes long.
 Data: < 8=FIX.4.4      > 00 38 3D 46 49 58 2E 34 2E 34 01 00 CD CD CD CD
{682018} normal block at 0x01F7A270, 33 bytes long.
 Data: < FIX.4.4        > 00 46 49 58 2E 34 2E 34 00 CD CD CD CD CD CD CD
{682017} normal block at 0x01F7A208, 44 bytes long.
 Data: <     {          > F8 D4 B5 00 90 7B F7 01 F8 D4 B5 00 CC CD CD CD
{682016} normal block at 0x01F7A2D8, 33 bytes long.
 Data: < 8=             > 00 38 3D 01 00 CD CD CD CD CD CD CD CD CD CD CD
{682013} normal block at 0x01F7A1B0, 20 bytes long.
 Data: <@e  H   @e      > 40 65 B5 00 48 9D F7 01 40 65 B5 00 CB 01 00 00
{682012} normal block at 0x01F79D48, 20 bytes long.
 Data: <@e              > 40 65 B5 00 F0 9C F7 01 B0 A1 F7 01 CA 01 00 00
{682011} normal block at 0x01F7A148, 44 bytes long.
 Data: <H       H       > 48 A1 F7 01 F8 D4 B5 00 48 A1 F7 01 CD CD CD CD
{682009} normal block at 0x01F7A0D0, 52 bytes long.
 Data: <                > D0 A0 F7 01 08 D4 B5 00 D0 A0 F7 01 CD CD CD CD
{682007} normal block at 0x01F7A068, 36 bytes long.
 Data: <h   8   h       > 68 A0 F7 01 38 D3 B5 00 68 A0 F7 01 CD CD CD CD
{682005} normal block at 0x01F7A000, 36 bytes long.
 Data: <    h           > 00 A0 F7 01 68 D2 B5 00 00 A0 F7 01 CD CD CD CD
{682003} normal block at 0x01F79F98, 36 bytes long.
 Data: <                > 98 9F F7 01 98 D1 B5 00 98 9F F7 01 CD CD CD CD
{682001} normal block at 0x01F79F40, 24 bytes long.
 Data: <@   P   @       > 40 9F F7 01 50 B8 B5 00 40 9F F7 01 CD CD CD CD
{681999} normal block at 0x01F79EE8, 20 bytes long.
 Data: <    @e          > E8 9E F7 01 40 65 B5 00 E8 9E F7 01 CD CD CD CD
{681997} normal block at 0x01F79E90, 20 bytes long.
 Data: <    @e          > 90 9E F7 01 40 65 B5 00 90 9E F7 01 CD CD CD CD
{681995} normal block at 0x01F79CF0, 20 bytes long.
 Data: <H   H           > 48 9D F7 01 48 9D F7 01 B0 A1 F7 01 CD CD CD CD
{681993} normal block at 0x01F79E28, 32 bytes long.
 Data: <(       (       > 28 9E F7 01 C8 D0 B5 00 28 9E F7 01 CD CD CD CD
{681991} normal block at 0x01F79DB0, 48 bytes long.
 Data: <                > B0 9D F7 01 90 95 B5 00 B0 9D F7 01 CD CD CD CD
{681989} normal block at 0x01F79C78, 48 bytes long.
 Data: <x       x       > 78 9C F7 01 90 95 B5 00 78 9C F7 01 CD CD CD CD
{681984} normal block at 0x01F79B40, 244 bytes long.
 Data: <  Z             > B0 19 5A 00 01 01 01 CD 08 00 00 00 CC CD CD CD
{681983} normal block at 0x01F79AE8, 20 bytes long.
 Data: <@e  8   @e      > 40 65 B5 00 38 9A F7 01 40 65 B5 00 F1 00 00 00
{681982} normal block at 0x01F79A90, 20 bytes long.
 Data: <@e  8   @e      > 40 65 B5 00 38 9A F7 01 40 65 B5 00 F3 00 00 00
{681981} normal block at 0x01F79A38, 20 bytes long.
 Data: <                > E8 9A F7 01 20 97 F7 01 90 9A F7 01 F2 00 00 00
{681980} normal block at 0x01F799E0, 20 bytes long.
 Data: <@e  0   @e      > 40 65 B5 00 30 99 F7 01 40 65 B5 00 F5 00 00 00
{681979} normal block at 0x01F79988, 20 bytes long.
 Data: <@e  0   @e      > 40 65 B5 00 30 99 F7 01 40 65 B5 00 F7 00 00 00
{681978} normal block at 0x01F79930, 20 bytes long.
 Data: <    x           > E0 99 F7 01 78 97 F7 01 88 99 F7 01 F6 00 00 00
{681977} normal block at 0x01F798D8, 20 bytes long.
 Data: <@e      @e  1   > 40 65 B5 00 D0 97 F7 01 40 65 B5 00 31 01 00 00
{681976} normal block at 0x01F79880, 20 bytes long.
 Data: <@e  (   @e  3   > 40 65 B5 00 28 98 F7 01 40 65 B5 00 33 01 00 00
{681975} normal block at 0x01F79828, 20 bytes long.
 Data: <        @e  4   > 80 98 F7 01 D0 97 F7 01 40 65 B5 00 34 01 00 00
{681974} normal block at 0x01F797D0, 20 bytes long.
 Data: <    x   (   2   > D8 98 F7 01 78 97 F7 01 28 98 F7 01 32 01 00 00
{681973} normal block at 0x01F79778, 20 bytes long.
 Data: <0               > 30 99 F7 01 20 97 F7 01 D0 97 F7 01 00 01 00 00
{681972} normal block at 0x01F79720, 20 bytes long.
 Data: <8       x       > 38 9A F7 01 C8 8B F7 01 78 97 F7 01 F4 00 00 00
{681971} normal block at 0x01F796C8, 20 bytes long.
 Data: <@e      @e  6   > 40 65 B5 00 18 96 F7 01 40 65 B5 00 36 01 00 00
{681970} normal block at 0x01F79670, 20 bytes long.
 Data: <@e      @e  8   > 40 65 B5 00 18 96 F7 01 40 65 B5 00 38 01 00 00
{681969} normal block at 0x01F79618, 20 bytes long.
 Data: <        p   7   > C8 96 F7 01 A8 92 F7 01 70 96 F7 01 37 01 00 00
{681968} normal block at 0x01F795C0, 20 bytes long.
 Data: <@e      @e  <   > 40 65 B5 00 B8 94 F7 01 40 65 B5 00 3C 01 00 00
{681967} normal block at 0x01F79568, 20 bytes long.
 Data: <@e      @e  >   > 40 65 B5 00 10 95 F7 01 40 65 B5 00 3E 01 00 00
{681966} normal block at 0x01F79510, 20 bytes long.
 Data: <h       @e  j   > 68 95 F7 01 B8 94 F7 01 40 65 B5 00 6A 01 00 00
{681965} normal block at 0x01F794B8, 20 bytes long.
 Data: <            =   > C0 95 F7 01 00 93 F7 01 10 95 F7 01 3D 01 00 00
{681964} normal block at 0x01F79460, 20 bytes long.
 Data: <@e      @e  m   > 40 65 B5 00 08 94 F7 01 40 65 B5 00 6D 01 00 00
{681963} normal block at 0x01F79408, 20 bytes long.
 Data: <@e  X   `   l   > 40 65 B5 00 58 93 F7 01 60 94 F7 01 6C 01 00 00
{681962} normal block at 0x01F793B0, 20 bytes long.
 Data: <@e  X   @e      > 40 65 B5 00 58 93 F7 01 40 65 B5 00 B4 01 00 00
{681961} normal block at 0x01F79358, 20 bytes long.
 Data: <                > 08 94 F7 01 00 93 F7 01 B0 93 F7 01 B3 01 00 00
{681960} normal block at 0x01F79300, 20 bytes long.
 Data: <        X   k   > B8 94 F7 01 A8 92 F7 01 58 93 F7 01 6B 01 00 00
{681959} normal block at 0x01F792A8, 20 bytes long.
 Data: <            9   > 18 96 F7 01 20 8C F7 01 00 93 F7 01 39 01 00 00
{681958} normal block at 0x01F79250, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 A0 91 F7 01 40 65 B5 00 CE 01 00 00
{681957} normal block at 0x01F791F8, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 A0 91 F7 01 40 65 B5 00 1E 02 00 00
{681956} normal block at 0x01F791A0, 20 bytes long.
 Data: <P   x           > 50 92 F7 01 78 8C F7 01 F8 91 F7 01 CF 01 00 00
{681955} normal block at 0x01F79148, 20 bytes long.
 Data: <@e      @e  R   > 40 65 B5 00 F0 90 F7 01 40 65 B5 00 52 02 00 00
{681954} normal block at 0x01F790F0, 20 bytes long.
 Data: <@e      H   Q   > 40 65 B5 00 E8 8F F7 01 48 91 F7 01 51 02 00 00
{681953} normal block at 0x01F79098, 20 bytes long.
 Data: <@e  @   @e  *   > 40 65 B5 00 40 90 F7 01 40 65 B5 00 2A 03 00 00
{681952} normal block at 0x01F79040, 20 bytes long.
 Data: <@e              > 40 65 B5 00 E8 8F F7 01 98 90 F7 01 FB 02 00 00
{681951} normal block at 0x01F78FE8, 20 bytes long.
 Data: <        @   S   > F0 90 F7 01 D0 8C F7 01 40 90 F7 01 53 02 00 00
{681950} normal block at 0x01F78F90, 20 bytes long.
 Data: <@e      @e  n   > 40 65 B5 00 E0 8E F7 01 40 65 B5 00 6E 03 00 00
{681949} normal block at 0x01F78F38, 20 bytes long.
 Data: <@e      @e  r   > 40 65 B5 00 E0 8E F7 01 40 65 B5 00 72 03 00 00
{681948} normal block at 0x01F78EE0, 20 bytes long.
 Data: <    (   8   o   > 90 8F F7 01 28 8D F7 01 38 8F F7 01 6F 03 00 00
{681947} normal block at 0x01F78E88, 20 bytes long.
 Data: <@e      @e  t   > 40 65 B5 00 80 8D F7 01 40 65 B5 00 74 03 00 00
{681946} normal block at 0x01F78E30, 20 bytes long.
 Data: <@e      @e  v   > 40 65 B5 00 D8 8D F7 01 40 65 B5 00 76 03 00 00
{681945} normal block at 0x01F78DD8, 20 bytes long.
 Data: <0       @e      > 30 8E F7 01 80 8D F7 01 40 65 B5 00 AD 03 00 00
{681944} normal block at 0x01F78D80, 20 bytes long.
 Data: <    (       u   > 88 8E F7 01 28 8D F7 01 D8 8D F7 01 75 03 00 00
{681943} normal block at 0x01F78D28, 20 bytes long.
 Data: <            s   > E0 8E F7 01 D0 8C F7 01 80 8D F7 01 73 03 00 00
{681942} normal block at 0x01F78CD0, 20 bytes long.
 Data: <    x   (   m   > E8 8F F7 01 78 8C F7 01 28 8D F7 01 6D 03 00 00
{681941} normal block at 0x01F78C78, 20 bytes long.
 Data: <            P   > A0 91 F7 01 20 8C F7 01 D0 8C F7 01 50 02 00 00
{681940} normal block at 0x01F78C20, 20 bytes long.
 Data: <        x       > A8 92 F7 01 C8 8B F7 01 78 8C F7 01 C9 01 00 00
{681939} normal block at 0x01F78BC8, 20 bytes long.
 Data: <     x      5   > 20 97 F7 01 80 78 F7 01 20 8C F7 01 35 01 00 00
{681938} normal block at 0x01F78B70, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 C0 8A F7 01 40 65 B5 00 F1 00 00 00
{681937} normal block at 0x01F78B18, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 C0 8A F7 01 40 65 B5 00 F3 00 00 00
{681936} normal block at 0x01F78AC0, 20 bytes long.
 Data: <p               > 70 8B F7 01 A8 87 F7 01 18 8B F7 01 F2 00 00 00
{681935} normal block at 0x01F78A68, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 B8 89 F7 01 40 65 B5 00 F5 00 00 00
{681934} normal block at 0x01F78A10, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 B8 89 F7 01 40 65 B5 00 F7 00 00 00
{681933} normal block at 0x01F789B8, 20 bytes long.
 Data: <h               > 68 8A F7 01 00 88 F7 01 10 8A F7 01 F6 00 00 00
{681932} normal block at 0x01F78960, 20 bytes long.
 Data: <@e  X   @e  1   > 40 65 B5 00 58 88 F7 01 40 65 B5 00 31 01 00 00
{681931} normal block at 0x01F78908, 20 bytes long.
 Data: <@e      @e  3   > 40 65 B5 00 B0 88 F7 01 40 65 B5 00 33 01 00 00
{681930} normal block at 0x01F788B0, 20 bytes long.
 Data: <    X   @e  4   > 08 89 F7 01 58 88 F7 01 40 65 B5 00 34 01 00 00
{681929} normal block at 0x01F78858, 20 bytes long.
 Data: <`           2   > 60 89 F7 01 00 88 F7 01 B0 88 F7 01 32 01 00 00
{681928} normal block at 0x01F78800, 20 bytes long.
 Data: <        X       > B8 89 F7 01 A8 87 F7 01 58 88 F7 01 00 01 00 00
{681927} normal block at 0x01F787A8, 20 bytes long.
 Data: <    P|          > C0 8A F7 01 50 7C F7 01 00 88 F7 01 F4 00 00 00
{681926} normal block at 0x01F78750, 20 bytes long.
 Data: <@e      @e  6   > 40 65 B5 00 A0 86 F7 01 40 65 B5 00 36 01 00 00
{681925} normal block at 0x01F786F8, 20 bytes long.
 Data: <@e      @e  8   > 40 65 B5 00 A0 86 F7 01 40 65 B5 00 38 01 00 00
{681924} normal block at 0x01F786A0, 20 bytes long.
 Data: <P   0       7   > 50 87 F7 01 30 83 F7 01 F8 86 F7 01 37 01 00 00
{681923} normal block at 0x01F78648, 20 bytes long.
 Data: <@e  @   @e  <   > 40 65 B5 00 40 85 F7 01 40 65 B5 00 3C 01 00 00
{681922} normal block at 0x01F785F0, 20 bytes long.
 Data: <@e      @e  >   > 40 65 B5 00 98 85 F7 01 40 65 B5 00 3E 01 00 00
{681921} normal block at 0x01F78598, 20 bytes long.
 Data: <    @   @e  j   > F0 85 F7 01 40 85 F7 01 40 65 B5 00 6A 01 00 00
{681920} normal block at 0x01F78540, 20 bytes long.
 Data: <H           =   > 48 86 F7 01 88 83 F7 01 98 85 F7 01 3D 01 00 00
{681919} normal block at 0x01F784E8, 20 bytes long.
 Data: <@e      @e  m   > 40 65 B5 00 90 84 F7 01 40 65 B5 00 6D 01 00 00
{681918} normal block at 0x01F78490, 20 bytes long.
 Data: <@e          l   > 40 65 B5 00 E0 83 F7 01 E8 84 F7 01 6C 01 00 00
{681917} normal block at 0x01F78438, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 E0 83 F7 01 40 65 B5 00 B4 01 00 00
{681916} normal block at 0x01F783E0, 20 bytes long.
 Data: <        8       > 90 84 F7 01 88 83 F7 01 38 84 F7 01 B3 01 00 00
{681915} normal block at 0x01F78388, 20 bytes long.
 Data: <@   0       k   > 40 85 F7 01 30 83 F7 01 E0 83 F7 01 6B 01 00 00
{681914} normal block at 0x01F78330, 20 bytes long.
 Data: <     |      9   > A0 86 F7 01 A8 7C F7 01 88 83 F7 01 39 01 00 00
{681913} normal block at 0x01F782D8, 20 bytes long.
 Data: <@e  (   @e      > 40 65 B5 00 28 82 F7 01 40 65 B5 00 CE 01 00 00
{681912} normal block at 0x01F78280, 20 bytes long.
 Data: <@e  (   @e      > 40 65 B5 00 28 82 F7 01 40 65 B5 00 1E 02 00 00
{681911} normal block at 0x01F78228, 20 bytes long.
 Data: <     }          > D8 82 F7 01 00 7D F7 01 80 82 F7 01 CF 01 00 00
{681910} normal block at 0x01F781D0, 20 bytes long.
 Data: <@e  x   @e  R   > 40 65 B5 00 78 81 F7 01 40 65 B5 00 52 02 00 00
{681909} normal block at 0x01F78178, 20 bytes long.
 Data: <@e  p       Q   > 40 65 B5 00 70 80 F7 01 D0 81 F7 01 51 02 00 00
{681908} normal block at 0x01F78120, 20 bytes long.
 Data: <@e      @e  *   > 40 65 B5 00 C8 80 F7 01 40 65 B5 00 2A 03 00 00
{681907} normal block at 0x01F780C8, 20 bytes long.
 Data: <@e  p           > 40 65 B5 00 70 80 F7 01 20 81 F7 01 FB 02 00 00
{681906} normal block at 0x01F78070, 20 bytes long.
 Data: <x   X}      S   > 78 81 F7 01 58 7D F7 01 C8 80 F7 01 53 02 00 00
{681905} normal block at 0x01F78018, 20 bytes long.
 Data: <@e  h   @e  n   > 40 65 B5 00 68 7F F7 01 40 65 B5 00 6E 03 00 00
{681904} normal block at 0x01F77FC0, 20 bytes long.
 Data: <@e  h   @e  r   > 40 65 B5 00 68 7F F7 01 40 65 B5 00 72 03 00 00
{681903} normal block at 0x01F77F68, 20 bytes long.
 Data: <     }      o   > 18 80 F7 01 B0 7D F7 01 C0 7F F7 01 6F 03 00 00
{681902} normal block at 0x01F77F10, 20 bytes long.
 Data: <@e   ~  @e  t   > 40 65 B5 00 08 7E F7 01 40 65 B5 00 74 03 00 00
{681901} normal block at 0x01F77EB8, 20 bytes long.
 Data: <@e  `~  @e  v   > 40 65 B5 00 60 7E F7 01 40 65 B5 00 76 03 00 00
{681900} normal block at 0x01F77E60, 20 bytes long.
 Data: < ~   ~  @e      > B8 7E F7 01 08 7E F7 01 40 65 B5 00 AD 03 00 00
{681899} normal block at 0x01F77E08, 20 bytes long.
 Data: <     }  `~  u   > 10 7F F7 01 B0 7D F7 01 60 7E F7 01 75 03 00 00
{681898} normal block at 0x01F77DB0, 20 bytes long.
 Data: <h   X}   ~  s   > 68 7F F7 01 58 7D F7 01 08 7E F7 01 73 03 00 00
{681897} normal block at 0x01F77D58, 20 bytes long.
 Data: <p    }   }  m   > 70 80 F7 01 00 7D F7 01 B0 7D F7 01 6D 03 00 00
{681896} normal block at 0x01F77D00, 20 bytes long.
 Data: <(    |  X}  P   > 28 82 F7 01 A8 7C F7 01 58 7D F7 01 50 02 00 00
{681895} normal block at 0x01F77CA8, 20 bytes long.
 Data: <0   P|   }      > 30 83 F7 01 50 7C F7 01 00 7D F7 01 C9 01 00 00
{681894} normal block at 0x01F77C50, 20 bytes long.
 Data: <     {   |  5   > A8 87 F7 01 F8 7B F7 01 A8 7C F7 01 35 01 00 00
{681893} normal block at 0x01F77BF8, 20 bytes long.
 Data: <p   P|  `~      > 70 8B F7 01 50 7C F7 01 60 7E F7 01 CD CD CD CD
{681891} normal block at 0x01F74BA0, 48 bytes long.
 Data: <     o          > 90 95 B5 00 F0 6F F7 01 90 95 B5 00 CC CD CD CD
{681890} normal block at 0x01F77B90, 44 bytes long.
 Data: <                > 08 A2 F7 01 08 A2 F7 01 08 A2 F7 01 CD CD CD CD
{681888} normal block at 0x01F77B18, 52 bytes long.
 Data: < {       {      > 18 7B F7 01 08 D4 B5 00 18 7B F7 01 CD CD CD CD
{681886} normal block at 0x01F77AB0, 36 bytes long.
 Data: < z  8    z      > B0 7A F7 01 38 D3 B5 00 B0 7A F7 01 CD CD CD CD
{681884} normal block at 0x01F77A48, 36 bytes long.
 Data: <Hz  h   Hz      > 48 7A F7 01 68 D2 B5 00 48 7A F7 01 CD CD CD CD
{681882} normal block at 0x01F779E0, 36 bytes long.
 Data: < y       y      > E0 79 F7 01 98 D1 B5 00 E0 79 F7 01 CD CD CD CD
{681880} normal block at 0x01F77988, 24 bytes long.
 Data: < y  P    y      > 88 79 F7 01 50 B8 B5 00 88 79 F7 01 CD CD CD CD
{681878} normal block at 0x01F77930, 20 bytes long.
 Data: <0y  @e  0y      > 30 79 F7 01 40 65 B5 00 30 79 F7 01 CD CD CD CD
{681876} normal block at 0x01F778D8, 20 bytes long.
 Data: < x  @e   x      > D8 78 F7 01 40 65 B5 00 D8 78 F7 01 CD CD CD CD
{681874} normal block at 0x01F77880, 20 bytes long.
 Data: <                > E8 9A F7 01 C8 8B F7 01 D8 8D F7 01 CD CD CD CD
{681872} normal block at 0x01F77610, 32 bytes long.
 Data: < v       v      > 10 76 F7 01 C8 D0 B5 00 10 76 F7 01 CD CD CD CD
{681870} normal block at 0x01F77808, 48 bytes long.
 Data: < x       x      > 08 78 F7 01 90 95 B5 00 08 78 F7 01 CD CD CD CD
{681868} normal block at 0x01F76FF0, 48 bytes long.
 Data: < K   K   K      > A0 4B F7 01 A0 4B F7 01 A0 4B F7 01 CD CD CD CD
{681863} normal block at 0x01F776D0, 244 bytes long.
 Data: <  Z             > B0 19 5A 00 01 01 01 CD 08 00 00 00 CC CD CD CD
{679746} normal block at 0x01F73F98, 33 bytes long.
 Data: < 8=FIX.4.4      > 00 38 3D 46 49 58 2E 34 2E 34 01 00 CD CD CD CD
{679742} normal block at 0x01F73DF8, 33 bytes long.
 Data: < FIX.4.4        > 00 46 49 58 2E 34 2E 34 00 CD CD CD CD CD CD CD
{679741} normal block at 0x01F73DA0, 20 bytes long.
 Data: <@e  89  @e  ^   > 40 65 B5 00 38 39 F7 01 40 65 B5 00 5E 02 00 00
{679740} normal block at 0x01F73938, 20 bytes long.
 Data: <@e   8   =  ]   > 40 65 B5 00 E0 38 F7 01 A0 3D F7 01 5D 02 00 00
{679739} normal block at 0x01F73D38, 44 bytes long.
 Data: <8=      8=      > 38 3D F7 01 F8 D4 B5 00 38 3D F7 01 CD CD CD CD
{679737} normal block at 0x01F73CC0, 52 bytes long.
 Data: < <       <      > C0 3C F7 01 08 D4 B5 00 C0 3C F7 01 CD CD CD CD
{679735} normal block at 0x01F73C58, 36 bytes long.
{639704} normal block at 0x01F259B0, 20 bytes long.
 Data: <@e  XY  @e  h   > 40 65 B5 00 58 59 F2 01 40 65 B5 00 68 02 00 00
{639703} normal block at 0x01F25958, 20 bytes long.
 Data: < Z   Y   Y  g   > 08 5A F2 01 00 59 F2 01 B0 59 F2 01 67 02 00 00
{639702} normal block at 0x01F25900, 20 bytes long.
{639700} normal block at 0x01F25850, 20 bytes long.
 Data: <@e   W  @e  l   > 40 65 B5 00 F8 57 F2 01 40 65 B5 00 6C 02 00 00
{639699}  Data: <@e  @V  @e  n   > 40 65 B5 00 40 56 F2 01 40 65 B5 00 6E 02
00 00
{639697} normal block at 0x01F25748, 20 bytes long.
 Data: <@e   V  @e  p   > 40 65 B5 00 98 56 F2 01 40 65 B5 00 70 02 00 00
{639696} {639695} normal block at 0x01F25698, 20 bytes long.
 Data: <HW  @V   V      > 48 57 F2 01 40 56 F2 01 F0 56 F2 01 E3 02 00 00
{639694}  Data: <@e  8U  @e      > 40 65 B5 00 38 55 F2 01 40 65 B5 00 AE 03
00 00
{639692} normal block at 0x01F25590, 20 bytes long.
 Data: <@e  8U  @e      > 40 65 B5 00 38 55 F2 01 40 65 B5 00 BC 03 00 00
{639691} {639690} normal block at 0x01F254E0, 20 bytes long.
 Data: <@V   T  8U      > 40 56 F2 01 88 54 F2 01 38 55 F2 01 FC 02 00 00
{639689}  Data: < Y   S   T  i   > 00 59 F2 01 D8 53 F2 01 88 54 F2 01 69 02
00 00
{639687} normal block at 0x01F253D8, 20 bytes long.
 Data: <h[   S  0T  a   > 68 5B F2 01 80 53 F2 01 30 54 F2 01 61 02 00 00
{639686} {639685} normal block at 0x01F25328, 20 bytes long.
 Data: < a   S   U      > 98 61 F2 01 80 53 F2 01 90 55 F2 01 CD CD CD CD
{639683}  Data: <(w  (w  (w      > 28 77 F2 01 28 77 F2 01 28 77 F2 01 CD CD
CD CD
{639680} normal block at 0x01F25248, 52 bytes long.
 Data: <HR      HR      > 48 52 F2 01 08 D4 B5 00 48 52 F2 01 CD CD CD CD
{639678} {639676} normal block at 0x01F25178, 36 bytes long.
 Data: <xQ  h   xQ      > 78 51 F2 01 68 D2 B5 00 78 51 F2 01 CD CD CD CD
{639674}  Data: < P  P    P      > B8 50 F2 01 50 B8 B5 00 B8 50 F2 01 CD CD
CD CD
{639670} normal block at 0x01F25060, 20 bytes long.
 Data: <`P  @e  `P      > 60 50 F2 01 40 65 B5 00 60 50 F2 01 CD CD CD CD
{639668} {639666} normal block at 0x01F24F38, 20 bytes long.
 Data: < p   a   d      > 08 70 F2 01 F0 61 F2 01 00 64 F2 01 CD CD CD CD
{639664}  Data: <(       (       > 28 1C F2 01 90 95 B5 00 28 1C F2 01 CD CD
CD CD
{639660} normal block at 0x01F21BB0, 48 bytes long.
 Data: < O   O   O      > 90 4F F2 01 90 4F F2 01 90 4F F2 01 CD CD CD CD
{639655} {638402} normal block at 0x01F225E0, 33 bytes long.
 Data: < 8=FIX.4.4      > 00 38 3D 46 49 58 2E 34 2E 34 01 00 CD CD CD CD
{638398}  Data: <@e      @e  a   > 40 65 B5 00 D0 1E F2 01 40 65 B5 00 61 03
00 00
{638396} normal block at 0x01F22390, 20 bytes long.
 Data: <@e  8#  @e  d   > 40 65 B5 00 38 23 F2 01 40 65 B5 00 64 03 00 00
{638395}
Thanks and regards,
Alan Chen

[Quickfix-developers] RFC: transaction, speed upgrades

[John M. <jg...@jg...>]

Hello,

I am making some changes to QuickFIX and would like feedback on the 
plans.  I'm not sure how best to get the changes into the source tree 
but that is my goal since I think they'll be generally useful and I'd 
like to not patch future versions...  :-)  I'm hoping to get some 
consensus on the work to be done so that my chances of getting the 
changes incorporated are greater... and to benefit from the combined 
wisdom of the group.  I am relatively new to QuickFIX so please bear 
with me!  I would need a volunteer to get the Java wrappers done since 
we are C++ only...

First: I'd like to modify MySQLStore such that it uses the "prepared 
statements" in version 4.1.1+.  I'm hoping for a significant 
performance improvement.

Second: I'd like to provide the option to store the received messages 
in the 'messages' table in case the developer needs to look at those 
messages for some other reason.  This would be less error prone than 
remembering to manually persist received messages.  For reasons that 
will become clear soon, this would happen at dequeue from the 
ThreadedSocket* objects.

The third proposal needs some motivation:

In some applications the validity of sending a FIX message depends on 
the success of sending another FIX message.  It would therefore be nice 
to have an atomic unit of work that involves the processing and sending 
of an arbitrary number of messages.  One simple example: the developer 
wants to send an execution report AND a drop copy somewhere else.  If 
the execution report doesn't happen then the drop copy should not 
either (and vice versa).

Proposed solution (using MySQL 4.1.1+ with BDB or InnoDB tables):

a) Add begin() and commit() methods to MySQLStore (and perhaps nil 
versions in MessageStore) which returns handle(s) useful for performing 
other MySQL statements in the same transaction.  The generalized 
transaction looks like this:

	begin transaction
	receive message from queue, persisting changes to next incoming seqnum 
(can't take place in socket reader thread-- does it now?)
	business logic resulting in message send(s) and potentially in other 
persistence within the same transaction
	commit transaction

The problem here is that we cannot actually send messages unless we get 
past commit-- otherwise we might advertise something that didn't 
actually happen!  More on this follows... Also, the user manually calls 
begin() and commit() if the enclosed send(s) and other persistence are 
not in response to a received message.

b) static Utility::socket_send() is re-implemented to place bytes on a 
send queue instead of actually sending on the socket-- and there is 
YAWT (yet another worker thread) draining this queue onto the socket.  
There are two reasons for this-- first, bandwidth utilization may 
increase if business logic can run concurrently (our in-house engine 
has this).  Second, this provides a mechanism for stalling the actual 
send until post-commit (more in the next point).  If the worker thread 
encounters a write error then the queue is marked bad/emptied and 
socket_send() returns the error encountered by the write instead of 
performing the next enqueue.  The enqueued messages are lost but will 
be resent at next session startup (gap fill).  BTW, I am aware that 
socket_send() is static-- the socket handle is used with a global map 
to obtain the queue associated with the socket.  Hmmm... since there is 
really no reason to do this with the non-threaded incarnation of 
QuickFIX perhaps the right place for this is a re-implementation of 
ThreadedSocketConnection::send().

c) when beginning the transaction, a barrier is placed on the write 
queues of each active session (whether connected or not).  The barrier 
means "don't send past this point, wait here".  All such barriers are 
removed just after the transaction is committed.  This delays the send 
of each message generated from within the transaction until after the 
message and seqnum increment have been persisted -- a guarantee that 
they are available for servicing future resend requests.

High performance, reliable routing-type applications stand to benefit 
the most from these changes.  If a process/server dies in the middle of 
a transaction then the incoming message being acted on is effectively 
"un-received" and any messages produced are not sent.  Of course 
changes would be made in such a way as to not impact current QuickFIX 
users.

It would be nice if "someone" wanted to do all of this for BDBStore 
(imaginary Berkeley DB transactional implementation of MessageStore) in 
the cases where MySQL is not practical-- like a desktop application.

Comments? Concerns?

Thanks,
John

RE: [Quickfix-developers] Vacation/release

[Day, J. B. S. <Je...@ba...>]

[Snipped]

2. build a pure Java versions since JNI seems to make some headaches
 -- I'd be interested in this (and maybe helping!).

3. integrate with J2EE, most preferably the JBoss Application Server
    (http://www.jboss.org). This could in the style of JMS, the Java
    Messaging Systems and the QF messages could be processed by Message
    Driven Beans (MDBs).
 -- Allowing raw JMS endpoints would be a win, this would enable =
multiple middlewares to be used as a transport mechanism (and might ease =
connectivity into the SWIFT Fix network for some organisations)

Thank for your great work, Oren!

Cheers, J=F6rg

RE: [Quickfix-developers] Vacation/release

[Rich H. <rh...@st...>]

We need a week long session to finish up CME iLink support.
I patched a few things to get around this for now... passing
up logoffs to fromAdmin() without being logged in.  I believe
Dan May posted this change at some point.

Cheers,
Rich


-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]=20
Sent: Wednesday, December 17, 2003 8:40 AM
To: Miller, Oren
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Vacation/release

Hello Oren,

thank you for your Christmas wishes (in Europe it is still politically=20
correct to say Christma ;-). I also wish you a good time and a=20
successful New Year 2004. Enjoy your holidays!

> I will be out of town until the 28th of december.  After my return, I
> plan to get out the new release, likely to be versioned as 1.7.
> Among other thing, there will be full 4.4 support for .NET.

That is good news. I am also waiting for a new release, but I would like =

to add some stuff before as:

1. Process "Resend requests to infinity" completely before sending new
    messages through.

2. More verbose Logout processing. Currently QuickFIX does not send a
    Logout message in some instance where FIX suggests to send one.
    (Error conditions as "Sequence number too low" etc.)

Actually I would like to help more on implementing things like this. But =

project pressure prevented this until now.  Hopefully this will change=20
next year and I can contribute some changes.

> Although it is impossible to know how many installations of QuickFIX
> are out there, it appears to be very signifigant.  The big execution
> providers are taking notice as more and more people connect to them
> with QuickFIX.

Just make a poll...

> The popularity of QF can be attributed almost completely to word of
> mouth.  Keep it up! Combined with the growing acceptance of open
> source within the business community, I believe our so called "market
> share" will continue to grow.

We connect several customers to an exchange system and starting telling=20
them: We use QuickFIX. In addition, several users certified their=20
QF-based engines against different systems. Digging through the mailing=20
list gives the following:

* CBOE (Oren Miller, did you finish it?)
=09
* FOC's RediFIX FIX 4.0 interface
   QuickFix 1.4/1.5 Java Interface / FIX 4.0
   Platforms: W2k and Solaris
   From: "Chuck Houpt" <zzc...@xc...>

* CME ilink 2.0
   The changes needed to pass certification have been supplied, but are
   still not incorporated into CVS (I should have done it already...)
   From: "Rich Holm" <rh...@st...>

* Arcapelago
   http://www.tradearca.com
   QuickFIX 1.5 / FIX 4.1
   From: "Andrew Munn" <an...@nm...>

* SKL's RediFIX (no changes, is this the same as FOC?)
   http://www.redi.com/apifix.html
   QuickFIX 1.5 / FIX 4.1
   From: "Andrew Munn" <an...@nm...>

* Bear Stearns
   QuickFIX 1.6
   From: Oren Miller

If anybody has corrections/additions, please contribute!  It would be=20
nice to have some sort of form at the webpage so that people could=20
easily enter their data if they like.  Oren, is that possible with=20
sourceforge?

> I hope this next year will bring a new evolution to quickfix.  There
> are several big projects on the plate which I hope will either be
> inroporated into an eventual 2.0 release, or be spunoff into new
> projects.  Thank you for your support and have a happy holiday.

Could you reveal any details?  IMHO, the following things I would like=20
to be done:

1. file QuickFIX as a Debian package (http://www.debian.org)
    (possibly RPM too)

2. build a pure Java versions since JNI seems to make some headaches

3. integrate with J2EE, most preferably the JBoss Application Server
    (http://www.jboss.org). This could in the style of JMS, the Java
    Messaging Systems and the QF messages could be processed by Message
    Driven Beans (MDBs).

Thank for your great work, Oren!

Cheers, J=F6rg



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] A new feature which should be added!

[Michael H. <mh...@li...>]

I just noticed that the FIX message which is received and logged is =
completely different from the FIX message returned by calling the =
Message class method "toString()". 99% of the time it doesn't matter but =
if you are receiving group tags from an exchange which does not follow =
FIX 100% you are screwed. So I added this functionality to my =
implementation of Quickfix 1.6.

Thanks
Michael

Re: [Quickfix-developers] Vacation/release

[Joerg T. <Joe...@ma...>]

Hello Oren,

thank you for your Christmas wishes (in Europe it is still politically 
correct to say Christma ;-). I also wish you a good time and a 
successful New Year 2004. Enjoy your holidays!

> I will be out of town until the 28th of december.  After my return, I
> plan to get out the new release, likely to be versioned as 1.7.
> Among other thing, there will be full 4.4 support for .NET.

That is good news. I am also waiting for a new release, but I would like 
to add some stuff before as:

1. Process "Resend requests to infinity" completely before sending new
    messages through.

2. More verbose Logout processing. Currently QuickFIX does not send a
    Logout message in some instance where FIX suggests to send one.
    (Error conditions as "Sequence number too low" etc.)

Actually I would like to help more on implementing things like this. But 
project pressure prevented this until now.  Hopefully this will change 
next year and I can contribute some changes.

> Although it is impossible to know how many installations of QuickFIX
> are out there, it appears to be very signifigant.  The big execution
> providers are taking notice as more and more people connect to them
> with QuickFIX.

Just make a poll...

> The popularity of QF can be attributed almost completely to word of
> mouth.  Keep it up! Combined with the growing acceptance of open
> source within the business community, I believe our so called "market
> share" will continue to grow.

We connect several customers to an exchange system and starting telling 
them: We use QuickFIX. In addition, several users certified their 
QF-based engines against different systems. Digging through the mailing 
list gives the following:

* CBOE (Oren Miller, did you finish it?)
	
* FOC's RediFIX FIX 4.0 interface
   QuickFix 1.4/1.5 Java Interface / FIX 4.0
   Platforms: W2k and Solaris
   From: "Chuck Houpt" <zzc...@xc...>

* CME ilink 2.0
   The changes needed to pass certification have been supplied, but are
   still not incorporated into CVS (I should have done it already...)
   From: "Rich Holm" <rh...@st...>

* Arcapelago
   http://www.tradearca.com
   QuickFIX 1.5 / FIX 4.1
   From: "Andrew Munn" <an...@nm...>

* SKL's RediFIX (no changes, is this the same as FOC?)
   http://www.redi.com/apifix.html
   QuickFIX 1.5 / FIX 4.1
   From: "Andrew Munn" <an...@nm...>

* Bear Stearns
   QuickFIX 1.6
   From: Oren Miller

If anybody has corrections/additions, please contribute!  It would be 
nice to have some sort of form at the webpage so that people could 
easily enter their data if they like.  Oren, is that possible with 
sourceforge?

> I hope this next year will bring a new evolution to quickfix.  There
> are several big projects on the plate which I hope will either be
> inroporated into an eventual 2.0 release, or be spunoff into new
> projects.  Thank you for your support and have a happy holiday.

Could you reveal any details?  IMHO, the following things I would like 
to be done:

1. file QuickFIX as a Debian package (http://www.debian.org)
    (possibly RPM too)

2. build a pure Java versions since JNI seems to make some headaches

3. integrate with J2EE, most preferably the JBoss Application Server
    (http://www.jboss.org). This could in the style of JMS, the Java
    Messaging Systems and the QF messages could be processed by Message
    Driven Beans (MDBs).

Thank for your great work, Oren!

Cheers, Jörg

[Quickfix-developers] Vacation/release

[Miller, O. <OM...@ri...>]

I will be out of town until the 28th of december.  After my return, I =
plan to get out the new release, likely to be versioned as 1.7.  Among =
other thing, there will be full 4.4 support for .NET. =20

We have had more contributors to this version than ever before.  thank =
you to everyone who has helped out.

Although it is impossible to know how many installations of QuickFIX are =
out there, it appears to be very signifigant.  The big execution =
providers are taking notice as more and more people connect to them with =
QuickFIX.=20

The popularity of QF can be attributed almost completely to word of =
mouth.  Keep it up! Combined with the growing acceptance of open source =
within the business community, I believe our so called "market share" =
will continue to grow.

I hope this next year will bring a new evolution to quickfix.  There are =
several big projects on the plate which I hope will either be =
inroporated into an eventual 2.0 release, or be spunoff into new =
projects.  Thank you for your support and have a happy holiday.

--oren
--------------------------
Sent from my BlackBerry Wireless Handheld

[Quickfix-developers] QF writing same record to incoming_log repeatedly

[Andrew <and...@ho...>]

I have a situation where QF repeatedly writes duplicate records (except for
the ID field), hundreds of times per second, to the incoming_log.

Has anyone else seen this behavior or does anyone know of a fix?

Thanks,
Andrew Munn
and...@ho...

RE: [Quickfix-developers] Re: Sequence numbers

[Oren M. <ore...@ya...>]

Verma,  have you tried compiling with the
ENABLE_CALLSTACK parameter?  This will provide you
with a QuickFIX callstack at the time of the crash. 
This may help us to fix the core problem that you are
having.

--- "Verma, Sanjay" <SV...@Cr...> wrote:
> You are right. Unfortunately the problem is that
> when using the Java version
> of QF, numerous times the JVM simply crashes with no
> clue as to what
> happened! Debugging Java and C++ together is a
> challange that I don't feel
> like taking on (though as we speak I am looking at
> some tool called
> JNI-Bridge). So I am trying to eliminate as many
> abnormal (or normal but
> that lead to session disconnect) conditions as I can
> to get to the root of
> the problem. If people in this community have had
> similar experience, i.e.
> using Java version of QF, I'd love to share in it. 
> 
> Thanks.
> -----Original Message-----
> From: ili...@bn...
> [mailto:ili...@bn...]
> Sent: Wednesday, December 10, 2003 12:11 PM
> To: qui...@li...
> Subject: [Quickfix-developers] Re: Sequence numbers
> 
> 
> 
> Hi Sanjay,
> 
> Concordantly to the FIX protocol, QF allows you to
> receive a message with a
> sequence number too high (it will issue a resend
> request for the missing
> messages). On the contrary, a message with a
> sequence number too low will
> end your session, and I don't think that you should
> try to make your engine
> accept that kind of messages.
> 
> Regards,
> Ilyas
> 
> 
> 
> 
> Internet
>
qui...@li...@lists.sourceforge.net
> -
> 10/12/2003 05:09
> 
> 
> Veuillez répondre à
> qui...@li...
> 
> Envoyé par :     
> qui...@li...
> 
> Pour : quickfix-developers
> 
> cc :
> 
> 
> Objet :     Quickfix-developers digest, Vol 1 #378 -
> 1 msg
> 
> 
> Send Quickfix-developers mailing list submissions to
>       qui...@li...
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
>      
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> or, via email, send a message with subject or body
> 'help' to
>      
> qui...@li...
> 
> You can reach the person managing the list at
>      
> qui...@li...
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Quickfix-developers digest..."
> 
> 
> Today's Topics:
> 
>    1. (no subject) (Verma, Sanjay)
> 
> --__--__--
> 
> Message: 1
> From: "Verma, Sanjay" <SV...@Cr...>
> To: "'qui...@li...'"
>        <qui...@li...>
> Date: Tue, 9 Dec 2003 15:56:21 -0500
> Subject: [Quickfix-developers] (no subject)
> 
> This message is in MIME format. Since your mail
> reader does not understand
> this format, some or all of this message may not be
> legible.
> 
> ------_=_NextPart_001_01C3BE96.E65B49A0
> Content-Type: text/plain;
>       charset="iso-8859-1"
> 
> Is there anyway to force a sequence number in QF.
> Say I get sequence number
> 34 when I connect and logon to a counterparty. Is
> there a switch or a
> setting that tells QF "yes, the sequence number is
> incorrect but accept it
> and move on" as opposed to disconnecting the
> session.
> 
> Thanks.
> DISCLAIMER
> e-mail, and any attachments thereto, is intended
> only for use by the
> addressee(s) named herein and may contain legally
> privileged and/or
> confidential information. If you are not the
> intended recipient of this
> e-mail, you are hereby notified that any
> dissemination, distribution or
> copying of this e-mail, and any attachments thereto,
> is strictly
> prohibited.
> If you have received this e-mail in error, please
> immediately notify me and
> permanently delete the original and any copy of any
> e-mail and any printout
> thereof.
> 
> E-mail transmission cannot be guaranteed to be
> secure or error-free. The
> sender therefore does not accept liability for any
> errors or omissions in
> the contents of this message which arise as a result
> of e-mail
> transmission.
> REGARDING PRIVACY AND CONFIDENTIALITY
> Crown Financial Group may, at its discretion,
> monitor and review the
> content
> of all e-mail communications.
> 
> 
> ------_=_NextPart_001_01C3BE96.E65B49A0
> Content-Type: text/html;
>       charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type"
> CONTENT=3D"text/html; =
> charset=3Diso-8859-1">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange
> Server version =
> 5.5.2654.45">
> <TITLE></TITLE>
> </HEAD>
> <BODY>
> 
> <P><FONT SIZE=3D2 FACE=3D"Arial">Is there anyway to
> force a sequence =
> number in QF. Say I get sequence number 34 when I
> connect and logon to =
> a counterparty. Is there a switch or a setting that
> tells QF &quot;yes, =
> the sequence number is incorrect but accept it and
> move on&quot; as =
> opposed to disconnecting the session. </FONT></P>
> 
> <P><FONT SIZE=3D2 FACE=3D"Arial">Thanks. </FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Arial">DISCLAIMER</FONT>
> <BR><FONT SIZE=3D2 FACE=3D"Arial">e-mail, and any
> attachments thereto, =
> is intended only for use by the addressee(s) named
> herein and may =
> contain legally privileged and/or confidential
> information. If you are =
> not the intended recipient of this e-mail, you are
> hereby notified that =
> any dissemination, distribution or copying of this
> e-mail, and any =
> attachments thereto, is strictly prohibited. If you
> have received this =
> e-mail in error, please immediately notify me and
> permanently delete =
> the original and any copy of any e-mail and any
> printout =
> thereof.</FONT></P>
> 
> <P><FONT SIZE=3D2 FACE=3D"Arial">E-mail transmission
> cannot be =
> guaranteed to be secure or error-free. The sender
> therefore 
=== message truncated ===


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [Quickfix-developers] Order Type value (Market on close)

[Oren M. <ore...@ya...>]

The deprecation process is a little kooky and somewhat
manual.  When whole fields are deprecated it is pretty
easy because we just move the whole field to a
deprecated file and old versions continue to use it
happily.  What we currently don't handle so well is
the deprecation of some enumeration values within an
otherwise currently useful field.

The problem lies in the fact the the fields are
generated off of the most current XML, in this case
4.4.  These situations are so far pretty rare,
although they have become more common with the release
of 4.4.  What we may have to do is update the field
generator to use all available data dictionaries for
all supported versions, which will contain a union of
supported enumerations.

Other options are to create versions of each field in
different versioned namespaces like we do with
messages, but would personally like to avoid that kind
of bloat if possible.  Another possibility would be to
have separate enumeration groups for each version so
we would do things like OrdType_42_MARKET_ON_CLOSE.

I'd definately like to hear suggestions on this as it
will probably become a more serious issue with the
next FIX release.

--- Caleb Epstein <ca...@bk...> wrote:
> 
> On Wed, Dec 10, 2003 at 01:42:58PM -0500,
> bal...@ub... wrote:
> 
> > Hi folks, Does someone know why
> OrdType_MARKET_ON_CLOSE = '5'; value
> > got dropped in newer versions(1.6.0).
> 
> 	It may be in one of the deprecated headers, but in
> FIX 4.4,
> 	market on close is indicated with an OrdType(40) =
> MARKET(1)
> 	and TimeInForce(59) = AT_THE_CLOSE(7)
> 
> -- 
> Caleb Epstein |  bklyn . org  | This is a scsi
> driver, scraes the shit out
>     cae at    | Brooklyn Dust | of me, therefore I
> tapdanced and wrote a unix
> bklyn dot org |   Bunny Mfg.  | clone around it (C)
> by linus
>               |               | 	-- Somewhere in the
> kernel tree
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux
> Tutorials.
> Become an expert in LINUX or just sharpen your
> skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the
> bash shell to sys admin.
> Click now!
>
http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [Quickfix-developers] Order Type value (Market on close)

[Caleb E. <ca...@bk...>]

On Wed, Dec 10, 2003 at 01:42:58PM -0500, bal...@ub... wrote:

> Hi folks, Does someone know why OrdType_MARKET_ON_CLOSE = '5'; value
> got dropped in newer versions(1.6.0).

	It may be in one of the deprecated headers, but in FIX 4.4,
	market on close is indicated with an OrdType(40) = MARKET(1)
	and TimeInForce(59) = AT_THE_CLOSE(7)

-- 
Caleb Epstein |  bklyn . org  | This is a scsi driver, scraes the shit out
    cae at    | Brooklyn Dust | of me, therefore I tapdanced and wrote a unix
bklyn dot org |   Bunny Mfg.  | clone around it (C) by linus
              |               | 	-- Somewhere in the kernel tree

[Quickfix-developers] Order Type value (Market on close)

[<bal...@ub...>]

Hi folks,
	Does someone know why=20

OrdType_MARKET_ON_CLOSE =3D '5';

	value got dropped in newer versions(1.6.0).

thanks
-Balaji

This material has been prepared by UBS AG or an affiliate thereof
("UBS"). This material is a sales and trading communication and should
not be viewed as research. Opinions expressed herein are subject to
change without notice and may differ or be contrary to the opinions or
recommendations of UBS Investment research or the opinions expressed
by other business areas or groups of UBS as a result of using
different assumptions and criteria. Full details of UBS Investment
Research, if any, are available on request. Any prices or quotations
contained herein are indicative only and do not constitute an offer to
buy or sell any securities at any given price. No representation or
warranty, either express or implied, is provided in relation to the
accuracy, completeness, reliability or appropriateness of the
information, methodology and any derived price contained within this
material. The securities and related financial instruments described
herein may not be eligible for sale in all jurisdictions or to certain
categories of investors. Options, derivative products and futures are
not suitable for all investors, and trading in these instruments is
considered risky. Past performance is not necessarily indicative of
future results. Foreign currency rates of exchange may adversely
affect the value, price or income of any security or related
instrument mentioned in this report. UBS, its directors, officers and
employees or clients may have or have had interests or long or short
positions in the securities or related financial instruments referred
to herein, and may at any time make purchases and/or sales in them as
principal or agent. UBS may provide investment banking and other
services to and/or serve as directors of the companies referred to in
this material. Neither UBS its directors, employees or agents accept
any liability for any loss or damage arising out of the use of all or
any part of these materials. This material is distributed in the
following jurisdictions by: United Kingdom: UBS Limited, a subsidiary
of UBS AG, to persons who are market counterparties or intermediate
customers (as detailed in the FSA Rules) and is only available to such
persons. The information contained herein does not apply to, and
should not be relied upon by, private customers. Switzerland: UBS AG
to institutional investors only. Italy: Giubergia UBS SIM SpA, an
associate of UBS SA, in Milan. US: UBS Securities LLC or UBS Financial
Services Inc., subsidiaries of UBS AG, or solely to US institutional
investors by UBS AG or a subsidiary or affiliate thereof that is not
registered as a US broker-dealer (a "non-US affiliate"). Transactions
resulting from materials distributed by a non-US affiliate must be
effected through UBS Securities LLC or UBS Financial Services Inc.
Canada: UBS Securities Canada Inc., a subsidiary of UBS AG and a
member of the principal Canadian stock exchanges & CIPF. Japan: UBS
Securities Japan Ltd or UBS AG, Tokyo Branch, to institutional
investors only. Hong Kong: UBS Securities Asia Limited or UBS AG, Hong
Kong Branch. Singapore: UBS Securities Singapore Pte. Ltd or UBS AG,
Singapore Branch. Australia: UBS Advisory and Capital Markets
Australia Ltd and UBS Securities Australia Ltd. For additional
information or trade execution please contact your local sales or
trading contact.

Copyright 2003 UBS. All rights reserved. This material is strictly
for specified recipients only and may not be reproduced, distributed
or forwarded in any manner without the permission of UBS.

RE: [Quickfix-developers] Re: Sequence numbers

[Verma, S. <SV...@Cr...>]

You are right. Unfortunately the problem is that when using the Java =
version
of QF, numerous times the JVM simply crashes with no clue as to what
happened! Debugging Java and C++ together is a challange that I don't =
feel
like taking on (though as we speak I am looking at some tool called
JNI-Bridge). So I am trying to eliminate as many abnormal (or normal =
but
that lead to session disconnect) conditions as I can to get to the root =
of
the problem. If people in this community have had similar experience, =
i.e.
using Java version of QF, I'd love to share in it.=20

Thanks.
-----Original Message-----
From: ili...@bn... [mailto:ili...@bn...]
Sent: Wednesday, December 10, 2003 12:11 PM
To: qui...@li...
Subject: [Quickfix-developers] Re: Sequence numbers



Hi Sanjay,

Concordantly to the FIX protocol, QF allows you to receive a message =
with a
sequence number too high (it will issue a resend request for the =
missing
messages). On the contrary, a message with a sequence number too low =
will
end your session, and I don't think that you should try to make your =
engine
accept that kind of messages.

Regards,
Ilyas




Internet
qui...@li...@lists.sourceforge.net =
-
10/12/2003 05:09


Veuillez r=E9pondre =E0 qui...@li...

Envoy=E9 par :      qui...@li...

Pour : quickfix-developers

cc :


Objet :     Quickfix-developers digest, Vol 1 #378 - 1 msg


Send Quickfix-developers mailing list submissions to
      qui...@li...

To subscribe or unsubscribe via the World Wide Web, visit
      https://lists.sourceforge.net/lists/listinfo/quickfix-developers
or, via email, send a message with subject or body 'help' to
      qui...@li...

You can reach the person managing the list at
      qui...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Quickfix-developers digest..."


Today's Topics:

   1. (no subject) (Verma, Sanjay)

--__--__--

Message: 1
From: "Verma, Sanjay" <SV...@Cr...>
To: "'qui...@li...'"
       <qui...@li...>
Date: Tue, 9 Dec 2003 15:56:21 -0500
Subject: [Quickfix-developers] (no subject)

This message is in MIME format. Since your mail reader does not =
understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C3BE96.E65B49A0
Content-Type: text/plain;
      charset=3D"iso-8859-1"

Is there anyway to force a sequence number in QF. Say I get sequence =
number
34 when I connect and logon to a counterparty. Is there a switch or a
setting that tells QF "yes, the sequence number is incorrect but accept =
it
and move on" as opposed to disconnecting the session.

Thanks.
DISCLAIMER
e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly
prohibited.
If you have received this e-mail in error, please immediately notify me =
and
permanently delete the original and any copy of any e-mail and any =
printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free. =
The
sender therefore does not accept liability for any errors or omissions =
in
the contents of this message which arise as a result of e-mail
transmission.
REGARDING PRIVACY AND CONFIDENTIALITY
Crown Financial Group may, at its discretion, monitor and review the
content
of all e-mail communications.


------_=3D_NextPart_001_01C3BE96.E65B49A0
Content-Type: text/html;
      charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D3D"Content-Type" CONTENT=3D3D"text/html; =3D
charset=3D3Diso-8859-1">
<META NAME=3D3D"Generator" CONTENT=3D3D"MS Exchange Server version =3D
5.5.2654.45">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">Is there anyway to force a =
sequence =3D
number in QF. Say I get sequence number 34 when I connect and logon to =
=3D
a counterparty. Is there a switch or a setting that tells QF &quot;yes, =
=3D
the sequence number is incorrect but accept it and move on&quot; as =3D
opposed to disconnecting the session. </FONT></P>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">Thanks. </FONT>
<BR><FONT SIZE=3D3D2 FACE=3D3D"Arial">DISCLAIMER</FONT>
<BR><FONT SIZE=3D3D2 FACE=3D3D"Arial">e-mail, and any attachments =
thereto, =3D
is intended only for use by the addressee(s) named herein and may =3D
contain legally privileged and/or confidential information. If you are =
=3D
not the intended recipient of this e-mail, you are hereby notified that =
=3D
any dissemination, distribution or copying of this e-mail, and any =3D
attachments thereto, is strictly prohibited. If you have received this =
=3D
e-mail in error, please immediately notify me and permanently delete =
=3D
the original and any copy of any e-mail and any printout =3D
thereof.</FONT></P>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">E-mail transmission cannot be =3D
guaranteed to be secure or error-free. The sender therefore does not =
=3D
accept liability for any errors or omissions in the contents of this =
=3D
message which arise as a result of e-mail transmission.</FONT></P>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">REGARDING PRIVACY AND =3D
CONFIDENTIALITY</FONT>
<BR><FONT SIZE=3D3D2 FACE=3D3D"Arial">Crown Financial Group may, at its =
=3D
discretion, monitor and review the content of all e-mail =3D
communications.</FONT>
</P>

</BODY>
</HTML>
------_=3D_NextPart_001_01C3BE96.E65B49A0--



--__--__--

_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


End of Quickfix-developers Digest






This message and any attachments (the "message") is intended solely for =
the
addressees and is confidential.=20
If you receive this message in error, please delete it and immediately
notify the sender. Any use not in accord with=20
its purpose, any dissemination or disclosure, either whole or partial, =
is
prohibited except formal approval.=20
The internet can not guarantee the integrity of this message. BNP =
PARIBAS
(and its subsidiaries) shall (will) not=20
therefore be liable for the message if modified.=20

                ---------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message") sont =
etablis
a l'intention exclusive de ses=20
destinataires et sont confidentiels. Si vous recevez ce message par =
erreur,
merci de le detruire et d'en avertir=20
immediatement l'expediteur. Toute utilisation de ce message non =
conforme a
sa destination, toute diffusion=20
ou toute publication, totale ou partielle, est interdite, sauf =
autorisation
expresse. L'internet ne permettant pas=20
d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales)
decline(nt) toute responsabilite au titre de ce=20
message, dans l'hypothese ou il aurait ete modifie.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
DISCLAIMER
e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly =
prohibited.
If you have received this e-mail in error, please immediately notify me =
and
permanently delete the original and any copy of any e-mail and any =
printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free. =
The
sender therefore does not accept liability for any errors or omissions =
in
the contents of this message which arise as a result of e-mail =
transmission.
REGARDING PRIVACY AND CONFIDENTIALITY
Crown Financial Group may, at its discretion, monitor and review the =
content
of all e-mail communications.

[Quickfix-developers] Re: Sequence numbers

[<ili...@bn...>]

Hi Sanjay,

Concordantly to the FIX protocol, QF allows you to receive a message with a
sequence number too high (it will issue a resend request for the missing
messages). On the contrary, a message with a sequence number too low will
end your session, and I don't think that you should try to make your engine
accept that kind of messages.

Regards,
Ilyas




Internet
qui...@li...@lists.sourceforge.net -
10/12/2003 05:09


Veuillez r=E9pondre =E0 qui...@li...

Envoy=E9 par :      qui...@li...

Pour : quickfix-developers

cc :


Objet :     Quickfix-developers digest, Vol 1 #378 - 1 msg


Send Quickfix-developers mailing list submissions to
      qui...@li...

To subscribe or unsubscribe via the World Wide Web, visit
      https://lists.sourceforge.net/lists/listinfo/quickfix-developers
or, via email, send a message with subject or body 'help' to
      qui...@li...

You can reach the person managing the list at
      qui...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Quickfix-developers digest..."


Today's Topics:

   1. (no subject) (Verma, Sanjay)

--__--__--

Message: 1
From: "Verma, Sanjay" <SV...@Cr...>
To: "'qui...@li...'"
       <qui...@li...>
Date: Tue, 9 Dec 2003 15:56:21 -0500
Subject: [Quickfix-developers] (no subject)

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=3D_NextPart_001_01C3BE96.E65B49A0
Content-Type: text/plain;
      charset=3D"iso-8859-1"

Is there anyway to force a sequence number in QF. Say I get sequence number
34 when I connect and logon to a counterparty. Is there a switch or a
setting that tells QF "yes, the sequence number is incorrect but accept it
and move on" as opposed to disconnecting the session.

Thanks.
DISCLAIMER
e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly
prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail
transmission.
REGARDING PRIVACY AND CONFIDENTIALITY
Crown Financial Group may, at its discretion, monitor and review the
content
of all e-mail communications.


------_=3D_NextPart_001_01C3BE96.E65B49A0
Content-Type: text/html;
      charset=3D"iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D3D"Content-Type" CONTENT=3D3D"text/html; =3D
charset=3D3Diso-8859-1">
<META NAME=3D3D"Generator" CONTENT=3D3D"MS Exchange Server version =3D
5.5.2654.45">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">Is there anyway to force a sequence =3D
number in QF. Say I get sequence number 34 when I connect and logon to =3D
a counterparty. Is there a switch or a setting that tells QF &quot;yes, =3D
the sequence number is incorrect but accept it and move on&quot; as =3D
opposed to disconnecting the session. </FONT></P>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">Thanks. </FONT>
<BR><FONT SIZE=3D3D2 FACE=3D3D"Arial">DISCLAIMER</FONT>
<BR><FONT SIZE=3D3D2 FACE=3D3D"Arial">e-mail, and any attachments thereto, =
=3D
is intended only for use by the addressee(s) named herein and may =3D
contain legally privileged and/or confidential information. If you are =3D
not the intended recipient of this e-mail, you are hereby notified that =3D
any dissemination, distribution or copying of this e-mail, and any =3D
attachments thereto, is strictly prohibited. If you have received this =3D
e-mail in error, please immediately notify me and permanently delete =3D
the original and any copy of any e-mail and any printout =3D
thereof.</FONT></P>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">E-mail transmission cannot be =3D
guaranteed to be secure or error-free. The sender therefore does not =3D
accept liability for any errors or omissions in the contents of this =3D
message which arise as a result of e-mail transmission.</FONT></P>

<P><FONT SIZE=3D3D2 FACE=3D3D"Arial">REGARDING PRIVACY AND =3D
CONFIDENTIALITY</FONT>
<BR><FONT SIZE=3D3D2 FACE=3D3D"Arial">Crown Financial Group may, at its =3D
discretion, monitor and review the content of all e-mail =3D
communications.</FONT>
</P>

</BODY>
</HTML>
------_=3D_NextPart_001_01C3BE96.E65B49A0--



--__--__--

_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


End of Quickfix-developers Digest






This message and any attachments (the "message") is intended solely for the=
 addressees and is confidential.=20
If you receive this message in error, please delete it and immediately noti=
fy the sender. Any use not in accord with=20
its purpose, any dissemination or disclosure, either whole or partial, is p=
rohibited except formal approval.=20
The internet can not guarantee the integrity of this message. BNP PARIBAS (=
and its subsidiaries) shall (will) not=20
therefore be liable for the message if modified.=20

                ---------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message") sont etabli=
s a l'intention exclusive de ses=20
destinataires et sont confidentiels. Si vous recevez ce message par erreur,=
 merci de le detruire et d'en avertir=20
immediatement l'expediteur. Toute utilisation de ce message non conforme a =
sa destination, toute diffusion=20
ou toute publication, totale ou partielle, est interdite, sauf autorisation=
 expresse. L'internet ne permettant pas=20
d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(=
nt) toute responsabilite au titre de ce=20
message, dans l'hypothese ou il aurait ete modifie.

[Quickfix-developers] (no subject)

[Verma, S. <SV...@Cr...>]

Is there anyway to force a sequence number in QF. Say I get sequence number
34 when I connect and logon to a counterparty. Is there a switch or a
setting that tells QF "yes, the sequence number is incorrect but accept it
and move on" as opposed to disconnecting the session. 

Thanks. 
DISCLAIMER
e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof.

E-mail transmission cannot be guaranteed to be secure or error-free. The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.
REGARDING PRIVACY AND CONFIDENTIALITY
Crown Financial Group may, at its discretion, monitor and review the content
of all e-mail communications.

[Quickfix-developers] Unit Test Failures

[Mark P. <mar...@md...>]

Hi,

Im new to QuickFIX and just trying to run the unit test. Does anyone know
what the following failures in the output relate to.

Regards,

Mark Priestner


C:\Develop\QuickFIX\test>runut debug 5001

C:\Develop\QuickFIX\test>echo off
<ut>
  <output>
............................................................................
..F.
F................................................
  </output>
  <results total="129" failures="2">
    <failure  line= "838" file= "src\C++\test\SessionTestCase.cpp">
      <test>
        <![CDATA[ class FIX::SessionTestCase::resetOnEndTime]]>
      </test>
      <text>
        <![CDATA[ assert(m_disconnect == 1)]]>
      </text>
    </failure>
    <failure  line= "0" file= "unknown">
      <test>
        <![CDATA[ class CPPTest::Test<class FIX::Session> *]]>
      </test>
      <text>
        <![CDATA[ assert(no futher information available)]]>
      </text>
    </failure>
  </results>
</ut>

C:\Develop\QuickFIX\test>

[Quickfix-developers] Runut Tests

[Jon D. <jd...@li...>]

I ran the ut tests in both debug and release. Release was fine however, =
Debug failed on one test

Here is the output:

<ut>
  <output>
.........................................................................=
.............................F..........................
  </output>
  <results total=3D"129" failures=3D"1">
    <error line=3D "0" file=3D "unknown">
      <test>
        <![CDATA[ class CPPTest::Test<class FIX::Dictionary> *]]>
      </test>
      <text>
        <![CDATA[ no futher information available]]>
      </text>
    </error>
  </results>
</ut>

I'm using MS VC++ SP5. Windows PSDK Feb 2003 and STLPort 4.6

Any help would be appreciated.

Thanks,

JD

Re: [Quickfix-developers] STLPort With MSVC

[Oren M. <ore...@ya...>]

Well the *nix version requires a configuration flag
that tells the compiler where to find the stlport
header files and library.  The equivalent process in
windows would be to setup STLPORT with msvc and
recompile quickFIX, or to modify the QuickFIX project
file to tell it where to find the header files and
library.

--oren

--- Jon Dahl <jd...@li...> wrote:
> Does anyone out there use STLPort with Quickfix on
> the Windows Platform?
> 
> I noticed the *NIX version requires a compiler flag
> to use STLPort. Any
> reason to do the same with MSVC?
> 
> 
> TIA,
> 
> JD
> 
> OS:W2K SP4
> MS VC 6 SP5
> Lastest STL Port
> Lastest Platform SDK for Windows
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by OSDN's Audience
> Survey.
> Help shape OSDN's sites and tell us what you think.
> Take this
> five minute survey and you could win a $250 Gift
> Certificate.
> http://www.wrgsurveys.com/2003/osdntech03.php?site=8
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

[Quickfix-developers] STLPort With MSVC

[Jon D. <jd...@li...>]

Does anyone out there use STLPort with Quickfix on the Windows Platform?

I noticed the *NIX version requires a compiler flag to use STLPort. Any
reason to do the same with MSVC?


TIA,

JD

OS:W2K SP4
MS VC 6 SP5
Lastest STL Port
Lastest Platform SDK for Windows

[Quickfix-developers] withinHeartBeat()

[Daniel M. <Dan...@ma...>]

Could someone explain why withinHeartBeat() is implemented as:

bool withinHeartBeat() const
  {
    UtcTimeStamp now;
    return ( ( now - lastSentTime() ) < heartBtInt() ) &&
           ( ( now - lastReceivedTime() ) < heartBtInt() );
  }
 =20
rather than:

bool withinHeartBeat() const
  {
    UtcTimeStamp now;
    return ( ( now - lastSentTime() ) < heartBtInt() );
  }

The FIX spec says the heartbeat interval is the time when the last
message was sent, not sent
AND received.

Daniel May


 =20

[Quickfix-developers] Calling fromAdmin() before disconnect

[Daniel M. <Dan...@ma...>]

I am looking at adding a change to Session.cpp that would allow
fromAdmin() to be called with the offending message
that failed the validLogonState() test.  Here is the scenario, I try to
logon to a FIX server but my logon gets rejected for
any number of reasons, sequence number too low, invalid permissions,
etc.  Some FIX servers send back a Logout Message,
some send a Reject Message with a text field explaining why the logon
was denied or rejected.  I think it is reasonable
to allow the application to inspect these return messages.
=20
I propose the following in Session.cpp:
=20
change line 880 from:

catch ( std::exception& )
{ disconnect(); return false; }

=20

to:

catch ( std::exception& )
{=20
    if ( Message::isAdminMsgType( msgType ) )
      fromCallback( msgType, msg, m_sessionID );
    disconnect();=20
    return false;=20
}

Daniel May


 =20


=20

=20

=20

RE: [Quickfix-developers] Incorrect threading function.

[Daniel M. <Dan...@ma...>]

I have fixed the issues below, and will check them in after I do some
more testing.  Please comment
on any possible side effects these changes may have.

1. I found the documentation that warns against using _beginthread with
synchronization API's:=20
=20
"The _beginthreadex function gives you more control over how the thread
is created than _beginthread does. The _endthreadex function is also
more flexible. For example, with _beginthreadex, you can use security
information, set the initial state of the thread (running or suspended),
and get the thread identifier of the newly created thread. You are also
able to use the thread handle returned by _beginthreadex with the
synchronization APIs, which you cannot do with _beginthread.=20

It is safer to use _beginthreadex than _beginthread. If the thread
spawned by _beginthread exits quickly, the handle returned to the caller
of _beginthread may be invalid or, worse, point to another thread.
However, the handle returned by _beginthreadex has to be closed by the
caller of _beginthreadex, so it is guaranteed to be a valid handle if
_beginthreadex did not return an error. "

Since _beginthread had a different prototype for the function being
spawned than _beginthreadex does, I defined the
following:

  #ifdef _MSC_VER
  typedef unsigned int (_stdcall THREAD_START_ROUTINE)(void *);
  #define  THREAD_PROC unsigned int _stdcall=20
  #else
  typedef void * (THREAD_START_ROUTINE)(void *);
  #define THREAD_PROC void *
  #endif

  bool thread_spawn( THREAD_START_ROUTINE func, void* var, unsigned&
thread );
  bool thread_spawn( THREAD_START_ROUTINE, void* var );

I then changed the return type of the thread functions from void * to
THREAD_PROC .  This way only the Windows
code is actually changed.

2. I saw the potential problem for the race condition, but did not have
an elegant solution.  Here is what I did
   as a work around:

void SocketAcceptor::onStart()
{ QF_STACK_PUSH(SocketAcceptor::onStart)
  m_running =3D  true;
  while ( !m_stop && m_pServer && m_pServer->block( *this ) ) {}
  m_running =3D  false;
  QF_STACK_POP
}

void SocketAcceptor::onStop()
{ QF_STACK_PUSH(SocketAcceptor::onStop)

  m_stop =3D true;

  while(m_running)
     process_sleep(0);

  if ( m_pServer )=20
  {
    m_pServer->close();=20
    delete m_pServer;
  }

  QF_STACK_POP
}

3. I changed GetCurrentThread() to GetCurrentThreadId().

Daniel May


=20

-----Original Message-----
From: Timothy Yates [mailto:ty...@pa...]=20
Sent: Friday, November 21, 2003 9:50 AM
To: Daniel May
Subject: RE: [Quickfix-developers] Incorrect threading function.

I am not a registered quickfix developer, so the answer is no.

I just thought you guys might want to know about some problems I've
found.

-----Original Message-----
From: Daniel May [mailto:Dan...@ma...]
Sent: Friday, November 21, 2003 5:39 AM
To: qui...@li...
Cc: ty...@pa...
Subject: RE: [Quickfix-developers] Incorrect threading function.


Tim,
Have you checked these changes into CVS ?

Daniel May
da...@ma...

--__--__--

Message: 2
From: Timothy Yates <ty...@pa...>
To: "'qui...@li...'"
	 <qui...@li...>
Date: Thu, 20 Nov 2003 16:06:58 -0000
Subject: [Quickfix-developers] Incorrect threading function.

I am using the Java quickfix API and running on a fast (3GHz) processor
on Windows XP.

I have encountered a number of threading problems.

1. It is quite common for QuickFIX to lock up in Acceptor.stop().  The
lock-up occurs due to incorrect implementation of
thread_spawn/thread_join.
These should use _beginthreadex, not _beginthread.  In the current
implementation (using _beginthread), the call too WaitForSingleObject()
generally fails because the handle it is waiting for has already been
closed automatically by _beginthread.  Sometimes, WaitForSingleObject()
blocks indefinitely even though the acceptor thread has exited.  This
may be because it is waiting on an incorrect handle for which no event
is likely to be signalled.  In any case, the Windows documentation
advises against using _beginthread and WaitForSingleObject together.

2. When stopping a SocketAcceptor there is a race condition between
completion of the acceptor thread function and destruction of the
SocketServer object.  Since the thread function uses the SocketServer
object,  it should not be destroyed until the thread function has
completed.
I'm not sure that this is causing problems, but it looks dangerous.

3. The stack trace facility (QF_STACK_PUSH/QF_STACK_POP) does not work
on Windows.  This is due to incorrect implementation of thread_self().
GetCurrentThread() returns a pseudo handle, which seems to be the same
irrespective of thread.  I replaced this with a call to
GetCurrentThreadId().

Tim Yates
Lead Developer
Patsystems (US) LLC
141 West Jackson Boulevard
Chicago 60604, USA
Tel +1 (312) 542-1336
www.patsystems.com=20


DISCLAIMER: This e-mail is confidential and may also be legally
privileged.
If you are not the intended recipient, use of the information contained
in this e-mail (including disclosure, copying or distribution) is
prohibited and may be unlawful.  Please inform the sender and delete the
message immediately from your system.  This e-mail is attributed to the
sender and may not necessarily reflect the views of the Patsystems Group
and no member of the Patsystems Group accepts any liability for any
action taken in reliance on the contents of this e-mail (other than
where it has a legal or regulatory obligation to do so) or for the
consequences of any computer viruses which may have been transmitted by
this e-mail. The Patsystems Group comprises Patsystems plc and its
subsidiary group of companies.



--__--__--

_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


End of Quickfix-developers Digest
DISCLAIMER: This e-mail is confidential and may also be legally
privileged.
If you are not the intended recipient, use of the information contained
in this e-mail (including disclosure, copying or distribution) is
prohibited and may be unlawful.  Please inform the sender and delete the
message immediately from your system.  This e-mail is attributed to the
sender and may not necessarily reflect the views of the Patsystems Group
and no member of the Patsystems Group accepts any liability for any
action taken in reliance on the contents of this e-mail (other than
where it has a legal or regulatory obligation to do so) or for the
consequences of any computer viruses which may have been transmitted by
this e-mail. The Patsystems Group comprises Patsystems plc and its
subsidiary group of companies.

RE: [Quickfix-developers] Incorrect threading function.

[Daniel M. <Dan...@ma...>]

Tim,
Have you checked these changes into CVS ?

Daniel May
da...@ma...

--__--__--

Message: 2
From: Timothy Yates <ty...@pa...>
To: "'qui...@li...'"
	 <qui...@li...>
Date: Thu, 20 Nov 2003 16:06:58 -0000
Subject: [Quickfix-developers] Incorrect threading function.

I am using the Java quickfix API and running on a fast (3GHz) processor
on Windows XP.

I have encountered a number of threading problems.

1. It is quite common for QuickFIX to lock up in Acceptor.stop().  The
lock-up occurs due to incorrect implementation of
thread_spawn/thread_join.
These should use _beginthreadex, not _beginthread.  In the current
implementation (using _beginthread), the call too WaitForSingleObject()
generally fails because the handle it is waiting for has already been
closed automatically by _beginthread.  Sometimes, WaitForSingleObject()
blocks indefinitely even though the acceptor thread has exited.  This
may be because it is waiting on an incorrect handle for which no event
is likely to be signalled.  In any case, the Windows documentation
advises against using _beginthread and WaitForSingleObject together.

2. When stopping a SocketAcceptor there is a race condition between
completion of the acceptor thread function and destruction of the
SocketServer object.  Since the thread function uses the SocketServer
object,  it should not be destroyed until the thread function has
completed.
I'm not sure that this is causing problems, but it looks dangerous.

3. The stack trace facility (QF_STACK_PUSH/QF_STACK_POP) does not work
on Windows.  This is due to incorrect implementation of thread_self().
GetCurrentThread() returns a pseudo handle, which seems to be the same
irrespective of thread.  I replaced this with a call to
GetCurrentThreadId().

Tim Yates
Lead Developer
Patsystems (US) LLC
141 West Jackson Boulevard
Chicago 60604, USA
Tel +1 (312) 542-1336
www.patsystems.com=20


DISCLAIMER: This e-mail is confidential and may also be legally
privileged.
If you are not the intended recipient, use of the information contained
in this e-mail (including disclosure, copying or distribution) is
prohibited and may be unlawful.  Please inform the sender and delete the
message immediately from your system.  This e-mail is attributed to the
sender and may not necessarily reflect the views of the Patsystems Group
and no member of the Patsystems Group accepts any liability for any
action taken in reliance on the contents of this e-mail (other than
where it has a legal or regulatory obligation to do so) or for the
consequences of any computer viruses which may have been transmitted by
this e-mail. The Patsystems Group comprises Patsystems plc and its
subsidiary group of companies.



--__--__--

_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


End of Quickfix-developers Digest

[Quickfix-developers] Incorrect threading function.

[Timothy Y. <ty...@pa...>]

I am using the Java quickfix API and running on a fast (3GHz) processor on
Windows XP.

I have encountered a number of threading problems.

1. It is quite common for QuickFIX to lock up in Acceptor.stop().  The
lock-up occurs due to incorrect implementation of  thread_spawn/thread_join.
These should use _beginthreadex, not _beginthread.  In the current
implementation (using _beginthread), the call too WaitForSingleObject()
generally fails because the handle it is waiting for has already been closed
automatically by _beginthread.  Sometimes, WaitForSingleObject() blocks
indefinitely even though the acceptor thread has exited.  This may be
because it is waiting on an incorrect handle for which no event is likely to
be signalled.  In any case, the Windows documentation advises against using
_beginthread and WaitForSingleObject together.

2. When stopping a SocketAcceptor there is a race condition between
completion of the acceptor thread function and destruction of the
SocketServer object.  Since the thread function uses the SocketServer
object,  it should not be destroyed until the thread function has completed.
I'm not sure that this is causing problems, but it looks dangerous.

3. The stack trace facility (QF_STACK_PUSH/QF_STACK_POP) does not work on
Windows.  This is due to incorrect implementation of thread_self().
GetCurrentThread() returns a pseudo handle, which seems to be the same
irrespective of thread.  I replaced this with a call to
GetCurrentThreadId().

Tim Yates
Lead Developer 
Patsystems (US) LLC 
141 West Jackson Boulevard
Chicago 60604, USA 
Tel +1 (312) 542-1336 
www.patsystems.com 


DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful.  Please inform the sender and delete the message
immediately from your system.  This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.

Re: [Quickfix-developers] RE: QuickFix 4.4 Support For .NET

[Oren M. <ore...@ya...>]

I've split them, but I was getting in three of the
messages INTERNAL COMPILER ERROR 1001.  I did some
experimenting and it looks to me like there is a bug
in the managed C++ compiler where it breaks if there
are more than 17 inner classes.  I was able to
demonstrate the problem with this bit of code:

#using <mscorlib.dll>

public __gc class mainclass
{
  __gc class class1 {};
  __gc class class2 {};
  __gc class class3 {};
  __gc class class4 {};
  __gc class class5 {};
  __gc class class6 {};
  __gc class class7 {};
  __gc class class8 {};
  __gc class class9 {};
  __gc class class10 {};
  __gc class class11 {};
  __gc class class12 {};
  __gc class class13 {};
  __gc class class14 {};
  __gc class class15 {};
  __gc class class16 {};
  __gc class class17 {};
  __gc class class18 {};
};

This chokes the compiler, but if you remove class18,
it's fine.  Does anyone know if this is a known
problem with the managed c++ compiler and if there is
a patch available?

--- LeRoi Beukes <le...@pe...> wrote:
> Hi
> 
> Any Idea when this will be available ?
> I know about the COFF Error (number of sections
> exceeded blah blah)
> 
> Anyone know how I can get past this (other than
> splitting up the header
> files ... ?)
> 
> Tx
> Bye
> Le Roi
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive? 
> Does it
> help you create better code?  SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/