quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Field with embedded null character

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

Thanks.  I've already added a unit test for this case, so hopefully it 
will pass once I apply this.

--oren

On Oct 28, 2004, at 11:02 AM, Caleb Epstein wrote:

> On Thu, 28 Oct 2004 09:05:47 -0400, Caleb Epstein
> <cal...@gm...> wrote:
>
>> That said, it does seem that QuickFIX has a bug in the message
>> serialization code when dealing with fields having embedded \0 bytes:
>
> Ironically, the bug turns out to be in code that I submitted.  In
> Field.h there is this optimization:
>
>     char buf[64];
>
>     if( 13 + m_string.length() < sizeof(buf) )
>     {
>       m_length = sprintf( buf, "%d=%*.*s\001", m_field,
>                           (int)m_string.length(), 
> (int)m_string.length(),
>                           m_string.data() );
>       m_data.assign( buf, m_length );
>     }
>
> At least on Linux, sprintf refuses to write anything after a \0 byte
> to the output buffer, so the field gets padded with spaces on the
> left.  Here's a re-worked version that is not as simple but is still
> faster than the string + string + ... implementation that is used when
> the value is too long to fit in buf:
>
>     char buf[64];
>
>     if( 13 + m_string.length() < sizeof(buf) )
>     {
>       int fidlen = sprintf (buf, "%d=", m_field);
>       m_length = fidlen + m_string.length() + 1;
>       memcpy (buf + fidlen, m_string.data(), m_string.length());
>       buf[m_length - 1] = '\001';
>       m_data.assign (buf, m_length);
>     }
>
> -- 
> Caleb Epstein
> cal...@gm...
>

Re: [Quickfix-developers] Field with embedded null character

[Caleb E. <cal...@gm...>]

On Thu, 28 Oct 2004 09:05:47 -0400, Caleb Epstein
<cal...@gm...> wrote:

> That said, it does seem that QuickFIX has a bug in the message
> serialization code when dealing with fields having embedded \0 bytes:

Ironically, the bug turns out to be in code that I submitted.  In
Field.h there is this optimization:

    char buf[64];

    if( 13 + m_string.length() < sizeof(buf) )
    {
      m_length = sprintf( buf, "%d=%*.*s\001", m_field,
                          (int)m_string.length(), (int)m_string.length(),
                          m_string.data() );
      m_data.assign( buf, m_length );
    }

At least on Linux, sprintf refuses to write anything after a \0 byte
to the output buffer, so the field gets padded with spaces on the
left.  Here's a re-worked version that is not as simple but is still
faster than the string + string + ... implementation that is used when
the value is too long to fit in buf:

    char buf[64];

    if( 13 + m_string.length() < sizeof(buf) )
    {
      int fidlen = sprintf (buf, "%d=", m_field);
      m_length = fidlen + m_string.length() + 1;
      memcpy (buf + fidlen, m_string.data(), m_string.length());
      buf[m_length - 1] = '\001';
      m_data.assign (buf, m_length);
    }

-- 
Caleb Epstein
cal...@gm...

Re: [Quickfix-developers] Fixed spurious System.NullReferenceException in .NET Application.toApp()

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

Yep, we have verified the problem is still there.  The upside is we now 
have a test environment where we can duplicate the problem rather 
easier.  Hopefully we can track it down better now.

--oren

On Oct 28, 2004, at 9:13 AM, John Debay 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
>
> on 10/19/2004 12:03 PM Vladimir Arnost 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
>>
>> Oren,
>>
>> I have fixed a nasty bug in .NET Application class in QuickFIX 1.9.2.
>> From time to time, especially under high system load, sending a FIX
>> message throws an exception like this one:
>>
>> System.NullReferenceException: Object reference not set to an instance
>> of an object.
>>   at FIX.message_order.=(message_order* , message_order* )
>>   at FIX.message_order.__ctor(message_order* , message_order* copy)
>>   at
>> std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,...>
>>
>>> .key_comp(_Tree<...>* , message_order* )
>>>
>>   at FIX.FieldMap.=(FieldMap* , FieldMap* )
>>   at FIX.Message.=(Message* , Message* )
>>   at Application.toApp(Application* , Message* message, SessionID*
>> sessionID)
>>   at FIX.Session.sendToTarget(Message* , SessionID* )
>>   at QuickFix.Session.sendToTarget(Message message, SessionID
>> sessionID)
>>
>>
> Hi,
>
> Is anyone still seeing this issue occur after applying Vladimir's 
> patch? We have applied it to our code, and are still seeing them same 
> exceptions arise. It is causing a major problem for us in production 
> code, and I'm looking for some feedback from other users out there 
> that may be contending with the same thing.
>
> Thanks,
> John
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] beginner's validation question

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

Michael,

QuickFIX does not validate outbound messages.  Since you have total=20
control over those messages, it allows you to send whatever you like. =20=

The counter-party who is better equipped to know what they can handle=20
can do the validation on the received message.  If you really want to=20
validate a message before sending it, you can do so yourself by getting=20=

a hold of the data dictionary for the session you will be sending on. =20=

Something like so:

Session* pSession =3D Session::lookupSession( sessionID );
if( pSession ) {
	try {
		pSession->getDataDictionary().validate( message );
		Session::sendToTarget( message, sessionID );
	} catch( std::exception& e ) {
		// failed validation
	}
}

Otherwise QuickFIX will only validate incoming messages, since these=20
are the ones that you do not have control over and could be potentially=20=

damaging to your application.

--oren

