quickfix-developers — QuickFIX developers forum

RE: [Quickfix-developers] Connecting/disconnecting fails

[Francis G. <fr...@at...>]

I forgot to mention that I'm using the .NET 1.10.2 version.
 
Francis

  _____  

From: Oren Miller
Sent: Tuesday, July 05, 2005 21:48
To: Francis Gingras; qui...@li...
Subject: Re: [Quickfix-developers] Connecting/disconnecting fails


Version?

----- Original Message ----- 
From: Francis  <mailto:fr...@at...> Gingras 
To: qui...@li... 
Sent: Tuesday, July 05, 2005 8:40 PM
Subject: [Quickfix-developers] Connecting/disconnecting fails

I am having a problem when connecting/disconnecting.  The 3rd logon always
fails and the sequence numbers are not reset.
 
This is the log from a ThreadedInitiator running the latest sources.
 

Outgoing:
8=FIX.4.2
9=85
35=A
34=1
49=FIXUSER
52=20050706-00:16:38.828
56=ORDERS
96=FI
XPASS
98=0
108=30
141=Y
10=246

8=FIX.4.2
9=56
35=5
34=2
49=FIXUSER
52=20050706-00:16:46.703
56=ORDERS
10=20
7

8=FIX.4.2
9=85
35=A
34=1
49=FIXUSER
52=20050706-00:16:50.968
56=ORDERS
96=FI
XPASS
98=0
108=30
141=Y
10=245

8=FIX.4.2
9=56
35=5
34=2
49=FIXUSER
52=20050706-00:17:00.578
56=ORDERS
10=20
8

8=FIX.4.2
9=85
35=A
34=3
49=FIXUSER
52=20050706-00:17:05.093
56=ORDERS
96=FI
XPASS
98=0
108=30
141=Y
10=237

8=FIX.4.2
9=105
35=5
34=4
49=FIXUSER
52=20050706-00:17:05.109
56=ORDERS
58=M
sgSeqNum too low, expecting 2 but received 1
10=143

 

Incoming:
8=FIX.4.2
9=00074
35=A
49=ORDERS
56=FIXUSER
34=1
52=20050706-00:16:38.921
10
8=30
141=Y
98=0
10=179

8=FIX.4.2
9=00074
35=A
49=ORDERS
56=FIXUSER
34=1
52=20050706-00:16:50.968
10
8=30
141=Y
98=0
10=184

8=FIX.4.2
9=00074
35=A
49=ORDERS
56=FIXUSER
34=1
52=20050706-00:17:05.109
10
8=30
141=Y
98=0
10=172

 
Events:
20050706-00:16:38 : Created session
20050706-00:16:38 : Connecting to 127.0.0.1 on port 10501
20050706-00:16:38 : Connection succeeded
20050706-00:16:38 : Initiated logon request
20050706-00:16:38 : Logon contains ResetSeqNumFlag=Y, reseting sequence
numbers to 1
20050706-00:16:38 : Received logon response
20050706-00:16:46 : Initiated logout request
20050706-00:16:46 : Socket Error: Connection reset by peer.
20050706-00:16:46 : Disconnecting
20050706-00:16:50 : Created session
20050706-00:16:50 : Connecting to 127.0.0.1 on port 10501
20050706-00:16:50 : Connection succeeded
20050706-00:16:50 : Initiated logon request
20050706-00:16:50 : Logon contains ResetSeqNumFlag=Y, reseting sequence
numbers to 1
20050706-00:16:50 : Received logon response
20050706-00:17:00 : Initiated logout request
20050706-00:17:00 : Socket Error: Connection reset by peer.
20050706-00:17:00 : Disconnecting
20050706-00:17:04 : Created session
20050706-00:17:05 : Connecting to 127.0.0.1 on port 10501
20050706-00:17:05 : Connection succeeded
20050706-00:17:05 : Initiated logon request
20050706-00:17:05 : Logon contains ResetSeqNumFlag=Y, reseting sequence
numbers to 1
20050706-00:17:05 : MsgSeqNum too low, expecting 2 but received 1
20050706-00:17:05 : Disconnecting
20050706-00:17:05 : Socket Error
20050706-00:17:05 : Initiated logon request
 
I'm not reporting this as a bug because I'm not sure if this happening
because the server is sending MsgSeqNum = 1 after the logon request.
 
1) Since all the server messages are the same, why is QF throwing a
MsgSeqNum too low only on the third login?
2) Why isn't QF resetting the MsgSeqNums after the second logoff?
3) Both ResetOnLogout and ResetOnDisconnect and enabled.  If I disable them,
I get this error on the second login.
4) The code calls socket.stop() to disconnect and a new socket is
instantiated before every socket.start().
 
Thanks,
 
Francis

Re: [Quickfix-developers] Connecting/disconnecting fails

[Oren M. <or...@qu...>]

Version?
  ----- Original Message -----=20
  From: Francis Gingras=20
  To: qui...@li...=20
  Sent: Tuesday, July 05, 2005 8:40 PM
  Subject: [Quickfix-developers] Connecting/disconnecting fails


  I am having a problem when connecting/disconnecting.  The 3rd logon =
always fails and the sequence numbers are not reset.

  This is the log from a ThreadedInitiator running the latest sources.

  Outgoing:
  =
8=3DFIX.4.2=019=3D85=0135=3DA=0134=3D1=0149=3DFIXUSER=0152=3D20050706-00:=
16:38.828=0156=3DORDERS=0196=3DFIXPASS=0198=3D0=01108=3D30=01141=3DY=0110=
=3D246=01
  =
8=3DFIX.4.2=019=3D56=0135=3D5=0134=3D2=0149=3DFIXUSER=0152=3D20050706-00:=
16:46.703=0156=3DORDERS=0110=3D207=01
  =
8=3DFIX.4.2=019=3D85=0135=3DA=0134=3D1=0149=3DFIXUSER=0152=3D20050706-00:=
16:50.968=0156=3DORDERS=0196=3DFIXPASS=0198=3D0=01108=3D30=01141=3DY=0110=
=3D245=01
  =
8=3DFIX.4.2=019=3D56=0135=3D5=0134=3D2=0149=3DFIXUSER=0152=3D20050706-00:=
17:00.578=0156=3DORDERS=0110=3D208=01
  =
8=3DFIX.4.2=019=3D85=0135=3DA=0134=3D3=0149=3DFIXUSER=0152=3D20050706-00:=
17:05.093=0156=3DORDERS=0196=3DFIXPASS=0198=3D0=01108=3D30=01141=3DY=0110=
=3D237=01
  =
8=3DFIX.4.2=019=3D105=0135=3D5=0134=3D4=0149=3DFIXUSER=0152=3D20050706-00=
:17:05.109=0156=3DORDERS=0158=3DMsgSeqNum too low, expecting 2 but =
received 1=0110=3D143=01

  Incoming:
  =
8=3DFIX.4.2=019=3D00074=0135=3DA=0149=3DORDERS=0156=3DFIXUSER=0134=3D1=01=
52=3D20050706-00:16:38.921=01108=3D30=01141=3DY=0198=3D0=0110=3D179=01
  =
8=3DFIX.4.2=019=3D00074=0135=3DA=0149=3DORDERS=0156=3DFIXUSER=0134=3D1=01=
52=3D20050706-00:16:50.968=01108=3D30=01141=3DY=0198=3D0=0110=3D184=01
  =
8=3DFIX.4.2=019=3D00074=0135=3DA=0149=3DORDERS=0156=3DFIXUSER=0134=3D1=01=
52=3D20050706-00:17:05.109=01108=3D30=01141=3DY=0198=3D0=0110=3D172=01

  Events:
  20050706-00:16:38 : Created session
  20050706-00:16:38 : Connecting to 127.0.0.1 on port 10501
  20050706-00:16:38 : Connection succeeded
  20050706-00:16:38 : Initiated logon request
  20050706-00:16:38 : Logon contains ResetSeqNumFlag=3DY, reseting =
sequence numbers to 1
  20050706-00:16:38 : Received logon response
  20050706-00:16:46 : Initiated logout request
  20050706-00:16:46 : Socket Error: Connection reset by peer.
  20050706-00:16:46 : Disconnecting
  20050706-00:16:50 : Created session
  20050706-00:16:50 : Connecting to 127.0.0.1 on port 10501
  20050706-00:16:50 : Connection succeeded
  20050706-00:16:50 : Initiated logon request
  20050706-00:16:50 : Logon contains ResetSeqNumFlag=3DY, reseting =
sequence numbers to 1
  20050706-00:16:50 : Received logon response
  20050706-00:17:00 : Initiated logout request
  20050706-00:17:00 : Socket Error: Connection reset by peer.
  20050706-00:17:00 : Disconnecting
  20050706-00:17:04 : Created session
  20050706-00:17:05 : Connecting to 127.0.0.1 on port 10501
  20050706-00:17:05 : Connection succeeded
  20050706-00:17:05 : Initiated logon request
  20050706-00:17:05 : Logon contains ResetSeqNumFlag=3DY, reseting =