On Oct 27, 2004, at 11:25 AM, Michael Raykh wrote:

> For some reason messages that my app(very simlar to example apps from=20=

> install) is sending are not being validated by quickFix.
>
> I do have UseDataDictionary=A0 and DataDictionary set....
> What am I doing wrong?
>  This email and any files transmitted with it are confidential and=20
> intended solely for the use of the individual or entity to whom they=20=

> are addressed. If you have received this email in error please notify=20=

> the system manager. This message contains confidential information and=20=

> is intended only for the individual named. If you are not the named=20
> addressee you should not disseminate, distribute or copy this e-mail.=20=

> =20=

Re: [Quickfix-developers] Fixed spurious System.NullReferenceException in .NET Application.toApp()

[John D. <joh...@ch...>]

on 10/19/2004 12:03 PM Vladimir Arnost 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
>
>Oren,
>
>I have fixed a nasty bug in .NET Application class in QuickFIX 1.9.2.
>From time to time, especially under high system load, sending a FIX
>message throws an exception like this one:
>
>System.NullReferenceException: Object reference not set to an instance
>of an object.
>   at FIX.message_order.=(message_order* , message_order* )
>   at FIX.message_order.__ctor(message_order* , message_order* copy)
>   at
>std._Tree<std::_Tmap_traits<int,FIX::FieldBase,FIX::message_order,...>
>  
>
>>.key_comp(_Tree<...>* , message_order* )
>>    
>>
>   at FIX.FieldMap.=(FieldMap* , FieldMap* )
>   at FIX.Message.=(Message* , Message* )
>   at Application.toApp(Application* , Message* message, SessionID*
>sessionID)
>   at FIX.Session.sendToTarget(Message* , SessionID* )
>   at QuickFix.Session.sendToTarget(Message message, SessionID
>sessionID)
>
>  
>
Hi,

Is anyone still seeing this issue occur after applying Vladimir's patch? 
We have applied it to our code, and are still seeing them same 
exceptions arise. It is causing a major problem for us in production 
code, and I'm looking for some feedback from other users out there that 
may be contending with the same thing.

Thanks,
John

Re: [Quickfix-developers] Sequence number higher than expected logic !!

[Caleb E. <cal...@gm...>]

On Thu, 28 Oct 2004 12:48:48 +0100, em...@co...
<em...@co...> wrote:
> I am having some problems when I receive a higher than expected sequence
> number. Yes, I have read on the list that the quickfix engine will go into
> an infinite loop sending resendRequest messages.
> 
> I am wondering if someone has found a solution/patch for this problem, or
> whether this has allready been fixed and I just dont have an upto date
> version of the engine.

This was fixed in QuickFIX 1.7.1.  Which version are you using?

-- 
Caleb Epstein
cal...@gm...

Re: [Quickfix-developers] Field with embedded null character

[Caleb E. <cal...@gm...>]

On Wed, 27 Oct 2004 21:23:04 -0400, Yihu Fang <yih...@re...> wrote:
> However, in QuickFIX message constructor, it takes string as the parameter.
> It will throw an invalid message exception because it thinks the string is
> truncated at the null character and cannot find the Tag 10. 

Make sure you construct the string you pass to the Message constructor
properly.  The std::string constructor can take a const char* with or
without a length.  If you don't pass the length, it'll stop at the
first embedded \0 and you'll end up with a truncated message.

That said, it does seem that QuickFIX has a bug in the message
serialization code when dealing with fields having embedded \0 bytes:

#include <quickfix/Message.h>
#include <iostream>

using namespace FIX; using namespace std;

int main () {
  Message m;
  m.setField (1000, string ("one\0", 4));
  cout << m.toString () << endl;
  cout << m.getField (1000) << endl;
}

Gives the output (where ^A = ASCII SOH and \0 is an ASCII NULL)

9=10^A1000= one^A10=057^A
one\0

Note extra space and lack of \0 for serialized message form.

-- 
Caleb Epstein
cal...@gm...

[Quickfix-developers] Sequence number higher than expected logic !!

[<em...@co...>]

I am having some problems when I receive a higher than expected sequence
number. Yes, I have read on the list that the quickfix engine will go into
an infinite loop sending resendRequest messages.

I am wondering if someone has found a solution/patch for this problem, or
whether this has allready been fixed and I just dont have an upto date
version of the engine.


Many thanks folks,

Emir

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
 

[Quickfix-developers] Field with embedded null character

[Yihu F. <Yih...@re...>]

Hi,

=20

I understand that technically a field of string type which includes some
null character may be valid, i.e. Tag=3DABC<null><soh>. As stated in FIX
4.2 specification, "String: Alpha-numeric free format strings, can
include any character or punctuation except the delimiter".

=20

However, in QuickFIX message constructor, it takes string as the
parameter. It will throw an invalid message exception because it thinks
the string is truncated at the null character and cannot find the Tag
10.

=20

Is it true that such message is considered invalid in real world
scenario?

=20

Thanks.

=20

-Yihu

=20

=20



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

[Quickfix-developers] beginner's validation question

[Michael R. <mr...@li...>]

For some reason messages that my app(very simlar to example apps from
install) is sending are not being validated by quickFix.
I do have UseDataDictionary  and DataDictionary set....
What am I doing wrong?

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

RE: [Quickfix-developers] Multiple sessions with different start and end times

[Brendan B. B. <br...@ka...>]

On Mon, 25 Oct 2004 "Shamanth" <sha...@in...> wrote:

Shamanth,

The way I handled this was to configure QF for a single session
beginning at the start of the 1st session and ending at the end of
the last session.  I started and stopped each 'interior' session via
Application::run() which would detect the end of a session and an
outer loop which would detect the start of a session and start QF.

Regards,
Brendan

> I am using quickfix 1.8
> =20
> I have a provider who has some complex session timing settings. within a =
> day, they start and stop the sessions at multiple times, but reset the =
> sequence number only once. And also they are down on weekends.
> =20
> I wanted to have multiple sessions configured for this provider with the =
> same SenderCompID, TargetCompID and BeginString, But each of these =
> sessions would have different starttime and endtime.
> =20
> Problem: Sequence numbers get reset everytime any of the session's =
> starttime/endtime is crossed. Is it possible to configure quickfix not =
> to reset the sequence numbers based on starttime and endtime.
> =20

Re: [Quickfix-developers] Possible Bug w/ Duplicate SenderCompID's

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

The optimum would be to have a general log(or Message Handler) which
wouldn't be specific to a SenderCompID but could log events like this or
events that aren't necessarily specific to a SenderCompID.

Needless to say, logging to the *.event file is fine. I can put together a
script to monitor those files.

Thanks,

-jd-


> Yeah, what we could do is write to the event log when this happens, is
> this what you are getting at?
>
> --oren
>
> On Oct 26, 2004, at 9:08 AM, Jon Dahl wrote:
>
>> Oren,
>>
>> I noticed the fix in CVS and was looking at it in a little more detail
>> and I was wondering if there was anyway an exception could be thrown
>> when unable to register the session - because there is already one
>> registered for that SenderCompID.
>>
>> The reason being is, from an operational and troubleshooting
>> standpoint this could be a nightmare if you don't know why the
>> connection was dropped and the user simply states they can't connect
>> to the Acceptor.
>>
>> Reference(hope the link doesn't break):
>> http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/
>> SocketConnection.cpp?r1=1.8&r2=1.9
>>
>> Thanks,
>>
>> -jd-
>>
>>
>>> We have corrected this bug and added acceptance tests which are now
>>> passing for both the SocketAcceptor and ThreadedSocketAcceptor.
>>>
>>> --oren
>>>
>>> On Oct 5, 2004, at 10:30 AM, Jon Dahl 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
>>>>
>>>> Yes, I'm using SocketAcceptor, not ThreadedSocketAcceptor.
>>>>
>>>> -jd-
>>>>
>>>>> Are you using the SocketAcceptor?  Looking at it it looks to me
>>>>> like the ThreadedSocketAcceptor is handling this situation
>>>>> correctly by registering Session usage, but SocketAcceptor doesn't
>>>>> appear to be doing so.
>>>>>
>>>>> --oren
>>>>>
>>>>> On Oct 5, 2004, at 9:41 AM, Jon Dahl 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
>>>>>>
>>>>>> It seems that if a client connects to an Acceptor app with a
>>>>>> SenderCompID
>>>>>> already connected, it causes the MsgSeqNum to change to the new
>>>>>> connection
>>>>>> instead of just dropping the connection.
>>>>>>
>>>>>> Subsequently, the valid client can't enter valid messages until
>>>>>> either
>>>>>>  it
>>>>>> disconnects or the server is restarted. We reset our sequence
>>>>>> numbers after disconnect and logoff. Those who don't, may run into
>>>>>> a bigger problem.
>>>>>>
>>>>>> Anyone else run into this?
>>>>>>
>>>>>> QF 1.9.0
>>>>>> RHAS 2.1
>>>>>> gcc 3.04
>>>>>> --------
>>>>>> config:
>>>>>> .....
>>>>>> ResetOnDisconnect=Y
>>>>>> ResetOnLogout=Y
>>>>>>
>>>>>> -jd-
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> This SF.net email is sponsored by: IT Product Guide on
>>>>>> ITManagersJournal
>>>>>> Use IT products in your business? Tell us what you think of them.
>>>>>> Give
>>>>>>  us
>>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>>>>>> out
>>>>>>  more
>>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>>>> _______________________________________________
>>>>>> Quickfix-developers mailing list
>>>>>> Qui...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.net email is sponsored by: IT Product Guide on
>>>> ITManagersJournal
>>>> Use IT products in your business? Tell us what you think of them.
>>>> Give
>>>>  us
>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>>>> out
>>>>  more
>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>> _______________________________________________
>>>> Quickfix-developers mailing list
>>>> Qui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>> --
>>
>>
>> --


-- 

Re: [Quickfix-developers] Possible Bug w/ Duplicate SenderCompID's

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

Yeah, what we could do is write to the event log when this happens, is  
this what you are getting at?

--oren

On Oct 26, 2004, at 9:08 AM, Jon Dahl wrote:

> Oren,
>
> I noticed the fix in CVS and was looking at it in a little more detail
> and I was wondering if there was anyway an exception could be thrown
> when unable to register the session - because there is already one
> registered for that SenderCompID.
>
> The reason being is, from an operational and troubleshooting standpoint
> this could be a nightmare if you don't know why the connection was
> dropped and the user simply states they can't connect to the Acceptor.
>
> Reference(hope the link doesn't break):
> http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/ 
> SocketConnection.cpp?r1=1.8&r2=1.9
>
> Thanks,
>
> -jd-
>
>
>> We have corrected this bug and added acceptance tests which are now
>> passing for both the SocketAcceptor and ThreadedSocketAcceptor.
>>
>> --oren
>>
>> On Oct 5, 2004, at 10:30 AM, Jon Dahl 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
>>>
>>> Yes, I'm using SocketAcceptor, not ThreadedSocketAcceptor.
>>>
>>> -jd-
>>>
>>>> Are you using the SocketAcceptor?  Looking at it it looks to me like
>>>> the ThreadedSocketAcceptor is handling this situation correctly by
>>>> registering Session usage, but SocketAcceptor doesn't appear to be
>>>> doing so.
>>>>
>>>> --oren
>>>>
>>>> On Oct 5, 2004, at 9:41 AM, Jon Dahl 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
>>>>>
>>>>> It seems that if a client connects to an Acceptor app with a
>>>>> SenderCompID
>>>>> already connected, it causes the MsgSeqNum to change to the new
>>>>> connection
>>>>> instead of just dropping the connection.
>>>>>
>>>>> Subsequently, the valid client can't enter valid messages until
>>>>> either
>>>>>  it
>>>>> disconnects or the server is restarted. We reset our sequence
>>>>> numbers after disconnect and logoff. Those who don't, may run into
>>>>> a bigger problem.
>>>>>
>>>>> Anyone else run into this?
>>>>>
>>>>> QF 1.9.0
>>>>> RHAS 2.1
>>>>> gcc 3.04
>>>>> --------
>>>>> config:
>>>>> .....
>>>>> ResetOnDisconnect=Y
>>>>> ResetOnLogout=Y
>>>>>
>>>>> -jd-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.net email is sponsored by: IT Product Guide on
>>>>> ITManagersJournal
>>>>> Use IT products in your business? Tell us what you think of them.
>>>>> Give
>>>>>  us
>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>>>>> out
>>>>>  more
>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>>> _______________________________________________
>>>>> Quickfix-developers mailing list
>>>>> Qui...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IT Product Guide on
>>> ITManagersJournal
>>> Use IT products in your business? Tell us what you think of them.
>>> Give
>>>  us
>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>>> out
>>>  more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> -- 
>
>
> -- 
>
>
>
>

Re: [Quickfix-developers] Fixed massive memory leak in .NET CPPMessageStore

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

Thanks Vlad,

We are actually removing that method.  It is redundant and is not even =20=

used as you pointed out since the session always uses the get call that =20=

returns a range.  We'll add this patch.  Thanks for giving the .NET API =20=

a workout.

--oren

On Oct 26, 2004, at 6:19 AM, Vladimir Arnost wrote:

> Hello,
>
> I have fixed a massive memory leak in .NET CPPMessageStore class in =20=

> QuickFIX 1.9.2. Every time a FIX message was stored, a copy would be =20=

> leaked. My tests show that hundreds of megabytes(!) of memory may be =20=

> leaked in a few hours on a busy server, making it run out of memory.
>
> The bug seems to be a rather silly oversight and it could be =20
> automatically detected by VS.NET compiler if only Warning Level 4 was =20=

> selected in the project settings (this, unfortunately, reports dozens =20=

> of other less severe warnings, so code cleanup would be inevitable to =20=

> get a clean build).
>
> Method CPPMessageStore::get( int sequence, String* message ) was =20
> completely broken, but it didn't show up because it is never called.
>
>
>
> Here is the diff:
>
> --- CPPMessageStore.h=A0=A0 2004-04-29 15:08:18.000000000 +0200
>  +++ CPPMessageStore.h.new=A0=A0=A0=A0=A0=A0 2004-10-26 =
11:58:51.597017500 +0200
>  @@ -48,8 +48,9 @@
>  =A0
>  =A0=A0=A0=A0 try
>  =A0=A0=A0=A0 { char* umessage =3D createUnmanagedString( message );
>  -=A0=A0=A0=A0=A0 return m_pUnmanaged->set( sequence, umessage );
>  +=A0=A0=A0=A0=A0 bool rc =3D m_pUnmanaged->set( sequence, umessage );
>  =A0=A0=A0=A0=A0=A0 destroyUnmanagedString( umessage );
>  +=A0=A0=A0=A0=A0 return rc;
>  =A0=A0=A0=A0 }
>  =A0=A0=A0=A0 catch ( FIX::IOException& )
>  =A0=A0=A0=A0 { throw new IOException(); }
>  @@ -63,8 +64,9 @@
>  =A0=A0=A0=A0 try
>  =A0=A0=A0=A0 {
>  =A0=A0=A0=A0=A0=A0 std::string string;
>  -=A0=A0=A0=A0=A0 return m_pUnmanaged->get( sequence, string );
>  +=A0=A0=A0=A0=A0 bool rc =3D m_pUnmanaged->get( sequence, string );
>  =A0=A0=A0=A0=A0=A0 message =3D string.c_str();
> +=A0=A0=A0=A0=A0 return rc;
>  =A0=A0=A0=A0 }
>  =A0=A0=A0=A0 catch ( FIX::IOException& )
>  =A0=A0=A0=A0 { throw new IOException(); }
>
>
>
> Please put this patch to the official source tree before the next =20
> release.
>
> Cheers,
>  =A0 Vlad
>
> -------------------------------------------------------------
>  Ing. Vladimir Arnost, Developer, FFastFill Europe Ltd.
>  Vaclavske namesti 55, Prague, Czech Republic
>
>
>  =20
> =
_______________________________________________________________________=20=

> _
>  This email and any files transmitted with it are confidential and
>  intended solely for the use of the individual or entity to whom they
>  are addressed. If you have received this email in error please notify
>  sec...@ff...
>
>  This email has been scanned for all viruses by the FFastFill Email
>  Security System.
>  =20
> =
_______________________________________________________________________=20=

> _
> =20=

Re: [Quickfix-developers] Possible Bug w/ Duplicate SenderCompID's

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

Oren,

I noticed the fix in CVS and was looking at it in a little more detail
and I was wondering if there was anyway an exception could be thrown
when unable to register the session - because there is already one
registered for that SenderCompID.

The reason being is, from an operational and troubleshooting standpoint
this could be a nightmare if you don't know why the connection was
dropped and the user simply states they can't connect to the Acceptor.

Reference(hope the link doesn't break):
http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/SocketConnection.cpp?r1=1.8&r2=1.9

Thanks,

-jd-


> We have corrected this bug and added acceptance tests which are now
> passing for both the SocketAcceptor and ThreadedSocketAcceptor.
>
> --oren
>
> On Oct 5, 2004, at 10:30 AM, Jon Dahl 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
>>
>> Yes, I'm using SocketAcceptor, not ThreadedSocketAcceptor.
>>
>> -jd-
>>
>>> Are you using the SocketAcceptor?  Looking at it it looks to me like
>>> the ThreadedSocketAcceptor is handling this situation correctly by
>>> registering Session usage, but SocketAcceptor doesn't appear to be
>>> doing so.
>>>
>>> --oren
>>>
>>> On Oct 5, 2004, at 9:41 AM, Jon Dahl 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
>>>>
>>>> It seems that if a client connects to an Acceptor app with a
>>>> SenderCompID
>>>> already connected, it causes the MsgSeqNum to change to the new
>>>> connection
>>>> instead of just dropping the connection.
>>>>
>>>> Subsequently, the valid client can't enter valid messages until
>>>> either
>>>>  it
>>>> disconnects or the server is restarted. We reset our sequence
>>>> numbers after disconnect and logoff. Those who don't, may run into
>>>> a bigger problem.
>>>>
>>>> Anyone else run into this?
>>>>
>>>> QF 1.9.0
>>>> RHAS 2.1
>>>> gcc 3.04
>>>> --------
>>>> config:
>>>> .....
>>>> ResetOnDisconnect=Y
>>>> ResetOnLogout=Y
>>>>
>>>> -jd-
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.net email is sponsored by: IT Product Guide on
>>>> ITManagersJournal
>>>> Use IT products in your business? Tell us what you think of them.
>>>> Give
>>>>  us
>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>>>> out
>>>>  more
>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>> _______________________________________________
>>>> Quickfix-developers mailing list
>>>> Qui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>> --
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on
>> ITManagersJournal
>> Use IT products in your business? Tell us what you think of them.
>> Give
>>  us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
>> out
>>  more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers


-- 


-- 

[Quickfix-developers] Fixed massive memory leak in .NET CPPMessageStore

[Vladimir A. <Vla...@FF...>]

Hello,

I=20have=20fixed=20a=20massive=20memory=20leak=20in=20.NET=20CPPMessageSto=
re=20class=20in
QuickFIX=201.9.2.=20Every=20time=20a=20FIX=20message=20was=20stored,=20a=20=
copy=20would=20be
leaked.=20My=20tests=20show=20that=20hundreds=20of=20megabytes(!)=20of=20m=
emory=20may=20be
leaked=20in=20a=20few=20hours=20on=20a=20busy=20server,=20making=20it=20ru=
n=20out=20of=20memory.

The=20bug=20seems=20to=20be=20a=20rather=20silly=20oversight=20and=20it=20=
could=20be
automatically=20detected=20by=20VS.NET=20compiler=20if=20only=20Warning=20=
Level=204=20was
selected=20in=20the=20project=20settings=20(this,=20unfortunately,=20repor=
ts=20dozens=20of
other=20less=20severe=20warnings,=20so=20code=20cleanup=20would=20be=20ine=
vitable=20to=20get=20a
clean=20build).

Method=20CPPMessageStore::get(=20int=20sequence,=20String*=20message=20)=20=
was
completely=20broken,=20but=20it=20didn't=20show=20up=20because=20it=20is=20=
never=20called.


Here=20is=20the=20diff:

---=20CPPMessageStore.h=092004-04-29=2015:08:18.000000000=20+0200
+++=20CPPMessageStore.h.new=092004-10-26=2011:58:51.597017500=20+0200
@@=20-48,8=20+48,9=20@@
=20
=20=20=20=20=20try
=20=20=20=20=20{=20char*=20umessage=20=3D=20createUnmanagedString(=20messa=
ge=20);
-=20=20=20=20=20=20return=20m_pUnmanaged->set(=20sequence,=20umessage=20);=
=20
+=20=20=20=20=20=20bool=20rc=20=3D=20m_pUnmanaged->set(=20sequence,=20umes=
sage=20);=20
=20=20=20=20=20=20=20destroyUnmanagedString(=20umessage=20);
+=20=20=20=20=20=20return=20rc;
=20=20=20=20=20}
=20=20=20=20=20catch=20(=20FIX::IOException&=20)
=20=20=20=20=20{=20throw=20new=20IOException();=20}
@@=20-63,8=20+64,9=20@@
=20=20=20=20=20try
=20=20=20=20=20{
=20=20=20=20=20=20=20std::string=20string;
-=20=20=20=20=20=20return=20m_pUnmanaged->get(=20sequence,=20string=20);
+=20=20=20=20=20=20bool=20rc=20=3D=20m_pUnmanaged->get(=20sequence,=20stri=
ng=20);
=20=20=20=20=20=20=20message=20=3D=20string.c_str();
+=20=20=20=20=20=20return=20rc;
=20=20=20=20=20}
=20=20=20=20=20catch=20(=20FIX::IOException&=20)
=20=20=20=20=20{=20throw=20new=20IOException();=20}


Please=20put=20this=20patch=20to=20the=20official=20source=20tree=20before=
=20the=20next
release.

Cheers,
=20=20Vlad

-------------------------------------------------------------
Ing.=20Vladimir=20Arnost,=20Developer,=20FFastFill=20Europe=20Ltd.
Vaclavske=20namesti=2055,=20Prague,=20Czech=20Republic



________________________________________________________________________
This=20email=20and=20any=20files=20transmitted=20with=20it=20are=20confide=
ntial=20and
intended=20solely=20for=20the=20use=20of=20the=20individual=20or=20entity=20=
to=20whom=20they
are=20addressed.=20If=20you=20have=20received=20this=20email=20in=20error=20=
please=20notify
sec...@ff...

This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20FFa=
stFill=20Email
Security=20System.
________________________________________________________________________

[Quickfix-developers] Multiple sessions with different start and end times

[Shamanth <sha...@in...>]

Hi=20
=20
I am using quickfix 1.8
=20
I have a provider who has some complex session timing settings. within a =
day, they start and stop the sessions at multiple times, but reset the =
sequence number only once. And also they are down on weekends.
=20
I wanted to have multiple sessions configured for this provider with the =
same SenderCompID, TargetCompID and BeginString, But each of these =
sessions would have different starttime and endtime.
=20
Problem: Sequence numbers get reset everytime any of the session's =
starttime/endtime is crossed. Is it possible to configure quickfix not =
to reset the sequence numbers based on starttime and endtime.
=20
thanks
R Shamanth

[Quickfix-developers] DK Reason Z value missing

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

Hi all,

I noticed in the FIX40.xml, FIX41.xml, FIX42.xml (possibly higher versions
too) available at http://quickfixengine.org/FIX42.xml that the field value
Z doesn't exist for tag 127 (DKReason). The spec over at
www.fixprotocol.org says different (
http://fixprotocol.org/specifications/fix4.2fiximate/fixTable.xml#DKReason
).

Regards,
Ilyas




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

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

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

RE: [Quickfix-developers] SEDOL code to RIC code

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

Steven,
=20
  There's no magic formula to do this sort of conversion, mappings such =
as this are outside the scope of FIX and would generally (ideally) be =
performed/maintained by some centralized business unit.
=20
Jem....
=20

-----Original Message-----
From: qui...@li... =
[mailto:qui...@li...]On Behalf Of =
Steven Leung
Sent: Thursday, October 21, 2004 4:33 AM
To: qui...@li...
Subject: [Quickfix-developers] SEDOL code to RIC code



Hi all,

=20

           Do anyone know how to convert a SEDOL security code to RIC =
code format? Do I need to change from SEDOL to ISIN format and then =
change to RIC code? Any direct conversion mapping?

=20

Many Thanks

Steven

[Quickfix-developers] Groups

[<em...@co...>]

Hi All,

I have a following structure in C++ that I would like to translate into Fix
4.2 or desribe it :

struct t_group {
	int x;
	int y;
};

struct blabla
{
	int tag_;
	t_group	data_[];
};

the above just means that blabla holds and int and an array of t_group
structures of an unspecified size (the size can vary and can be anything >
0).

Please help.

Emir


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
 

Re: [Quickfix-developers] RE: [Quickfix-users] Logon Ack seqNo

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

Yes, this change is going into the next version.

--oren

On Oct 20, 2004, at 5:25 AM, Shamanth wrote:

> Hi Oren
> =A0
> Thanks for the reply, Regarding Answer 2 below,
>  =A0
> You are right, Acceptor is not a quickfix engine, but a custom built=20=

> one used by one of our providers. It seems, he is sending this huge=20
> number(2147483647)=A0in resend requests to signify infinity.=A0
> =A0
> I think the code you have give below, should solve this problem. Is it=20=

> possible to incorporate this change in the next release of quickfix.
> =A0
> thanks
> R Shamanth
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, October 19, 2004 8:29 PM
> To: Shamanth
> Cc: qui...@li...;=20
> qui...@li...
> Subject: Re: [Quickfix-users] Logon Ack seqNo
>
>
> Answer1:
>
>
>
>  No. This is in fact normal behavior. Whenever a message is sent the=20=

> sequence number has to be incremented. Just because we did not receive=20=

> an ack, does not necessarily mean the counter-party did not receive=20
> the logon. If the sequence number was not incremented, and they had=20
> actually received it without acknowledging, you would then encounter=20=

> disconnect scenarios due to too low sequence numbers at some point. A=20=

> much worse position to be in as it cannot be resolved automatically.
>
>
>
>  Having a sequence number that is too high isn't much of a problem=20
> since the two engines can resolve this on their own. And since in this=20=

> case we are talking about logon messages, all that is required is a=20
> single gap fill message to put everything in order.
>
>
>
>  Answer2:
>
>
>
>  Depends on the version. For FIX.4.2 and higher, the value should be=20=

> 0. For versions 4.1 and earlier, a special value of 999999 is used.=20
> I'm a bit curious as to what is going on here. Is both the initiator=20=

> and acceptor QuickFIX. It seems strange because since QuickFIX 1.6,=20
> the EndSeqNo is always send either 0 or 999999, never another value.=20=

> Based on this I'm guessing the acceptor in this scenario is not=20
> QuickFIX, is this correct?
>
>
>
>  As to the effect of the value 2147483647, I suspect your application=20=

> has stopped responding because you now got the message store trying to=20=

> look up a hell of a lot of messages in a tight loop. I suspect we can=20=

> have QuickFIX handle this situation more gracefully if we consider=20
> such a situation equivalent to an infinite request as such:
>
>
>
>  if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||
>
>  beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 999999 ||
>
>  endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle=20
> bizarrely large numbers
>
>  { endSeqNo =3D getExpectedSenderNum() - 1; }
>
>
>
>
>  On Oct 19, 2004, at 7:08 AM, Shamanth wrote:
>
>
>
>  Hi
>
>
>
> I am using quickfix 1.8,
>
>
>
> While testing due to some network problems we got disconnected from=20
> the "Acceptor". In the mean time, our "initiator" tried reconnecting=20=

> to the "acceptor" every 30secs.
>
>
>
> It tried it 8 times before it could get an ack for its logon message.
>
>
>
>
> Problem1: Our initiator, sent 8 logon messages and only the 9th logon=20=

> message was ack by the acceptor. But in the meantime, our initiator=20
> incremented its MsgSeqNo, so when both the initiator and acceptor got=20=

> connected, there was a mismatch of SeqNo, and the =93acceptor=94 send =
a=20
> resendRequest to the =93initiator=94
>
>
>
> Question: Is there a way we can prevent the quickfix initiator from=20
> incrementing its SeqNo, if it did not receive Ack for its Logon msg.
>
>
>
> NOTE: Only the SeqNo of the messages sent was incremented, while the=20=

> SeqNo of the messages received was correct.
>
>
>
>
>
> Problem2: After connecting again the Acceptor sent, a resend request=20=

> FROM: 0 TO: 2147483647, our initiator had not sent so many messages,=20=

> so it considers it as an error condition and stops responding to the=20=

> acceptor. Is =932147483647=94 the maximum value in resend request as =
per=20
> fix protocol or should =930=94(infinity) be considered as the max =
valueis=20
> considered as the maximum number?
>
>
>
> thanks
>
>
>
> R Shamanth

[Quickfix-developers] SEDOL code to RIC code

[Steven L. <ste...@2G...>]

Hi all,

=20

           Do anyone know how to convert a SEDOL security code to RIC
code format? Do I need to change from SEDOL to ISIN format and then
change to RIC code? Any direct conversion mapping?

=20

Many Thanks

Steven

[Quickfix-developers] Re: [Quickfix-users] 1.9.2 body lenght mismatch

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

Shamanth,

This looks like a problem that has been fixed.  The fix is available in =20=

CVS and will be released with 1.9.3

--oren

On Oct 20, 2004, at 4:23 AM, Shamanth wrote:

> Hi
> =C2=A0
> I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =20=

> downloaded the source and build them in windows.
>  Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI =20
> wrappers, and not the C++ code directly
> =C2=A0
> Problem:
> When I send a MarketDataRequest, I get the following error in the =20
> Acceptor, I have pasted the original message also below.
> =C2=A0
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
> =
=C2=A0(8=3DFIX.4.2=E2=98=BA9=3D151=E2=98=BA35=3DV=E2=98=BA34=3D2=E2=98=BA4=
9=3DITLClientMD=E2=98=BA52=3D2004102008:37:=20
> =
50.617=E2=98=BA56=3DITLServer=E2=98=BA146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA=
146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA146=3D1=E2=98=BA55=3DEUR/=20
> =
USD=E2=98=BA262=3D123456=E2=98=BA263=3D1=E2=98=BA264=3D0=E2=98=BA265=3D1=E2=
=98=BA267=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA267=3D2=E2=98=BA269=3D=
0=E2=98=BA269=3D1=E2=98=BA26=20
> 7=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA10=3D165=E2=98=BA)
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
> =C2=A0 (Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
> =C2=A0
> In my initiator log, I am printing the XML of the message before =20
> sending, I see that it is not getting resolved properly
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8"><![CDATA[FIX.4.2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35"><![CDATA[V]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49"><![CDATA[ITLClientMD]]></field>
> =C2=A0=C2=A0=C2=A0 <field =
number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56"><![CDATA[ITLServer]]></field>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262"><![CDATA[123456]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"55"><![CDATA[EUR/USD]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> =C2=A0
> Note: If I replace the quickfix.jar, quickfix.lib and quickfix_jni.dll =
=20
> of 1.8, then every thing works fine. I notice this problem only with =20=

> 1.9.2 jars and dlls.
> =C2=A0
> This is how the XML looks with 1.8 jars and dlls
> =C2=A0
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8" value=3D"FIX.4.2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35" value=3D"V"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49" value=3D"ITLClientMD"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"52" =
value=3D"20041020-08:47:49.679"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56" value=3D"ITLServer"/>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262" value=3D"123456"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"55" value=3D"EUR/USD"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> </message>
> =C2=A0
> any idea what could be the problem, has any one else faced the same =20=

> problem.
> =C2=A0
> thanks
> R Shamanth

[Quickfix-developers] Re: [Quickfix-users] 1.9.2 body lenght mismatch

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

Can you post the code you are using to create this message?

--oren

On Oct 20, 2004, at 4:23 AM, Shamanth wrote:

> Hi
> =C2=A0
> I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =20=

> downloaded the source and build them in windows.
>  Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI =20
> wrappers, and not the C++ code directly
> =C2=A0
> Problem:
> When I send a MarketDataRequest, I get the following error in the =20
> Acceptor, I have pasted the original message also below.
> =C2=A0
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
> =
=C2=A0(8=3DFIX.4.2=E2=98=BA9=3D151=E2=98=BA35=3DV=E2=98=BA34=3D2=E2=98=BA4=
9=3DITLClientMD=E2=98=BA52=3D2004102008:37:=20
> =
50.617=E2=98=BA56=3DITLServer=E2=98=BA146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA=
146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA146=3D1=E2=98=BA55=3DEUR/=20
> =
USD=E2=98=BA262=3D123456=E2=98=BA263=3D1=E2=98=BA264=3D0=E2=98=BA265=3D1=E2=
=98=BA267=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA267=3D2=E2=98=BA269=3D=
0=E2=98=BA269=3D1=E2=98=BA26=20
> 7=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA10=3D165=E2=98=BA)
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
> =C2=A0 (Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
> =C2=A0
> In my initiator log, I am printing the XML of the message before =20
> sending, I see that it is not getting resolved properly
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8"><![CDATA[FIX.4.2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35"><![CDATA[V]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49"><![CDATA[ITLClientMD]]></field>
> =C2=A0=C2=A0=C2=A0 <field =
number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56"><![CDATA[ITLServer]]></field>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262"><![CDATA[123456]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"55"><![CDATA[EUR/USD]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> =C2=A0
> Note: If I replace the quickfix.jar, quickfix.lib and quickfix_jni.dll =
=20
> of 1.8, then every thing works fine. I notice this problem only with =20=

> 1.9.2 jars and dlls.
> =C2=A0
> This is how the XML looks with 1.8 jars and dlls
> =C2=A0
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8" value=3D"FIX.4.2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35" value=3D"V"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49" value=3D"ITLClientMD"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"52" =
value=3D"20041020-08:47:49.679"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56" value=3D"ITLServer"/>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262" value=3D"123456"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"55" value=3D"EUR/USD"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> </message>
> =C2=A0
> any idea what could be the problem, has any one else faced the same =20=

> problem.
> =C2=A0
> thanks
> R Shamanth

[Quickfix-developers] RE: [Quickfix-users] Logon Ack seqNo

[Shamanth <sha...@in...>]

Hi Oren
=20
Thanks for the reply, Regarding Answer 2 below,=20
=20
You are right, Acceptor is not a quickfix engine, but a custom built one =
used by one of our providers. It seems, he is sending this huge =
number(2147483647) in resend requests to signify infinity.=20
=20
I think the code you have give below, should solve this problem. Is it =
possible to incorporate this change in the next release of quickfix.
=20
thanks
R Shamanth

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Tuesday, October 19, 2004 8:29 PM
To: Shamanth
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-users] Logon Ack seqNo



Answer1:=20


No. This is in fact normal behavior. Whenever a message is sent the =
sequence number has to be incremented. Just because we did not receive =
an ack, does not necessarily mean the counter-party did not receive the =
logon. If the sequence number was not incremented, and they had actually =
received it without acknowledging, you would then encounter disconnect =
scenarios due to too low sequence numbers at some point. A much worse =
position to be in as it cannot be resolved automatically.=20


Having a sequence number that is too high isn't much of a problem since =
the two engines can resolve this on their own. And since in this case we =
are talking about logon messages, all that is required is a single gap =
fill message to put everything in order.=20


Answer2:=20


Depends on the version. For FIX.4.2 and higher, the value should be 0. =
For versions 4.1 and earlier, a special value of 999999 is used. I'm a =
bit curious as to what is going on here. Is both the initiator and =
acceptor QuickFIX. It seems strange because since QuickFIX 1.6, the =
EndSeqNo is always send either 0 or 999999, never another value. Based =
on this I'm guessing the acceptor in this scenario is not QuickFIX, is =
this correct?=20


As to the effect of the value 2147483647, I suspect your application has =
stopped responding because you now got the message store trying to look =
up a hell of a lot of messages in a tight loop. I suspect we can have =
QuickFIX handle this situation more gracefully if we consider such a =
situation equivalent to an infinite request as such:=20


if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||=20

beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 999999 ||=20

endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle bizarrely =
large numbers=20

{ endSeqNo =3D getExpectedSenderNum() - 1; }=20



On Oct 19, 2004, at 7:08 AM, Shamanth wrote:=20


Hi=20


I am using quickfix 1.8,=20


While testing due to some network problems we got disconnected from the =
"Acceptor". In the mean time, our "initiator" tried reconnecting to the =
"acceptor" every 30secs.=20


It tried it 8 times before it could get an ack for its logon message.=20



Problem1: Our initiator, sent 8 logon messages and only the 9th logon =
message was ack by the acceptor. But in the meantime, our initiator =
incremented its MsgSeqNo, so when both the initiator and acceptor got =
connected, there was a mismatch of SeqNo, and the =93acceptor=94 send a =
resendRequest to the =93initiator=94=20


Question: Is there a way we can prevent the quickfix initiator from =
incrementing its SeqNo, if it did not receive Ack for its Logon msg.=20


NOTE: Only the SeqNo of the messages sent was incremented, while the =
SeqNo of the messages received was correct.=20




Problem2: After connecting again the Acceptor sent, a resend request =
FROM: 0 TO: 2147483647, our initiator had not sent so many messages, so =
it considers it as an error condition and stops responding to the =
acceptor. Is =932147483647=94 the maximum value in resend request as per =
fix protocol or should =930=94(infinity) be considered as the max =
valueis considered as the maximum number?=20


thanks=20


R Shamanth=20