sequence numbers to 1
  20050706-00:17:05 : MsgSeqNum too low, expecting 2 but received 1
  20050706-00:17:05 : Disconnecting
  20050706-00:17:05 : Socket Error
  20050706-00:17:05 : Initiated logon request

  I'm not reporting this as a bug because I'm not sure if this happening =
because the server is sending MsgSeqNum =3D 1 after the logon request.

  1) Since all the server messages are the same, why is QF throwing a =
MsgSeqNum too low only on the third login?
  2) Why isn't QF resetting the MsgSeqNums after the second logoff?
  3) Both ResetOnLogout and ResetOnDisconnect and enabled.  If I disable =
them, I get this error on the second login.
  4) The code calls socket.stop() to disconnect and a new socket is =
instantiated before every socket.start().

  Thanks,

  Francis

[Quickfix-developers] Connecting/disconnecting fails

[Francis G. <fr...@at...>]

I am having a problem when connecting/disconnecting.  The 3rd logon always
fails and the sequence numbers are not reset.
 
This is the log from a ThreadedInitiator running the latest sources.
 
Outgoing:
8=FIX.4.2
9=85
35=A
34=1
49=FIXUSER
52=20050706-00:16:38.828
56=ORDERS
96=FI
XPASS
98=0
108=30
141=Y
10=246

8=FIX.4.2
9=56
35=5
34=2
49=FIXUSER
52=20050706-00:16:46.703
56=ORDERS
10=20
7

8=FIX.4.2
9=85
35=A
34=1
49=FIXUSER
52=20050706-00:16:50.968
56=ORDERS
96=FI
XPASS
98=0
108=30
141=Y
10=245

8=FIX.4.2
9=56
35=5
34=2
49=FIXUSER
52=20050706-00:17:00.578
56=ORDERS
10=20
8

8=FIX.4.2
9=85
35=A
34=3
49=FIXUSER
52=20050706-00:17:05.093
56=ORDERS
96=FI
XPASS
98=0
108=30
141=Y
10=237

8=FIX.4.2
9=105
35=5
34=4
49=FIXUSER
52=20050706-00:17:05.109
56=ORDERS
58=M
sgSeqNum too low, expecting 2 but received 1
10=143

 
Incoming:
8=FIX.4.2
9=00074
35=A
49=ORDERS
56=FIXUSER
34=1
52=20050706-00:16:38.921
10
8=30
141=Y
98=0
10=179

8=FIX.4.2
9=00074
35=A
49=ORDERS
56=FIXUSER
34=1
52=20050706-00:16:50.968
10
8=30
141=Y
98=0
10=184

8=FIX.4.2
9=00074
35=A
49=ORDERS
56=FIXUSER
34=1
52=20050706-00:17:05.109
10
8=30
141=Y
98=0
10=172

 
Events:
20050706-00:16:38 : Created session
20050706-00:16:38 : Connecting to 127.0.0.1 on port 10501
20050706-00:16:38 : Connection succeeded
20050706-00:16:38 : Initiated logon request
20050706-00:16:38 : Logon contains ResetSeqNumFlag=Y, reseting sequence
numbers to 1
20050706-00:16:38 : Received logon response
20050706-00:16:46 : Initiated logout request
20050706-00:16:46 : Socket Error: Connection reset by peer.
20050706-00:16:46 : Disconnecting
20050706-00:16:50 : Created session
20050706-00:16:50 : Connecting to 127.0.0.1 on port 10501
20050706-00:16:50 : Connection succeeded
20050706-00:16:50 : Initiated logon request
20050706-00:16:50 : Logon contains ResetSeqNumFlag=Y, reseting sequence
numbers to 1
20050706-00:16:50 : Received logon response
20050706-00:17:00 : Initiated logout request
20050706-00:17:00 : Socket Error: Connection reset by peer.
20050706-00:17:00 : Disconnecting
20050706-00:17:04 : Created session
20050706-00:17:05 : Connecting to 127.0.0.1 on port 10501
20050706-00:17:05 : Connection succeeded
20050706-00:17:05 : Initiated logon request
20050706-00:17:05 : Logon contains ResetSeqNumFlag=Y, reseting sequence
numbers to 1
20050706-00:17:05 : MsgSeqNum too low, expecting 2 but received 1
20050706-00:17:05 : Disconnecting
20050706-00:17:05 : Socket Error
20050706-00:17:05 : Initiated logon request
 
I'm not reporting this as a bug because I'm not sure if this happening
because the server is sending MsgSeqNum = 1 after the logon request.
 
1) Since all the server messages are the same, why is QF throwing a
MsgSeqNum too low only on the third login?
2) Why isn't QF resetting the MsgSeqNums after the second logoff?
3) Both ResetOnLogout and ResetOnDisconnect and enabled.  If I disable them,
I get this error on the second login.
4) The code calls socket.stop() to disconnect and a new socket is
instantiated before every socket.start().
 
Thanks,
 
Francis

Re: [Quickfix-developers] CharConvertor::convert( char value ) bug

[Alexey Z. <ale...@in...>]

I added a bug #85 -> missing milliseconds.


Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305



Oren Miller wrote:

> It just got missed.  If you want to be sure a patch makes it in, best 
> to report it to the bugtracker 
> (http://www.quickfixengine.org/bugtracker 
> <http://www.quickfixengine.org/bugtracker>).  You can see with all the 
> volume on a day like today things can get lost in the shuffle if you 
> just rely reporting to the mailing list.
>  
> --oren
>
>     ----- Original Message -----
>     *From:* Alexey Zubko <mailto:ale...@in...>
>     *To:* azz...@ya...
>     <mailto:azz...@ya...>
>     *Cc:* qui...@li...
>     <mailto:qui...@li...>
>     *Sent:* Tuesday, July 05, 2005 2:23 PM
>     *Subject:* Re: [Quickfix-developers] CharConvertor::convert( char
>     value ) bug
>
>     Brian,
>
>     I know what the problem is.
>
>     See my posting:
>       some changes in C++ version
>     <http://sourceforge.net/mailarchive/forum.php?thread_id=7465814&forum_id=103>
>     	Alexey Zubko <alexey@in...> 	2 	2005-06-09 06:06
>
>
>     Is there a reason not to put this patch to the version?
>
>Regards,
>		Alexey Zubko
>
>Infinium Capital Corporation
>(416) 360-7000 ext. 305
>    
>
>
>
>     Brian Erst wrote:
>
>>Quick patch that would fix this problem (QF 1.9.4):
>>
>>FieldConverters.h:
>>
>>249 struct CharConvertor
>>250 {
>>251    static std::string convert( char value )
>>252    {
>>++        if (value)
>>253         return std::string( 1, value );
>>++        else
>>++          return std::string("");
>>254    }
>>
>>The problem is that the std::string template either has a "feature" or
>>a "bug" that doesn't check if the results of a char-based
>>initialization will cause a weird disconnect between the encapsulated
>>C-string (c_str) and the length/size member. The size or length
>>reported from such an initialization will be "1", even though the
>>size/length of c_str is "0".
>>
>>Changing the initialization to use an empty string when the char value
>>is null should fix this problem.
>>
>>- Brian Erst
>>Thynk Software, Inc.
>>
>>
>>
>>
>>--- Alexey Zubko <ale...@in...> wrote:
>>
>>  
>>
>>>QuickFIX Documentation:
>>>http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>QuickFIX FAQ:
>>>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>>Guys,
>>>
>>>I don't want to annoy you, but I think the following bug must be
>>>fixed.
>>>I reported about it early and I thought it would be a part of this
>>>release.
>>>
>>>I think quickfix must be more stable for this cases. At least throw 
>>>something like InvalidFieldValue...
>>>
>>>Here is the example:
>>>
>>>    char                                
>>>its_just_a_bug_or_wrong_input = 
>>>'\0';
>>>// oops!
>>>    FIX::OrdStatus                OrdStatus =
>>>its_just_a_bug_or_wrong_input;
>>>
>>>    FIX::Message                  message;
>>>    message.setField(OrdStatus);
>>>    message.setField(FIX::TransactTime());
>>>
>>>// now we send the message:
>>>    std::string        str;
>>>    message.toString(str);    // result: "9=26|39="
>>>
>>>
>>>
>>>-- 
>>>
>>>Regards,
>>>		Alexey Zubko
>>>
>>>Infinium Capital Corporation
>>>(416) 360-7000 ext. 305
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is sponsored by: Discover Easy Linux Migration
>>>Strategies
>>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>informative Webcasts and more! Get everything you need to get up to
>>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>_______________________________________________
>>>Quickfix-developers mailing list
>>>Qui...@li...
>>>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>>    
>>>
>>
>>
>>  
>>

Re: [Quickfix-developers] CharConvertor::convert( char value ) bug

[Alexey Z. <ale...@in...>]

Ok.
Thank you.

I just wanted to hear feedbacks from the developers, because you know, a 
bug is a very subjective thing.
Usually it's one's misunderstanding, particularly in a such complicate 
project.


Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305



Brian Erst wrote:

>Alexey -
>
>As I learned myself and as Oren reiterated this morning in his 1.10.2
>announcement, the only way to be sure that something gets fixed is to
>enter it into the BugTracker
>(http://www.quickfixengine.org/bugtracker/). The mailing list is
>getting too busy to use to track these issues.
>
>I took the liberty of entering the CharConverter bug into the Bug
>Tracker (bug #84). The other issues you listed in your linked email
>should probably be checked against 1.10.2 and, if they still exist,
>entered as bugs/feature requests in the Bug Tracker.
>
>- Brian Erst
>Thynk Software, Inc.
>
>--- Alexey Zubko <ale...@in...> wrote:
>
>  
>
>>Brian,
>>
>>I know what the problem is.
>>
>>See my posting:
>>  some changes in C++ version 
>>
>>    
>>
><http://sourceforge.net/mailarchive/forum.php?thread_id=7465814&forum_id=103>
>  
>
>>	Alexey Zubko <alexey@in...> 	2 	2005-06-09 06:06
>>
>>
>>Is there a reason not to put this patch to the version?
>>
>>Regards,
>>		Alexey Zubko
>>
>>Infinium Capital Corporation
>>(416) 360-7000 ext. 305
>>
>>
>>
>>Brian Erst wrote:
>>
>>    
>>
>>>Quick patch that would fix this problem (QF 1.9.4):
>>>
>>>FieldConverters.h:
>>>
>>>249 struct CharConvertor
>>>250 {
>>>251    static std::string convert( char value )
>>>252    {
>>>++        if (value)
>>>253         return std::string( 1, value );
>>>++        else
>>>++          return std::string("");
>>>254    }
>>>
>>>The problem is that the std::string template either has a "feature"
>>>      
>>>
>>or
>>    
>>
>>>a "bug" that doesn't check if the results of a char-based
>>>initialization will cause a weird disconnect between the
>>>      
>>>
>>encapsulated
>>    
>>
>>>C-string (c_str) and the length/size member. The size or length
>>>reported from such an initialization will be "1", even though the
>>>size/length of c_str is "0".
>>>
>>>Changing the initialization to use an empty string when the char
>>>      
>>>
>>value
>>    
>>
>>>is null should fix this problem.
>>>
>>>- Brian Erst
>>>Thynk Software, Inc.
>>>
>>>
>>>
>>>
>>>--- Alexey Zubko <ale...@in...> wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>QuickFIX Documentation:
>>>>http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>>QuickFIX FAQ:
>>>>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>>>
>>>>Guys,
>>>>
>>>>I don't want to annoy you, but I think the following bug must be
>>>>fixed.
>>>>I reported about it early and I thought it would be a part of this
>>>>release.
>>>>
>>>>I think quickfix must be more stable for this cases. At least throw
>>>>        
>>>>
>>>>something like InvalidFieldValue...
>>>>
>>>>Here is the example:
>>>>
>>>>   char                                
>>>>its_just_a_bug_or_wrong_input = 
>>>>'\0';
>>>>// oops!
>>>>   FIX::OrdStatus                OrdStatus =
>>>>its_just_a_bug_or_wrong_input;
>>>>
>>>>   FIX::Message                  message;
>>>>   message.setField(OrdStatus);
>>>>   message.setField(FIX::TransactTime());
>>>>
>>>>// now we send the message:
>>>>   std::string        str;
>>>>   message.toString(str);    // result: "9=26|39="
>>>>
>>>>
>>>>
>>>>-- 
>>>>
>>>>Regards,
>>>>		Alexey Zubko
>>>>
>>>>Infinium Capital Corporation
>>>>(416) 360-7000 ext. 305
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>SF.Net email is sponsored by: Discover Easy Linux Migration
>>>>Strategies
>>>>        
>>>>
>>>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>      
>>>
>>>>informative Webcasts and more! Get everything you need to get up to
>>>>speed, fast.
>>>>        
>>>>
>>http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>    
>>
>>>>_______________________________________________
>>>>Quickfix-developers mailing list
>>>>Qui...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>
>
>  
>

Re: [Quickfix-developers] CharConvertor::convert( char value ) bug

[Brian E. <azz...@ya...>]

Alexey -

As I learned myself and as Oren reiterated this morning in his 1.10.2
announcement, the only way to be sure that something gets fixed is to
enter it into the BugTracker
(http://www.quickfixengine.org/bugtracker/). The mailing list is
getting too busy to use to track these issues.

I took the liberty of entering the CharConverter bug into the Bug
Tracker (bug #84). The other issues you listed in your linked email
should probably be checked against 1.10.2 and, if they still exist,
entered as bugs/feature requests in the Bug Tracker.

- Brian Erst
Thynk Software, Inc.

--- Alexey Zubko <ale...@in...> wrote:

> Brian,
> 
> I know what the problem is.
> 
> See my posting:
>   some changes in C++ version 
>
<http://sourceforge.net/mailarchive/forum.php?thread_id=7465814&forum_id=103>
> 
> 	Alexey Zubko <alexey@in...> 	2 	2005-06-09 06:06
> 
> 
> Is there a reason not to put this patch to the version?
> 
> Regards,
> 		Alexey Zubko
> 
> Infinium Capital Corporation
> (416) 360-7000 ext. 305
> 
> 
> 
> Brian Erst wrote:
> 
> >Quick patch that would fix this problem (QF 1.9.4):
> >
> >FieldConverters.h:
> >
> >249 struct CharConvertor
> >250 {
> >251    static std::string convert( char value )
> >252    {
> >++        if (value)
> >253         return std::string( 1, value );
> >++        else
> >++          return std::string("");
> >254    }
> >
> >The problem is that the std::string template either has a "feature"
> or
> >a "bug" that doesn't check if the results of a char-based
> >initialization will cause a weird disconnect between the
> encapsulated
> >C-string (c_str) and the length/size member. The size or length
> >reported from such an initialization will be "1", even though the
> >size/length of c_str is "0".
> >
> >Changing the initialization to use an empty string when the char
> value
> >is null should fix this problem.
> >
> >- Brian Erst
> >Thynk Software, Inc.
> >
> >
> >
> >
> >--- Alexey Zubko <ale...@in...> wrote:
> >
> >  
> >
> >>QuickFIX Documentation:
> >>http://www.quickfixengine.org/quickfix/doc/html/index.html
> >>QuickFIX FAQ:
> >>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> >>QuickFIX Support: http://www.quickfixengine.org/services.html
> >>
> >>Guys,
> >>
> >>I don't want to annoy you, but I think the following bug must be
> >>fixed.
> >>I reported about it early and I thought it would be a part of this
> >>release.
> >>
> >>I think quickfix must be more stable for this cases. At least throw
> 
> >>something like InvalidFieldValue...
> >>
> >>Here is the example:
> >>
> >>    char                                
> >>its_just_a_bug_or_wrong_input = 
> >>'\0';
> >>// oops!
> >>    FIX::OrdStatus                OrdStatus =
> >>its_just_a_bug_or_wrong_input;
> >>
> >>    FIX::Message                  message;
> >>    message.setField(OrdStatus);
> >>    message.setField(FIX::TransactTime());
> >>
> >>// now we send the message:
> >>    std::string        str;
> >>    message.toString(str);    // result: "9=26|39="
> >>
> >>
> >>
> >>-- 
> >>
> >>Regards,
> >>		Alexey Zubko
> >>
> >>Infinium Capital Corporation
> >>(416) 360-7000 ext. 305
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>SF.Net email is sponsored by: Discover Easy Linux Migration
> >>Strategies
> >>from IBM. Find simple to follow Roadmaps, straightforward articles,
> >>informative Webcasts and more! Get everything you need to get up to
> >>speed, fast.
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> >>_______________________________________________
> >>Quickfix-developers mailing list
> >>Qui...@li...
> >>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >>
> >>    
> >>
> >
> >
> >  
> >
> 

Re: [Quickfix-developers] CharConvertor::convert( char value ) bug

[Alexey Z. <ale...@in...>]

Brian,

I know what the problem is.

See my posting:
  some changes in C++ version 
<http://sourceforge.net/mailarchive/forum.php?thread_id=7465814&forum_id=103> 
	Alexey Zubko <alexey@in...> 	2 	2005-06-09 06:06


Is there a reason not to put this patch to the version?

Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305



Brian Erst wrote:

>Quick patch that would fix this problem (QF 1.9.4):
>
>FieldConverters.h:
>
>249 struct CharConvertor
>250 {
>251    static std::string convert( char value )
>252    {
>++        if (value)
>253         return std::string( 1, value );
>++        else
>++          return std::string("");
>254    }
>
>The problem is that the std::string template either has a "feature" or
>a "bug" that doesn't check if the results of a char-based
>initialization will cause a weird disconnect between the encapsulated
>C-string (c_str) and the length/size member. The size or length
>reported from such an initialization will be "1", even though the
>size/length of c_str is "0".
>
>Changing the initialization to use an empty string when the char value
>is null should fix this problem.
>
>- Brian Erst
>Thynk Software, Inc.
>
>
>
>
>--- Alexey Zubko <ale...@in...> wrote:
>
>  
>
>>QuickFIX Documentation:
>>http://www.quickfixengine.org/quickfix/doc/html/index.html
>>QuickFIX FAQ:
>>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>Guys,
>>
>>I don't want to annoy you, but I think the following bug must be
>>fixed.
>>I reported about it early and I thought it would be a part of this
>>release.
>>
>>I think quickfix must be more stable for this cases. At least throw 
>>something like InvalidFieldValue...
>>
>>Here is the example:
>>
>>    char                                
>>its_just_a_bug_or_wrong_input = 
>>'\0';
>>// oops!
>>    FIX::OrdStatus                OrdStatus =
>>its_just_a_bug_or_wrong_input;
>>
>>    FIX::Message                  message;
>>    message.setField(OrdStatus);
>>    message.setField(FIX::TransactTime());
>>
>>// now we send the message:
>>    std::string        str;
>>    message.toString(str);    // result: "9=26|39="
>>
>>
>>
>>-- 
>>
>>Regards,
>>		Alexey Zubko
>>
>>Infinium Capital Corporation
>>(416) 360-7000 ext. 305
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration
>>Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>    
>>
>
>
>  
>

Re: [Quickfix-developers] CharConvertor::convert( char value ) bug

[Brian E. <azz...@ya...>]

Quick patch that would fix this problem (QF 1.9.4):

FieldConverters.h:

249 struct CharConvertor
250 {
251    static std::string convert( char value )
252    {
++        if (value)
253         return std::string( 1, value );
++        else
++          return std::string("");
254    }

The problem is that the std::string template either has a "feature" or
a "bug" that doesn't check if the results of a char-based
initialization will cause a weird disconnect between the encapsulated
C-string (c_str) and the length/size member. The size or length
reported from such an initialization will be "1", even though the
size/length of c_str is "0".

Changing the initialization to use an empty string when the char value
is null should fix this problem.

- Brian Erst
Thynk Software, Inc.




--- Alexey Zubko <ale...@in...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Guys,
> 
> I don't want to annoy you, but I think the following bug must be
> fixed.
> I reported about it early and I thought it would be a part of this
> release.
> 
> I think quickfix must be more stable for this cases. At least throw 
> something like InvalidFieldValue...
> 
> Here is the example:
> 
>     char                                
> its_just_a_bug_or_wrong_input = 
> '\0';
> // oops!
>     FIX::OrdStatus                OrdStatus =
> its_just_a_bug_or_wrong_input;
> 
>     FIX::Message                  message;
>     message.setField(OrdStatus);
>     message.setField(FIX::TransactTime());
> 
> // now we send the message:
>     std::string        str;
>     message.toString(str);    // result: "9=26|39="
> 
> 
> 
> -- 
> 
> Regards,
> 		Alexey Zubko
> 
> Infinium Capital Corporation
> (416) 360-7000 ext. 305
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

[Quickfix-developers] CharConvertor::convert( char value ) bug

[Alexey Z. <ale...@in...>]

Guys,

I don't want to annoy you, but I think the following bug must be fixed.
I reported about it early and I thought it would be a part of this release.

I think quickfix must be more stable for this cases. At least throw 
something like InvalidFieldValue...

Here is the example:

    char                                 its_just_a_bug_or_wrong_input = 
'\0';
// oops!
    FIX::OrdStatus                OrdStatus = its_just_a_bug_or_wrong_input;

    FIX::Message                  message;
    message.setField(OrdStatus);
    message.setField(FIX::TransactTime());

// now we send the message:
    std::string        str;
    message.toString(str);    // result: "9=26|39="



-- 

Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305

RE: [Quickfix-developers] Session qualifier?

[Steve B. <st...@te...>]

> Oren wrote:
> I suppose because that would cause the messages sent with a TargetSubID, a
> field which may not be supported by the counterparty (this was my
> understanding of the situation).
> 
> I guess I'm not the most knowledgable person regarding this scenario as
> I've never encountered the need for it myself.  I'm open to other
> solutions, but we need to keep in mind that it seems it is pretty 
> commonly used functionality.  I'm ok breaking backwards compatibility 
> if there is a more elegant solution that fits better within the 
> protocol.

It seems to be possible to add the support for optional subIDs and
locationIDs without removing the existing qualifier support. For 
third-party routing, a message would be rejected if the destination 
session is ambiguous due to duplicate TargetComp/Sub/LocationIDs,
even if the qualifiers are different.

Steve

> Again if anyone has comments on this, particularly people who are using
> this functionality, speak up as this will affect you in the future.
> 
> --oren

> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, July 05, 2005 10:58 AM
> To: Steve Bate
> Subject: Re: [Quickfix-developers] Session qualifier?
> 
> I suppose because that would cause the messages sent with a TargetSubID, a
> field which may not be supported by the counterparty (this was my
> understanding of the situation).
> 
> I guess I'm not the most knowledgable person regarding this scenario as
> I've
> never encountered the need for it myself.  I'm open to other solutions,
> but
> we need to keep in mind that it seems it is pretty commonly used
> functionality.  I'm ok breaking backwards compatibility if there is a more
> elegant solution that fits better within the protocol.
> 
> Again if anyone has comments on this, particularly people who are using
> this
> functionality, speak up as this will affect you in the future.
> 
> --oren
> 
> > Why couldn't that scenario have been handled with the following type of
> > config?
> >
> > [SESSION]
> > SenderCompID=SENDER
> > TargetCompID=TARGET
> > TargetSubID=MARKETDATA
> >
> >
> > [SESSION]
> > SenderCompID=SENDER
> > TargetCompID=TARGET
> > TargetSubID=ORDER
> >
> > Where TargetSubID is used instead of UserID (as in the original
> > message) or session qualifier?
> >
> > Steve
> >
> >

Re: [Quickfix-developers] Re: empty tag

[Alvin W. <AW...@FF...>]

Oren, 

I use the same code base to deal with multiple counterpaties. We want to 
demoralize some fields and save them in our tables for future use. That 
means I only need to retrieve the values and save to DB. So sometimes I do 
not really care if it is Null or not for most of tags

Thanks
Alvin






"Oren Miller" <or...@qu...>
07/05/2005 11:45 AM

 
        To:     <qui...@li...>, 
<qui...@li...>, "Alvin Wang" 
<AW...@FF...>
        cc: 
        bcc: 
        Subject:        Re: [Quickfix-developers] Re: empty tag


The configuration setting ValidateFieldsHaveValues already exists.
 
Returning null is not really an option in the C++ api.  I'm not really 
sure if always having to check for null before using a field really saves 
any trouble anyway.  The engine is designed to catch the exception and 
send an appropriate reject message if not present.  Maybe I'm not 
understanding your particular case, but I'm not really sure why you need 
to trap that exception in the general case.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller ; qui...@li... ; qui...@li... 
Sent: Tuesday, July 05, 2005 10:29 PM
Subject: Re: [Quickfix-developers] Re: empty tag


Oren, 

if we can discuss this issue in a more broader scope, can QF have a 
configuration to (dis)allow to handle "empty-tag" message received from 
counterparty? 

Also, can the message.getFiled() method return null if a tag does not 
exist (or is empty)? rather than through a exception. 
I have found catching this kind of exception is troublesome and I have to 
wrap it in my own methods for each different data types. 

Thanks 

Alvin 





Alvin Wang 
07/05/2005 11:16 PM 

        To:        "Oren Miller" <or...@qu...> 
        cc:        qui...@li..., qui...@li... 
        Subject:        Re: [Quickfix-developers] Re: empty tagLink


IMHO, can QF have a configuration for this behavior? Exception(strict) vs 
Ignore(forgiving)... 

Thanks 





"Oren Miller" <or...@qu...> 
Sent by: qui...@li... 
07/05/2005 10:16 AM 
        
        To:        "Alvin Wang" <AW...@FF...> 
        cc:        <qui...@li...>, 
<qui...@li...> 
        bcc:         
        Subject:        Re: [Quickfix-developers] Re: empty tag



My concern is how to handle the situation where the field already exists. 
If field 58 is set in the message, and I set it again with a field that 
has an empty tag, what does this mean?  Does it mean that I ignore the new 
field and retain the old value?  Or do I remove the old field from the 
message completely.  In which case setting a field with an empty tag is 
the same behavior as calling removeField.  Both of these behaviors feel a 
little surprising to me.  I'd be interested in hearing other opinions on 
this. 
  
--oren 
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: qui...@li... ; qui...@li... 
Sent: Tuesday, July 05, 2005 9:40 PM 
Subject: [Quickfix-developers] Re: empty tag 


Oren, I can understand where you are coming from. It makes total sense if 
QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers 
and the production may become disruptive. 

Thanks 
Alvin 




"Oren Miller" <or...@qu...> 
07/05/2005 10:00 AM 
        
       To:        <qui...@li...>, <qui...@li...>, "Alvin Wang" <AW...@FF...> 
       cc:         
       bcc:         
       Subject:        Re: empty tag




We could, although more likely I would throw a NoTagValue exception.  I 
don't much like the idea of having QF silently ignoring a field that the 
developer would be expecting to go out in the message (much like I don't 
like the current behavior).  I can imagine the head scratching that would 
go on if they added a field and then found it mysteriously absent in the 
logs. 
 
In either case if you have a field that might contain a blank value, I 
would suggest checking it before adding it to a message. 
 
--oren 
----- Original Message ----- 
From: Alvin Wang 
To: qui...@li... ; qui...@li... 
Cc: Oren Miller 
Sent: Tuesday, July 05, 2005 9:10 PM 
Subject: empty tag 


HI 

If I set a tag as below: 
message.set(new Text(text)); 
and if the variable "text" is null. QF will include an empty tag 58. As a 
result, some FIX engine (such as QF itself) on the other end will reject 
the message.  Can QF skip including empty tag? 

Thanks 
Alvin ********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

Re: [Quickfix-developers] SessionQualifier as a field in SessionID class in .NET

[Oren M. <or...@qu...>]

SessionQualifier as a field in SessionID class in .NETYes, I'll apply =
this patch.
  ----- Original Message -----=20
  From: Fanshteyn, Timur=20
  To: qui...@li...=20
  Sent: Tuesday, July 05, 2005 10:15 AM
  Subject: [Quickfix-developers] SessionQualifier as a field in =
SessionID class in .NET


  Can the patch be implemented to provide access to the SessionQualifier =
in the SessionID class in the .NET library? Or is there any other way to =
access SessionQualifier from .NET code?

  102,107d101=20
  <   String* getSessionQualifier()=20
  <   { QF_STACK_TRY=20
  <     return m_pUnmanaged->getSessionQualifier().c_str();=20
  <     QF_STACK_CATCH=20
  <   }=20
  <=20

  <<SessionID.h.patch>>=20
  Timur Fanshteyn=20
  Principal - Client Facing Applications / Web Development Team=20
  Prime Brokerage Technology=20
  Banc of America Securities, Prime Brokerage Services=20
  212-583-8624=20

Re: [Quickfix-developers] Re: empty tag

[Oren M. <or...@qu...>]

The configuration setting ValidateFieldsHaveValues already exists.

Returning null is not really an option in the C++ api.  I'm not really =
sure if always having to check for null before using a field really =
saves any trouble anyway.  The engine is designed to catch the exception =
and send an appropriate reject message if not present.  Maybe I'm not =
understanding your particular case, but I'm not really sure why you need =
to trap that exception in the general case.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller ; qui...@li... ; =
qui...@li...=20
  Sent: Tuesday, July 05, 2005 10:29 PM
  Subject: Re: [Quickfix-developers] Re: empty tag



  Oren,=20

  if we can discuss this issue in a more broader scope, can QF have a =
configuration to (dis)allow to handle "empty-tag" message received from =
counterparty?=20

  Also, can the message.getFiled() method return null if a tag does not =
exist (or is empty)? rather than through a exception.=20
  I have found catching this kind of exception is troublesome and I have =
to wrap it in my own methods for each different data types.=20

  Thanks=20

  Alvin=20




       Alvin Wang=20
        07/05/2005 11:16 PM=20

      =20
                To:        "Oren Miller" <or...@qu...>=20
                cc:        qui...@li..., =
qui...@li...=20
                Subject:        Re: [Quickfix-developers] Re: empty =
tagLink=20


  IMHO, can QF have a configuration for this behavior? Exception(strict) =
vs Ignore(forgiving)...=20

  Thanks=20




       "Oren Miller" <or...@qu...>=20
        Sent by: qui...@li...=20
        07/05/2005 10:16 AM=20

              =20
                To:        "Alvin Wang" <AW...@FF...>=20
                cc:        <qui...@li...>, =
<qui...@li...>=20
                bcc:        =20
                Subject:        Re: [Quickfix-developers] Re: empty tag=20



  My concern is how to handle the situation where the field already =
exists.  If field 58 is set in the message, and I set it again with a =
field that has an empty tag, what does this mean?  Does it mean that I =
ignore the new field and retain the old value?  Or do I remove the old =
field from the message completely.  In which case setting a field with =
an empty tag is the same behavior as calling removeField.  Both of these =
behaviors feel a little surprising to me.  I'd be interested in hearing =
other opinions on this.=20
   =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: qui...@li... ; =
qui...@li...=20
  Sent: Tuesday, July 05, 2005 9:40 PM=20
  Subject: [Quickfix-developers] Re: empty tag=20


  Oren, I can understand where you are coming from. It makes total sense =
if QF throws NoTagValue exception in this case. However, I just feel it =
will add workload to the developers and the production may become =
disruptive.=20

  Thanks=20
  Alvin=20



       "Oren Miller" <or...@qu...>=20
        07/05/2005 10:00 AM=20
              =20
               To:        <qui...@li...>, =
<qui...@li...>, "Alvin Wang" =
<AW...@FF...>=20
               cc:        =20
               bcc:        =20
               Subject:        Re: empty tag=20




  We could, although more likely I would throw a NoTagValue exception.  =
I don't much like the idea of having QF silently ignoring a field that =
the developer would be expecting to go out in the message (much like I =
don't like the current behavior).  I can imagine the head scratching =
that would go on if they added a field and then found it mysteriously =
absent in the logs.=20
  =20
  In either case if you have a field that might contain a blank value, I =
would suggest checking it before adding it to a message.=20
  =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: qui...@li... ; =
qui...@li...=20
  Cc: Oren Miller=20
  Sent: Tuesday, July 05, 2005 9:10 PM=20
  Subject: empty tag=20


  HI=20

  If I set a tag as below:=20
  message.set(new Text(text));=20
  and if the variable "text" is null. QF will include an empty tag 58. =
As a result, some FIX engine (such as QF itself) on the other end will =
reject the message.  Can QF skip including empty tag?=20

  Thanks=20
  Alvin =
********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
**********************************************************************=20

RE: [Quickfix-developers] Re: empty tag

[<Ani...@rb...>]

My two cents.
From business point of view, I believe an empty (standard) tag has no meani=
ng, so I believe, the current behavior of allowing an empty tag is merely a=
  technical fix to avoid the contentious issues you mention below  viz.
  i) Missing an expected tag
 ii) Removing an existing valid value tag
iii) Containing an incorrect (previous) value
=20
Possible Resolutions:
A) Configuration of allowing/disallowing in general carries the same surpri=
se elements
B) Configuring for a specific tag may be more desirable as it is a publishe=
d and managed resolution
C) Configuring for a specific tag for a New/Cancel/Replace) may be even mor=
e desirable
D) Configure to simply ignore empty values
E) Configure to ignore empty values with warning
=20
In my view default behavior as it exists now and with C and E  or B & E is =
desirable.
=20
Thanks,
=20
Anil

-----Original Message-----
From: qui...@li... [mailto:quickfix-deve=
lop...@li...]On Behalf Of Oren Miller
Sent: Tuesday, July 05, 2005 10:17 AM
To: Alvin Wang
Cc: qui...@li...; quickfix-developers-admin@li=
sts.sourceforge.net
Subject: Re: [Quickfix-developers] Re: empty tag


My concern is how to handle the situation where the field already exists.  =
If field 58 is set in the message, and I set it again with a field that has=
 an empty tag, what does this mean?  Does it mean that I ignore the new fie=
ld and retain the old value?  Or do I remove the old field from the message=
 completely.  In which case setting a field with an empty tag is the same b=
ehavior as calling removeField.  Both of these behaviors feel a little surp=
rising to me.  I'd be interested in hearing other opinions on this.
=20
--oren

----- Original Message -----=20
From: Alvin Wang <mailto:AW...@FF...> =20
To: Oren Miller <mailto:or...@qu...> =20
Cc: qui...@li... ; quickfix-developers-admin@l=
ists.sourceforge.net=20
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag



Oren, I can understand where you are coming from. It makes total sense if Q=
F throws NoTagValue exception in this case. However, I just feel it will ad=
d workload to the developers and the production may become disruptive.=20

Thanks=20
Alvin=20





	"Oren Miller" < or...@qu...>=20


07/05/2005 10:00 AM=20


       =20
        To:        < qui...@li...>, < quickfix=
-dev...@li...>, "Alvin Wang" < AW...@FF...>=20
        cc:        =20
        bcc:        =20
        Subject:        Re: empty tag=09



We could, although more likely I would throw a NoTagValue exception.  I don=
't much like the idea of having QF silently ignoring a field that the devel=
oper would be expecting to go out in the message (much like I don't like th=
e current behavior).  I can imagine the head scratching that would go on if=
 they added a field and then found it mysteriously absent in the logs.=20
 =20
In either case if you have a field that might contain a blank value, I woul=
d suggest checking it before adding it to a message.=20
 =20
--oren=20
----- Original Message -----=20
From:  <mailto:AW...@FF...> Alvin Wang=20
To:  <mailto:qui...@li...> quickfix-developers=
@lists.sourceforge.net ;  <mailto:qui...@li...=
ge.net> qui...@li...=20
Cc:  <mailto:or...@qu...> Oren Miller=20
Sent: Tuesday, July 05, 2005 9:10 PM=20
Subject: empty tag=20


HI=20

If I set a tag as below:=20
message.set(new Text(text));=20
and if the variable "text" is null. QF will include an empty tag 58. As a r=
esult, some FIX engine (such as QF itself) on the other end will reject the=
 message.  Can QF skip including empty tag?=20

Thanks=20
Alvin *********************************************************************=
* This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. Disclo=
sure to anyone other than the intended recipient is prohibited. If you are =
not the intended recipient, please do not disseminate, distribute or copy t=
his communication, by e-mail or otherwise. Instead, please notify us immedi=
ately by return e-mail (including the original message with your reply) and=
 then delete and discard all copies of the message. We have taken precautio=
ns to minimize the risk of transmitting software viruses but nevertheless a=
dvise you to carry out your own virus checks on any attachment to this mess=
age. We accept no liability for any loss or damage caused by software virus=
es. **********************************************************************=
=20




<font face=3D"Times New Roman" size=3D"3">
<p>------------------------------------------------------------------------=
------</p>
<p> This E-Mail (including any attachments) may contain privileged or confi=
dential information.  It is intended only for the addressee(s) indicated ab=
ove. The sender does not waive any of its rights, privileges or other prote=
ctions respecting this information.  Any distribution, copying or other use=
 of this E-Mail or the information it contains, by other than an intended r=
ecipient, is not sanctioned and is prohibited. If you received this E-Mail =
in error, please delete it and advise the sender (by return E-Mail or other=
wise) immediately.</p>
<p> This E-Mail (including any attachments) has been scanned for viruses.  =
It is believed to be free of any virus or other defect that might affect an=
y computer system into which it is received and opened.  However, it is the=
 responsibility of the recipient to ensure that it is virus free.  The send=
er accepts no responsibility for any loss or damage arising in any way from=
 its use.</p>
<p> E-Mail received by or sent from RBC Capital Markets is subject to revie=
w by Supervisory personnel.  Such communications are retained and may be pr=
oduced to regulatory authorities or others with legal rights to the informa=
tion.</p>
<p>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</p>
</font>

RE: [Quickfix-developers] Re: empty tag

[Steve B. <st...@te...>]

I vote this approach as the default behavior, possibly with a
configuration option for the other behaviors.

> -----Original Message-----
> From: qui...@li... [mailto:quickfix-
> dev...@li...] On Behalf Of Brian Erst
> Sent: Tuesday, July 05, 2005 9:46 AM
> To: Oren Miller; Alvin Wang
> Cc: qui...@li...; quickfix-developers-
> ad...@li...
> Subject: Re: [Quickfix-developers] Re: empty tag
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Oren -
> 
> I'd definitely go with the NoTagValue exception method rather than
> attempting to guess what the developer "really" wants.
> 
> You have the removeField method for the case of needing to strip a
> field out of a message, so providing a backdoor way of doing that via
> adding a "blank" value is redundant. It also isn't obvious that "blank"
> = "delete".
> 
> Considering how many FIX engines choke on a missing tag value, I think
> it's a good idea to default to not allowing it. I'd rather add a new
> method (addBlankField or some such) or optional parameter (e.g.,
> message.set(value, allowBlanks)) on the off chance that some weird FIX
> implementation out there requires the existence of a tag even if there
> is no value for it than allow what is normally considered "bad" FIX to
> go out by default.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- Oren Miller <or...@qu...> wrote:
> 
> > My concern is how to handle the situation where the field already
> > exists.  If field 58 is set in the message, and I set it again with a
> > field that has an empty tag, what does this mean?  Does it mean that
> > I ignore the new field and retain the old value?  Or do I remove the
> > old field from the message completely.  In which case setting a field
> > with an empty tag is the same behavior as calling removeField.  Both
> > of these behaviors feel a little surprising to me.  I'd be interested
> > in hearing other opinions on this.
> >
> > --oren
> >   ----- Original Message -----
> >   From: Alvin Wang
> >   To: Oren Miller
> >   Cc: qui...@li... ;
> > qui...@li...
> >   Sent: Tuesday, July 05, 2005 9:40 PM
> >   Subject: [Quickfix-developers] Re: empty tag
> >
> >
> >
> >   Oren, I can understand where you are coming from. It makes total
> > sense if QF throws NoTagValue exception in this case. However, I just
> > feel it will add workload to the developers and the production may
> > become disruptive.
> >
> >   Thanks
> >   Alvin
> >
> >
> >
> >
> >        "Oren Miller" <or...@qu...>
> >         07/05/2005 10:00 AM
> >
> >
> >                 To:
> > <qui...@li...>,
> > <qui...@li...>, "Alvin Wang"
> > <AW...@FF...>
> >                 cc:
> >                 bcc:
> >                 Subject:        Re: empty tag
> >
> >
> >
> >   We could, although more likely I would throw a NoTagValue
> > exception.  I don't much like the idea of having QF silently ignoring
> > a field that the developer would be expecting to go out in the
> > message (much like I don't like the current behavior).  I can imagine
> > the head scratching that would go on if they added a field and then
> > found it mysteriously absent in the logs.
> >
> >   In either case if you have a field that might contain a blank
> > value, I would suggest checking it before adding it to a message.
> >
> >   --oren
> >   ----- Original Message -----
> >   From: Alvin Wang
> >   To: qui...@li... ;
> > qui...@li...
> >   Cc: Oren Miller
> >   Sent: Tuesday, July 05, 2005 9:10 PM
> >   Subject: empty tag
> >
> >
> >   HI
> >
> >   If I set a tag as below:
> >   message.set(new Text(text));
> >   and if the variable "text" is null. QF will include an empty tag
> > 58. As a result, some FIX engine (such as QF itself) on the other end
> > will reject the message.  Can QF skip including empty tag?
> >
> >   Thanks
> >   Alvin
> >
> **********************************************************************
> > This e-mail message is intended solely for the use of the addressee.
> > The message may contain information that is privileged and
> > confidential. Disclosure to anyone other than the intended recipient
> > is prohibited. If you are not the intended recipient, please do not
> > disseminate, distribute or copy this communication, by e-mail or
> > otherwise. Instead, please notify us immediately by return e-mail
> > (including the original message with your reply) and then delete and
> > discard all copies of the message. We have taken precautions to
> > minimize the risk of transmitting software viruses but nevertheless
> > advise you to carry out your own virus checks on any attachment to
> > this message. We accept no liability for any loss or damage caused by
> > software viruses.
> >
> **********************************************************************
> >
> >
> >
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

RE: [Quickfix-developers] Session qualifier?

[Steve B. <st...@te...>]

> Those fields can change on a per message basis.  We cannot rely on 
> those fields remaining constant inside a session.  Also the sessions 
> themselves may not be expected the presence of such fields and may even
reject them.

Hi Oren,

Although those fields aren't required to be static, if they are used as part
of the session ID (as agreed by the counterparties) they can be assumed to
be static in that context and the session would be configured to expect them
(in fact, require them). 

All the commercial FIX engines I've used have at least supported subID as an
optional part of the session ID, if not also the location field. Also, so
far I haven't connected with a counterparty that used a dynamic SenderSubID.
However, if they did, it obviously wouldn't be considered part of the
session ID.

The issue with the session qualifier is that there's no standard way for a
counterparter to send it to the FIX engine. This seems to make it difficult
to do third-party routing since the DeliverToCompID might refer to any
number of sessions. Some options are to reject ambiguous routing requests or
allow the configuration of session subIds for routing although they aren't
used as part of the session ID.

> This came about because some feeds are running sessions with identical 
> versions and comp ids while using the IP addresses or port number to 
> disambiguate the session.  A very bad idea, but one that needed a work 
> around.  Otherwise it would have required running multiple processes. 
> You can read more about the problem here:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=9120281
> http://sourceforge.net/mailarchive/forum.php?thread_id=5249494&forum_i
> d=10
> 3

Interesting messages. Thanks for the pointers.

Why couldn't that scenario have been handled with the following type of
config?

[SESSION]
 SenderCompID=SENDER
 TargetCompID=TARGET
 TargetSubID=MARKETDATA 
 
 
 [SESSION]
 SenderCompID=SENDER
 TargetCompID=TARGET
 TargetSubID=ORDER

Where TargetSubID is used instead of UserID (as in the original
message) or session qualifier?

Steve

Re: [Quickfix-developers] Re: empty tag

[Alvin W. <AW...@FF...>]

Oren, 

if we can discuss this issue in a more broader scope, can QF have a 
configuration to (dis)allow to handle "empty-tag" message received from 
counterparty?

Also, can the message.getFiled() method return null if a tag does not 
exist (or is empty)? rather than through a exception. 
I have found catching this kind of exception is troublesome and I have to 
wrap it in my own methods for each different data types.

Thanks

Alvin






Alvin Wang
07/05/2005 11:16 PM


        To:     "Oren Miller" <or...@qu...>
        cc:     qui...@li..., 
qui...@li...
        Subject:        Re: [Quickfix-developers] Re: empty tag

IMHO, can QF have a configuration for this behavior? Exception(strict) vs 
Ignore(forgiving)...

Thanks






"Oren Miller" <or...@qu...>
Sent by: qui...@li...
07/05/2005 10:16 AM

 
        To:     "Alvin Wang" <AW...@FF...>
        cc:     <qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] Re: empty tag


My concern is how to handle the situation where the field already exists. 
If field 58 is set in the message, and I set it again with a field that 
has an empty tag, what does this mean?  Does it mean that I ignore the new 
field and retain the old value?  Or do I remove the old field from the 
message completely.  In which case setting a field with an empty tag is 
the same behavior as calling removeField.  Both of these behaviors feel a 
little surprising to me.  I'd be interested in hearing other opinions on 
this.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: qui...@li... ; qui...@li... 
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if 
QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers 
and the production may become disruptive. 

Thanks 
Alvin 





"Oren Miller" <or...@qu...> 
07/05/2005 10:00 AM 
        
        To:        <qui...@li...>, <qui...@li...>, "Alvin Wang" <AW...@FF...> 
        cc:         
        bcc:         
        Subject:        Re: empty tag



We could, although more likely I would throw a NoTagValue exception.  I 
don't much like the idea of having QF silently ignoring a field that the 
developer would be expecting to go out in the message (much like I don't 
like the current behavior).  I can imagine the head scratching that would 
go on if they added a field and then found it mysteriously absent in the 
logs. 
  
In either case if you have a field that might contain a blank value, I 
would suggest checking it before adding it to a message. 
  
--oren 
----- Original Message ----- 
From: Alvin Wang 
To: qui...@li... ; qui...@li... 
Cc: Oren Miller 
Sent: Tuesday, July 05, 2005 9:10 PM 
Subject: empty tag 


HI 

If I set a tag as below: 
message.set(new Text(text)); 
and if the variable "text" is null. QF will include an empty tag 58. As a 
result, some FIX engine (such as QF itself) on the other end will reject 
the message.  Can QF skip including empty tag? 

Thanks 
Alvin ********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

Re: [Quickfix-developers] Re: empty tag

[Brian E. <azz...@ya...>]

Oren -

I'd definitely go with the NoTagValue exception method rather than
attempting to guess what the developer "really" wants.

You have the removeField method for the case of needing to strip a
field out of a message, so providing a backdoor way of doing that via
adding a "blank" value is redundant. It also isn't obvious that "blank"
= "delete".

Considering how many FIX engines choke on a missing tag value, I think
it's a good idea to default to not allowing it. I'd rather add a new
method (addBlankField or some such) or optional parameter (e.g.,
message.set(value, allowBlanks)) on the off chance that some weird FIX
implementation out there requires the existence of a tag even if there
is no value for it than allow what is normally considered "bad" FIX to
go out by default.

- Brian Erst
Thynk Software, Inc.

--- Oren Miller <or...@qu...> wrote:

> My concern is how to handle the situation where the field already
> exists.  If field 58 is set in the message, and I set it again with a
> field that has an empty tag, what does this mean?  Does it mean that
> I ignore the new field and retain the old value?  Or do I remove the
> old field from the message completely.  In which case setting a field
> with an empty tag is the same behavior as calling removeField.  Both
> of these behaviors feel a little surprising to me.  I'd be interested
> in hearing other opinions on this.
> 
> --oren
>   ----- Original Message ----- 
>   From: Alvin Wang 
>   To: Oren Miller 
>   Cc: qui...@li... ;
> qui...@li... 
>   Sent: Tuesday, July 05, 2005 9:40 PM
>   Subject: [Quickfix-developers] Re: empty tag
> 
> 
> 
>   Oren, I can understand where you are coming from. It makes total
> sense if QF throws NoTagValue exception in this case. However, I just
> feel it will add workload to the developers and the production may
> become disruptive. 
> 
>   Thanks 
>   Alvin 
> 
> 
> 
> 
>        "Oren Miller" <or...@qu...> 
>         07/05/2005 10:00 AM 
> 
>                
>                 To:       
> <qui...@li...>,
> <qui...@li...>, "Alvin Wang"
> <AW...@FF...> 
>                 cc:         
>                 bcc:         
>                 Subject:        Re: empty tag 
> 
> 
> 
>   We could, although more likely I would throw a NoTagValue
> exception.  I don't much like the idea of having QF silently ignoring
> a field that the developer would be expecting to go out in the
> message (much like I don't like the current behavior).  I can imagine
> the head scratching that would go on if they added a field and then
> found it mysteriously absent in the logs. 
>     
>   In either case if you have a field that might contain a blank
> value, I would suggest checking it before adding it to a message. 
>     
>   --oren 
>   ----- Original Message ----- 
>   From: Alvin Wang 
>   To: qui...@li... ;
> qui...@li... 
>   Cc: Oren Miller 
>   Sent: Tuesday, July 05, 2005 9:10 PM 
>   Subject: empty tag 
> 
> 
>   HI 
> 
>   If I set a tag as below: 
>   message.set(new Text(text)); 
>   and if the variable "text" is null. QF will include an empty tag
> 58. As a result, some FIX engine (such as QF itself) on the other end
> will reject the message.  Can QF skip including empty tag? 
> 
>   Thanks 
>   Alvin
>
**********************************************************************
> This e-mail message is intended solely for the use of the addressee.
> The message may contain information that is privileged and
> confidential. Disclosure to anyone other than the intended recipient
> is prohibited. If you are not the intended recipient, please do not
> disseminate, distribute or copy this communication, by e-mail or
> otherwise. Instead, please notify us immediately by return e-mail
> (including the original message with your reply) and then delete and
> discard all copies of the message. We have taken precautions to
> minimize the risk of transmitting software viruses but nevertheless
> advise you to carry out your own virus checks on any attachment to
> this message. We accept no liability for any loss or damage caused by
> software viruses.
>
**********************************************************************
> 
> 
> 

Re: [Quickfix-developers] Re: empty tag

[VP M. IT A. E. T. <ass...@gm...>]

My opinion and what I would find useful:

if (tag already set)
{
  replace old value if a new non empty value is present
 never allow duplicate tags in the msg
}

Instead of numerous QF users to be checking and setting..it is better
to factor this in QF.
the issue of ambiguity may be resolved whenever
QF rejects a tag/value set operation by logging=20
"QFEONP QF Error Op Not Performed...tag without value cannot be added"
"QFEONP QF Error Op Not Performed...tag cannot be added for this msg"
"QFEONP QF Error Op Not Performed...tag value cannot be added in the
given format"
to a special QFE.log file
On 7/5/05, Oren Miller <or...@qu...> wrote:
> My concern is how to handle the situation where the field already exists.=
=20
> If field 58 is set in the message, and I set it again with a field that h=
as
> an empty tag, what does this mean?  Does it mean that I ignore the new fi=
eld
> and retain the old value?  Or do I remove the old field from the message
> completely.  In which case setting a field with an empty tag is the same
> behavior as calling removeField.  Both of these behaviors feel a little
> surprising to me.  I'd be interested in hearing other opinions on this.
> =20
> --oren
> ----- Original Message -----=20
> From: Alvin Wang=20
> To: Oren Miller=20
> Cc: qui...@li... ;
> qui...@li...=20
> Sent: Tuesday, July 05, 2005 9:40 PM
> Subject: [Quickfix-developers] Re: empty tag
>=20
>=20
> Oren, I can understand where you are coming from. It makes total sense if=
 QF
> throws NoTagValue exception in this case. However, I just feel it will ad=
d
> workload to the developers and the production may become disruptive.=20
>=20
> Thanks=20
> Alvin=20
>=20
>=20
>=20
>=20
> "Oren Miller" <or...@qu...>=20
>=20
> 07/05/2005 10:00 AM=20
>        =20
>         To:      =20
> <qui...@li...>,
> <qui...@li...>, "Alvin
> Wang" <AW...@FF...>=20
>         cc:        =20
>         bcc:        =20
>         Subject:        Re: empty tag
>=20
>=20
> We could, although more likely I would throw a NoTagValue exception.  I
> don't much like the idea of having QF silently ignoring a field that the
> developer would be expecting to go out in the message (much like I don't
> like the current behavior).  I can imagine the head scratching that would=
 go
> on if they added a field and then found it mysteriously absent in the log=
s.=20
>  =20
> In either case if you have a field that might contain a blank value, I wo=
uld
> suggest checking it before adding it to a message.=20
>  =20
> --oren=20
> ----- Original Message -----=20
> From: Alvin Wang=20
> To: qui...@li... ;
> qui...@li...=20
> Cc: Oren Miller=20
> Sent: Tuesday, July 05, 2005 9:10 PM=20
> Subject: empty tag=20
>=20
>=20
> HI=20
>=20
> If I set a tag as below:=20
> message.set(new Text(text));=20
> and if the variable "text" is null. QF will include an empty tag 58. As a
> result, some FIX engine (such as QF itself) on the other end will reject =
the
> message.  Can QF skip including empty tag?=20
>=20
> Thanks=20
> Alvin
> **********************************************************************
> This e-mail message is intended solely for the use of the addressee. The
> message may contain information that is privileged and confidential.
> Disclosure to anyone other than the intended recipient is prohibited. If =
you
> are not the intended recipient, please do not disseminate, distribute or
> copy this communication, by e-mail or otherwise. Instead, please notify u=
s
> immediately by return e-mail (including the original message with your
> reply) and then delete and discard all copies of the message. We have tak=
en
> precautions to minimize the risk of transmitting software viruses but
> nevertheless advise you to carry out your own virus checks on any attachm=
ent
> to this message. We accept no liability for any loss or damage caused by
> software viruses.
> **********************************************************************
>=20
>

Re: [Quickfix-developers] Re: empty tag

[Alvin W. <AW...@FF...>]

IMHO, can QF have a configuration for this behavior? Exception(strict) vs 
Ignore(forgiving)...

Thanks






"Oren Miller" <or...@qu...>
Sent by: qui...@li...
07/05/2005 10:16 AM

 
        To:     "Alvin Wang" <AW...@FF...>
        cc:     <qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] Re: empty tag


My concern is how to handle the situation where the field already exists. 
If field 58 is set in the message, and I set it again with a field that 
has an empty tag, what does this mean?  Does it mean that I ignore the new 
field and retain the old value?  Or do I remove the old field from the 
message completely.  In which case setting a field with an empty tag is 
the same behavior as calling removeField.  Both of these behaviors feel a 
little surprising to me.  I'd be interested in hearing other opinions on 
this.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: Oren Miller 
Cc: qui...@li... ; qui...@li... 
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag


Oren, I can understand where you are coming from. It makes total sense if 
QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers 
and the production may become disruptive. 

Thanks 
Alvin 





"Oren Miller" <or...@qu...> 
07/05/2005 10:00 AM 
        
        To:        <qui...@li...>, <qui...@li...>, "Alvin Wang" <AW...@FF...> 
        cc:         
        bcc:         
        Subject:        Re: empty tag



We could, although more likely I would throw a NoTagValue exception.  I 
don't much like the idea of having QF silently ignoring a field that the 
developer would be expecting to go out in the message (much like I don't 
like the current behavior).  I can imagine the head scratching that would 
go on if they added a field and then found it mysteriously absent in the 
logs. 
  
In either case if you have a field that might contain a blank value, I 
would suggest checking it before adding it to a message. 
  
--oren 
----- Original Message ----- 
From: Alvin Wang 
To: qui...@li... ; qui...@li... 
Cc: Oren Miller 
Sent: Tuesday, July 05, 2005 9:10 PM 
Subject: empty tag 


HI 

If I set a tag as below: 
message.set(new Text(text)); 
and if the variable "text" is null. QF will include an empty tag 58. As a 
result, some FIX engine (such as QF itself) on the other end will reject 
the message.  Can QF skip including empty tag? 

Thanks 
Alvin ********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

Re: [Quickfix-developers] Re: empty tag

[Oren M. <or...@qu...>]

My concern is how to handle the situation where the field already =
exists.  If field 58 is set in the message, and I set it again with a =
field that has an empty tag, what does this mean?  Does it mean that I =
ignore the new field and retain the old value?  Or do I remove the old =
field from the message completely.  In which case setting a field with =
an empty tag is the same behavior as calling removeField.  Both of these =
behaviors feel a little surprising to me.  I'd be interested in hearing =
other opinions on this.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: qui...@li... ; =
qui...@li...=20
  Sent: Tuesday, July 05, 2005 9:40 PM
  Subject: [Quickfix-developers] Re: empty tag



  Oren, I can understand where you are coming from. It makes total sense =
if QF throws NoTagValue exception in this case. However, I just feel it =
will add workload to the developers and the production may become =
disruptive.=20

  Thanks=20
  Alvin=20




       "Oren Miller" <or...@qu...>=20
        07/05/2005 10:00 AM=20

              =20
                To:        <qui...@li...>, =
<qui...@li...>, "Alvin Wang" =
<AW...@FF...>=20
                cc:        =20
                bcc:        =20
                Subject:        Re: empty tag=20



  We could, although more likely I would throw a NoTagValue exception.  =
I don't much like the idea of having QF silently ignoring a field that =
the developer would be expecting to go out in the message (much like I =
don't like the current behavior).  I can imagine the head scratching =
that would go on if they added a field and then found it mysteriously =
absent in the logs.=20
   =20
  In either case if you have a field that might contain a blank value, I =
would suggest checking it before adding it to a message.=20
   =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: qui...@li... ; =
qui...@li...=20
  Cc: Oren Miller=20
  Sent: Tuesday, July 05, 2005 9:10 PM=20
  Subject: empty tag=20


  HI=20

  If I set a tag as below:=20
  message.set(new Text(text));=20
  and if the variable "text" is null. QF will include an empty tag 58. =
As a result, some FIX engine (such as QF itself) on the other end will =
reject the message.  Can QF skip including empty tag?=20

  Thanks=20
  Alvin =
********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
**********************************************************************=20

[Quickfix-developers] Re: empty tag

[Alvin W. <AW...@FF...>]

Oren, I can understand where you are coming from. It makes total sense if 
QF throws NoTagValue exception in this case. However, I just feel it will add workload to the developers 
and the production may become disruptive. 

Thanks
Alvin






"Oren Miller" <or...@qu...>
07/05/2005 10:00 AM

 
        To:     <qui...@li...>, 
<qui...@li...>, "Alvin Wang" 
<AW...@FF...>
        cc: 
        bcc: 
        Subject:        Re: empty tag


We could, although more likely I would throw a NoTagValue exception.  I 
don't much like the idea of having QF silently ignoring a field that the 
developer would be expecting to go out in the message (much like I don't 
like the current behavior).  I can imagine the head scratching that would 
go on if they added a field and then found it mysteriously absent in the 
logs.
 
In either case if you have a field that might contain a blank value, I 
would suggest checking it before adding it to a message.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: qui...@li... ; qui...@li... 
Cc: Oren Miller 
Sent: Tuesday, July 05, 2005 9:10 PM
Subject: empty tag


HI 

If I set a tag as below: 
message.set(new Text(text)); 
and if the variable "text" is null. QF will include an empty tag 58. As a 
result, some FIX engine (such as QF itself) on the other end will reject 
the message.  Can QF skip including empty tag? 

Thanks 
Alvin ********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

[Quickfix-developers] Re: empty tag

[Oren M. <or...@qu...>]

We could, although more likely I would throw a NoTagValue exception.  I =
don't much like the idea of having QF silently ignoring a field that the =
developer would be expecting to go out in the message (much like I don't =
like the current behavior).  I can imagine the head scratching that =
would go on if they added a field and then found it mysteriously absent =
in the logs.

In either case if you have a field that might contain a blank value, I =
would suggest checking it before adding it to a message.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: qui...@li... ; =
qui...@li...=20
  Cc: Oren Miller=20
  Sent: Tuesday, July 05, 2005 9:10 PM
  Subject: empty tag



  HI=20

  If I set a tag as below:=20
  message.set(new Text(text));=20
  and if the variable "text" is null. QF will include an empty tag 58. =
As a result, some FIX engine (such as QF itself) on the other end will =
reject the message.  Can QF skip including empty tag?=20

  Thanks=20
  Alvin =
********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
********************************************************************** 

[Quickfix-developers] empty tag

[Alvin W. <AW...@FF...>]

HI 

If I set a tag as below:
message.set(new Text(text));
and if the variable "text" is null. QF will include an empty tag 58. As a 
result, some FIX engine (such as QF itself) on the other end will reject 
the message.  Can QF skip including empty tag?

Thanks
Alvin 
                                                                                                                                                                                                                                                                                                    **********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.  
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

Re: [Quickfix-developers] Session qualifier?

[Oren M. <or...@qu...>]

Those fields can change on a per message basis.  We cannot rely on those 
fields remaining constant inside a session.  Also the sessions themselves 
may not be expected the presence of such fields and may even reject them.

This came about because some feeds are running sessions with identical 
versions and comp ids while using the IP addresses or port number to 
disambiguate the session.  A very bad idea, but one that needed a work 
around.  Otherwise it would have required running multiple processes. You 
can read more about the problem here:

http://sourceforge.net/mailarchive/message.php?msg_id=9120281
http://sourceforge.net/mailarchive/forum.php?thread_id=5249494&forum_id=103

----- Original Message ----- 
From: "Steve Bate" <st...@te...>
To: <qui...@li...>
Sent: Tuesday, July 05, 2005 8:11 AM
Subject: [Quickfix-developers] Session qualifier?


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello,
>
> I am curious about why QF uses session qualifiers as part of
> the session identification rather than using subID and location.
>
> I'm looking into implementing third-party message routing in
> QFJ and this looks like the session qualifier technique might be
> a problem.
>
> Steve
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>