quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Sql Server

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

Connections to SQL should be done via an ODBC connection.  The sql api
was deprecated so we switch to using ODBC for MSSQL.

--oren

> -------- Original Message --------
> Subject: [Quickfix-developers] Sql Server
> From: "Manuel Lopez" <lop...@gm...>
> Date: Thu, May 15, 2008 8:22 am
> To: qui...@li...
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> Since sql server connect code is no longer present, and since I would
> like to add my own, what would the best way to do that?  Is there a
> method or series of methods to override?  Or is that not recommended?
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] SQL Server support

[Manuel L. <lop...@gm...>]

Since sql server connect code is no longer present, and since I would
like to add my own, what would the best way to do that?  Is there a
method or series of methods to override?  Or is that not recommended?

[Quickfix-developers] Documentation

[Manuel L. <lop...@gm...>]

The code is very well done, but I think the documentation could still
be improved, particularly the explanation and basic overview of how
things work--I mean the key concepts or classes and their
interrelationship, perhaps along with an explanation of what some of
the key code lines in the explanations do.  A little bit would go a
long way.

[Quickfix-developers] Sql Server

[Manuel L. <lop...@gm...>]

Since sql server connect code is no longer present, and since I would
like to add my own, what would the best way to do that?  Is there a
method or series of methods to override?  Or is that not recommended?

Re: [Quickfix-developers] FileStore crashes in .NET?

[Rick L. <ric...@gm...>]

Sibte,

I'm using the NTFS file system in Windows Server 2003.

Thanks,
Rick

Sibte Abbas wrote:
> Can it be because of windows file size limits (just guessing)? Do we 
> handle those in quickfix?
>
> Rick,
>
> Which file system is your FileStore using to store data?
>
> thanks,
> -- Sibte
>
> On Tue, May 13, 2008 at 5:10 PM, <or...@qu... 
> <mailto:or...@qu...>> wrote:
>
>     QuickFIX Documentation:
>     http://www.quickfixengine.org/quickfix/doc/html/index.html
>     QuickFIX Support: http://www.quickfixengine.org/services.html
>
>     Well, I know there were some fixes put it recently where unmanaged
>     exceptions were not properly caught and propogated to the VM.
>      Maybe it
>     has something to do with that.  Do your logs provide any insight
>     on what
>     was going on at the time of crash?
>
>     --oren
>
>     > -------- Original Message --------
>     > Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
>     > From: Rick Lane <ric...@gm... <mailto:ric...@gm...>>
>     > Date: Tue, May 13, 2008 2:45 pm
>     > To: or...@qu... <mailto:or...@qu...>
>     > Cc: qui...@li...
>     <mailto:qui...@li...>
>     > QuickFIX Documentation:
>     http://www.quickfixengine.org/quickfix/doc/html/index.html
>     > QuickFIX Support:
>     http://www.quickfixengine.org/services.html<hr>Greetings,
>     > I brought up an issue 2 months ago where it seemed that my FileStore
>     > might be crashing.  The issue somewhat went away and has now
>     resurfaced
>     > -- I'm no longer convinced this occurred from the FileStore, but
>     I am
>     > fairly convinced this is a QuickFix issue.
>     > My trading application is built in C# .NET 2.0, and so I'm using the
>     > quickfix_net and quickfix_net_messages DLLs.  From what I gather
>     about
>     > these DLLs, they are .NET wrappers around the native, unmanaged
>     code.
>     > The crashes I'm seeing are not of the friendly type -- in other
>     words,
>     > they don't give me the option to debug, and they give me no
>     information
>     > (they aren't the "You application has experienced an error and
>     needs to
>     > close" variety).  Rather, they are the "Runtime Error!!!" with
>     the big
>     > red "X" dialogs that signal a hard crash.  I believe this only ever
>     > occurs with unmanaged native code, which tells me (because the
>     quickfix
>     > DLLs are the only such code) that this must be occurring within
>     these
>     > libraries.
>     > My application processes /many /messages in a day -- it often
>     processes
>     > more than 1 million messages in any given day (I'm not sure if
>     that's
>     > common or on the high end, but something tells me it's on the high
>     > end).  And so I have a very rapid messaging rate.  What I'm
>     wondering is
>     > if anyone has ever seen these types of "hard" application
>     crashes before
>     > and possibly any remedies or ideas as to what might be causing it.
>     > The absolute worst part about all of this is that Dr Watson dump
>     files
>     > (.dmp) are not being generated.  They were generated the first
>     few times
>     > crashes occurred, but I installed Visual Studio and that, for some
>     > reason, stopped the dump files from being generated.  So I have
>     > absolutely no visibility into this error -- any help is greatly
>     appreciated.
>     > Thanks,
>     > Rick
>     > or...@qu... <mailto:or...@qu...> wrote:
>     > > Never mind.  I can see it's VS8 from your post.  Might be able
>     to do
>     > > something about this by changing the build settings.  I don't
>     think
>     > > it's a coding error.  I'm looking into the microsoft knowledge
>     base
>     > > for possible solutions.
>     > >
>     > >     -------- Original Message --------
>     > >     Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
>     > >     From: Rick Lane <ric...@gm...
>     <mailto:ric...@gm...>>
>     > >     Date: Fri, March 14, 2008 2:41 pm
>     > >     To: qui...@li...
>     <mailto:qui...@li...>
>     > >     <mailto:qui...@li...
>     <mailto:qui...@li...>>
>     > >
>     > >     QuickFIX Documentation:
>     > >     http://www.quickfixengine.org/quickfix/doc/html/index.html
>     > >     QuickFIX Support: http://www.quickfixengine.org/services.html
>     > >
>     > >    
>     ------------------------------------------------------------------------
>     > >     After some more digging, I'm attempting to load the .dmp file
>     > >     generated at the application crash into Visual Studio.
>      There are
>     > >     many entries for quickfix_net.dll (which, as you said, may not
>     > >     mean there was a problem with quickfix), but it would be
>     nice to
>     > >     be able to load the .pdb file for QuickFix into Visual
>     Studio so I
>     > >     can see actual function names instead of just assembly
>     mumbo jumbo.
>     > >
>     > >     I tried loading both the debug/vs8/quickfix_net.pdb and the
>     > >     release/vs8/quickfix_net.pdb and for both it said it "did not
>     > >     match the module."  Has anyone tried to load these pdb
>     files into
>     > >     studio for debugging purposes?  incidentally, the
>     exception is:
>     > >     "Unhandled exception at 0x77e4bee7 in user.dmp:
>     0xC0020001: The
>     > >     string binding is invalid."  I've done some research on
>     this and
>     > >     in most cases it seems to occur when people are blending
>     managed
>     > >     and unmanaged code.  Outside of QuickFix, I do /not /have any
>     > >     unmanaged code -- so is this looking more like it might be a
>     > >     native issue (after all, isn't the .NET QuickFix library
>     just a
>     > >     wrapper around the unmanaged version?).
>     > >
>     > >     call stack at crash:
>     > >
>     > >     >    kernel32.dll!77e4bee7()
>     > >          [Frames below may be incorrect and/or missing, no symbols
>     > >     loaded for kernel32.dll]
>     > >          kernel32.dll!77e4bee7()
>     > >          quickfix_net.dll!10084f0c()
>     > >          quickfix_net.dll!100938d5()
>     > >          quickfix_net.dll!10093938()
>     > >
>     > >
>     > >     or...@qu... <mailto:or...@qu...>
>     <mailto:or...@qu... <mailto:or...@qu...>>
>     wrote:
>     > >>     I don't know of any outstanding bugs with the filestore.
>      Do you
>     > >>     have any kind of stack trace.  Keep in mind that the
>     > >>     quickfix_net.dll will pretty much always show up because
>     events
>     > >>     are being passed from quickfix to your application.  So
>     crashes
>     > >>     in your application will generally appear to start out in the
>     > >>     quickfix dll.  12 MB is pretty big, but not outrageous
>     and I've
>     > >>     seen bigger.  None of it is kept in memory, it's only
>     read in as
>     > >>     needed for resend requests and such.  Any idea if one was
>     being
>     > >>     processed during your crash?
>     > >>
>     > >>     --oren
>     > >>
>     > >>         -------- Original Message --------
>     > >>         Subject: [Quickfix-developers] FileStore crashes in .NET?
>     > >>         From: Rick Lane <ric...@gm...
>     <mailto:ric...@gm...>>
>     > >>         Date: Fri, March 14, 2008 11:39 am
>     > >>         To: qui...@li...
>     <mailto:qui...@li...>
>     > >>         <mailto:qui...@li...
>     <mailto:qui...@li...>>
>     > >>
>     > >>         QuickFIX Documentation:
>     > >>        
>     http://www.quickfixengine.org/quickfix/doc/html/index.html
>     > >>         QuickFIX Support:
>     http://www.quickfixengine.org/services.html
>     > >>
>     > >>         Greetings,
>     > >>
>     > >>         Have there been any documented instances of QuickFix
>     causing an
>     > >>         application crash in .NET related to the FileStore? My
>     > >>         application was
>     > >>         running along just fine, entering no orders (and with no
>     > >>         orders, and
>     > >>         therefore no execution reports) for a couple hours
>     after a
>     > >>         very busy
>     > >>         morning. So for about an hour, the only traffic
>     through QuickFix
>     > >>         should've been heartbeats. I received an Application
>     crash --
>     > >>         not the
>     > >>         good kind, the kind that pretty much doesn't let you
>     do any
>     > >>         sort of
>     > >>         recovery -- for the first time (I've gotten many
>     crashes due
>     > >>         to a null
>     > >>         pointer, etc., but these can be caught and therefore
>     > >>         recovered from).
>     > >>
>     > >>         I'm not 100% sure QuickFix caused this -- I'm in the
>     process
>     > >>         of thumbing
>     > >>         through the memory dump created by Dr Watson (I'm not
>     very
>     > >>         good at this)
>     > >>         -- but the quickfix_net dll keeps popping up in the
>     log, so I
>     > >>         decided to
>     > >>         go check out the FileStore file. I was surprised to
>     see it
>     > >>         was nearly
>     > >>         12 MB (which I guess because of a busy morning, this
>     is to be
>     > >>         expected?). This crash could very well have been due
>     to the
>     > >>         market data
>     > >>         portion of my app (which listens to the CME's
>     FIX/FAST data
>     > >>         stream) but
>     > >>         I thought I was handling those types of errors better
>     than
>     > >>         this, so I
>     > >>         just wanted to see if anyone else has seen unexpected
>     crashes
>     > >>         w/ the
>     > >>         .NET quickfix library, possibly having something to
>     do with
>     > >>         the FileStore?
>     > >>
>     > >>         Thanks in advance,
>     > >>         Rick
>     > >>
>     > >>        
>     -------------------------------------------------------------------------
>     > >>         This SF.net <http://SF.net> email is sponsored by:
>     Microsoft
>     > >>         Defy all challenges. Microsoft(R) Visual Studio 2008.
>     > >>         http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     > >>         _______________________________________________
>     > >>         Quickfix-developers mailing list
>     > >>         Qui...@li...
>     <mailto:Qui...@li...>
>     > >>         <mailto:Qui...@li...
>     <mailto:Qui...@li...>>
>     > >>        
>     https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>     > >>
>     > >    
>     ------------------------------------------------------------------------
>     > >    
>     -------------------------------------------------------------------------
>     > >     This SF.net <http://SF.net> email is sponsored by: Microsoft
>     > >     Defy all challenges. Microsoft(R) Visual Studio 2008.
>     > >     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     > >    
>     ------------------------------------------------------------------------
>     > >     _______________________________________________
>     > >     Quickfix-developers mailing list
>     > >     Qui...@li...
>     <mailto:Qui...@li...> <#Compose>
>     > >    
>     https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>     >
>     ><hr>-------------------------------------------------------------------------
>     > This SF.net email is sponsored by: Microsoft
>     > Defy all challenges. Microsoft(R) Visual Studio 2008.
>     >
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/<hr>_______________________________________________
>     > Quickfix-developers mailing list
>     > Qui...@li...
>     <mailto:Qui...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by: Microsoft
>     Defy all challenges. Microsoft(R) Visual Studio 2008.
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     _______________________________________________
>     Quickfix-developers mailing list
>     Qui...@li...
>     <mailto:Qui...@li...>
>     https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>

Re: [Quickfix-developers] FileStore crashes in .NET?

[Rick L. <ric...@gm...>]

Oren,

ok, so do you suggest I get the latest code and build -- to include 
these fixes?  Up until now, I've just been using the last "release" codeset.

Unfortunately, I don't really have any logs -- for speed issues, I 
disabled the FileLogFactory, and I don't get any Windows crash logs, 
etc., because Windows isn't recognizing this as an Application Error 
(which is why, I believe, Dr Watson is never being called).

Rick

or...@qu... wrote:
> Well, I know there were some fixes put it recently where unmanaged
> exceptions were not properly caught and propogated to the VM.  Maybe it
> has something to do with that.  Do your logs provide any insight on what
> was going on at the time of crash?
>
> --oren
>
>   
>> -------- Original Message --------
>> Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
>> From: Rick Lane <ric...@gm...>
>> Date: Tue, May 13, 2008 2:45 pm
>> To: or...@qu...
>> Cc: qui...@li...
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html<hr>Greetings,
>> I brought up an issue 2 months ago where it seemed that my FileStore 
>> might be crashing.  The issue somewhat went away and has now resurfaced 
>> -- I'm no longer convinced this occurred from the FileStore, but I am 
>> fairly convinced this is a QuickFix issue.
>> My trading application is built in C# .NET 2.0, and so I'm using the 
>> quickfix_net and quickfix_net_messages DLLs.  From what I gather about 
>> these DLLs, they are .NET wrappers around the native, unmanaged code.  
>> The crashes I'm seeing are not of the friendly type -- in other words, 
>> they don't give me the option to debug, and they give me no information 
>> (they aren't the "You application has experienced an error and needs to 
>> close" variety).  Rather, they are the "Runtime Error!!!" with the big 
>> red "X" dialogs that signal a hard crash.  I believe this only ever 
>> occurs with unmanaged native code, which tells me (because the quickfix 
>> DLLs are the only such code) that this must be occurring within these 
>> libraries.
>> My application processes /many /messages in a day -- it often processes 
>> more than 1 million messages in any given day (I'm not sure if that's 
>> common or on the high end, but something tells me it's on the high 
>> end).  And so I have a very rapid messaging rate.  What I'm wondering is 
>> if anyone has ever seen these types of "hard" application crashes before 
>> and possibly any remedies or ideas as to what might be causing it. 
>> The absolute worst part about all of this is that Dr Watson dump files 
>> (.dmp) are not being generated.  They were generated the first few times 
>> crashes occurred, but I installed Visual Studio and that, for some 
>> reason, stopped the dump files from being generated.  So I have 
>> absolutely no visibility into this error -- any help is greatly appreciated.
>> Thanks,
>> Rick
>> or...@qu... wrote:
>>     
>>> Never mind.  I can see it's VS8 from your post.  Might be able to do 
>>> something about this by changing the build settings.  I don't think 
>>> it's a coding error.  I'm looking into the microsoft knowledge base 
>>> for possible solutions.
>>>
>>>     -------- Original Message --------
>>>     Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
>>>     From: Rick Lane <ric...@gm...>
>>>     Date: Fri, March 14, 2008 2:41 pm
>>>     To: qui...@li...
>>>     <mailto:qui...@li...>
>>>
>>>     QuickFIX Documentation:
>>>     http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>     QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>>     ------------------------------------------------------------------------
>>>     After some more digging, I'm attempting to load the .dmp file
>>>     generated at the application crash into Visual Studio.  There are
>>>     many entries for quickfix_net.dll (which, as you said, may not
>>>     mean there was a problem with quickfix), but it would be nice to
>>>     be able to load the .pdb file for QuickFix into Visual Studio so I
>>>     can see actual function names instead of just assembly mumbo jumbo.
>>>
>>>     I tried loading both the debug/vs8/quickfix_net.pdb and the
>>>     release/vs8/quickfix_net.pdb and for both it said it "did not
>>>     match the module."  Has anyone tried to load these pdb files into
>>>     studio for debugging purposes?  incidentally, the exception is:
>>>     "Unhandled exception at 0x77e4bee7 in user.dmp: 0xC0020001: The
>>>     string binding is invalid."  I've done some research on this and
>>>     in most cases it seems to occur when people are blending managed
>>>     and unmanaged code.  Outside of QuickFix, I do /not /have any
>>>     unmanaged code -- so is this looking more like it might be a
>>>     native issue (after all, isn't the .NET QuickFix library just a
>>>     wrapper around the unmanaged version?).
>>>
>>>     call stack at crash:
>>>
>>>     >    kernel32.dll!77e4bee7()    
>>>          [Frames below may be incorrect and/or missing, no symbols
>>>     loaded for kernel32.dll]   
>>>          kernel32.dll!77e4bee7()    
>>>          quickfix_net.dll!10084f0c()    
>>>          quickfix_net.dll!100938d5()    
>>>          quickfix_net.dll!10093938()    
>>>
>>>
>>>     or...@qu... <mailto:or...@qu...> wrote:
>>>       
>>>>     I don't know of any outstanding bugs with the filestore.  Do you
>>>>     have any kind of stack trace.  Keep in mind that the
>>>>     quickfix_net.dll will pretty much always show up because events
>>>>     are being passed from quickfix to your application.  So crashes
>>>>     in your application will generally appear to start out in the
>>>>     quickfix dll.  12 MB is pretty big, but not outrageous and I've
>>>>     seen bigger.  None of it is kept in memory, it's only read in as
>>>>     needed for resend requests and such.  Any idea if one was being
>>>>     processed during your crash?
>>>>      
>>>>     --oren
>>>>
>>>>         -------- Original Message --------
>>>>         Subject: [Quickfix-developers] FileStore crashes in .NET?
>>>>         From: Rick Lane <ric...@gm...>
>>>>         Date: Fri, March 14, 2008 11:39 am
>>>>         To: qui...@li...
>>>>         <mailto:qui...@li...>
>>>>
>>>>         QuickFIX Documentation:
>>>>         http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>>         QuickFIX Support: http://www.quickfixengine.org/services.html
>>>>
>>>>         Greetings,
>>>>
>>>>         Have there been any documented instances of QuickFix causing an
>>>>         application crash in .NET related to the FileStore? My
>>>>         application was
>>>>         running along just fine, entering no orders (and with no
>>>>         orders, and
>>>>         therefore no execution reports) for a couple hours after a
>>>>         very busy
>>>>         morning. So for about an hour, the only traffic through QuickFix
>>>>         should've been heartbeats. I received an Application crash --
>>>>         not the
>>>>         good kind, the kind that pretty much doesn't let you do any
>>>>         sort of
>>>>         recovery -- for the first time (I've gotten many crashes due
>>>>         to a null
>>>>         pointer, etc., but these can be caught and therefore
>>>>         recovered from).
>>>>
>>>>         I'm not 100% sure QuickFix caused this -- I'm in the process
>>>>         of thumbing
>>>>         through the memory dump created by Dr Watson (I'm not very
>>>>         good at this)
>>>>         -- but the quickfix_net dll keeps popping up in the log, so I
>>>>         decided to
>>>>         go check out the FileStore file. I was surprised to see it
>>>>         was nearly
>>>>         12 MB (which I guess because of a busy morning, this is to be
>>>>         expected?). This crash could very well have been due to the
>>>>         market data
>>>>         portion of my app (which listens to the CME's FIX/FAST data
>>>>         stream) but
>>>>         I thought I was handling those types of errors better than
>>>>         this, so I
>>>>         just wanted to see if anyone else has seen unexpected crashes
>>>>         w/ the
>>>>         .NET quickfix library, possibly having something to do with
>>>>         the FileStore?
>>>>
>>>>         Thanks in advance,
>>>>         Rick
>>>>
>>>>         -------------------------------------------------------------------------
>>>>         This SF.net <http://SF.net> email is sponsored by: Microsoft
>>>>         Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>         http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>         _______________________________________________
>>>>         Quickfix-developers mailing list
>>>>         Qui...@li...
>>>>         <mailto:Qui...@li...>
>>>>         https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>>
>>>>         
>>>     ------------------------------------------------------------------------
>>>     -------------------------------------------------------------------------
>>>     This SF.net <http://SF.net> email is sponsored by: Microsoft
>>>     Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>     ------------------------------------------------------------------------
>>>     _______________________________________________
>>>     Quickfix-developers mailing list
>>>     Qui...@li... <#Compose>
>>>     https://lists.sourceforge.net/lists/listinfo/quickfix-developers 
>>> <hr>-------------------------------------------------------------------------
>>>       
>> This SF.net email is sponsored by: Microsoft 
>> Defy all challenges. Microsoft(R) Visual Studio 2008. 
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/<hr>_______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>     
>
>   

[Quickfix-developers] Multiple acceptor withing single process

[Nilesh G. <gaj...@gm...>]

Hi

I am working on QF on server side. I am thinking of having two
acceptors runing in a single process space. One to handle the order
request and another to handle the market data request. I have modified
the ordermatch/tradeclient sample to test out if this is possible,
happy know it is working. To run this we need two cfg file: which can
looks like:

I can see the logon and heartbeat message exchanged between
tradeclient and ordermatch.

I would like to know if this is the right approch, any pointed would
be appreciated.


CFG-1
[DEFAULT]
ConnectionType=acceptor
SocketAcceptPort=5001
SocketReuseAddress=Y
FileStorePath=store
FileLogPath=log
StartTime=00:00:00
EndTime=00:00:00
DataDictionary=..\..\..\spec\FIX42.xml

[SESSION]
BeginString=FIX.4.2
SenderCompID=ORDERMATCH
TargetCompID=CLIENT1

[SESSION]
BeginString=FIX.4.2
SenderCompID=ORDERMATCH
TargetCompID=CLIENT2

CFG-2
[DEFAULT]
ConnectionType=acceptor
SocketAcceptPort=5002
SocketReuseAddress=Y
FileStorePath=store
FileLogPath=log
StartTime=00:00:00
EndTime=00:00:00
DataDictionary=..\..\..\spec\FIX42.xml

[SESSION]
BeginString=FIX.4.2
SenderCompID=MRKTDATA
TargetCompID=CLIENT1

[SESSION]
BeginString=FIX.4.2
SenderCompID=MRKTDATA
TargetCompID=CLIENT2

Thanks
-Nilesh

Re: [Quickfix-developers] Could not convert field error

[Manuel L. <lop...@gm...>]

Never mind.  I found the culprit.  It is this line:
EndTime= 21:30:00

The extra blank space after the equals sign was fatal.  This may be a
record for how much how little has cost me.


On Tue, May 13, 2008 at 9:07 PM, Manuel Lopez <lop...@gm...> wrote:
> Thanks for your help.  I'm having some trouble getting QuickFix to
> run.  I get this error using C# 2008 in Visual Studio:
> "QuickFix.ConfigError: Configuration failed: Could not convert field
>   at QuickFix.SocketInitiator..ctor(Application application,
> MessageStoreFactory factory, SessionSettings settings, MessageFactory
> messageFactory)"
>
> Here are the relevant lines (the documentation seems contradictory
> over the parameters to SocketInitiator).
>
>           try
>            {
>                QuickFix.Application qfApp = Qf.GetApp();
>                SessionSettings settings = new SessionSettings(QfSettingsFile);
>                FileStoreFactory factory = new FileStoreFactory(settings);
>                MessageFactory msgFactory = new DefaultMessageFactory();
>                SocketInitiator initiator = new SocketInitiator(qfApp,
> factory, settings, msgFactory);
>                initiator.start();
>                initiator.stop();
>            }
>            catch (ConfigError e)
>            {
>                Debug.WriteLine(e);
>            }
>
> This is the contents of my config file:
>
> [DEFAULT]
> ConnectionType=initiator
> SenderCompID=STEST
> ReconectInterval=60
> MillisecondsInTimeStamp=Y
> SendRedundantResendRequests=Y
> SocketNoDelay=N
> PersistMessages=Y
>
> [SESSION]
> TargetCompID=TTEST
> BeginString=FIX.4.4
> SocketConnectPort=9200
> SocketConnectHost=147.63.150.34
> StartTime=06:00:00
> EndTime= 21:30:00
> ResetOnLogout=N
> ResetOnDisconnect=N
> RefreshOnLogon=N
> UseDataDictionary=Y
> DataDictionary=c:\Users\usr\Autocta\QuickFix\FIX44.xml
> ValidateFieldsOutOfOrder=Y
> ValidateFieldsHaveValues=Y
> ValidateUserDefinedFields=Y
> CheckCompID=Y
> CheckLatency=Y
> MaxLatency=60
> ReconnectInterval=30
> HeartBtInt=20
> FileStorePath=c:\Users\usr\Autocta\QuickFix\LehmanMsg\
> LogonTimeout=30
> LogoutTimeout=10
>

[Quickfix-developers] Could not convert field error

[Manuel L. <lop...@gm...>]

Thanks for your help.  I'm having some trouble getting QuickFix to
run.  I get this error using C# 2008 in Visual Studio:
"QuickFix.ConfigError: Configuration failed: Could not convert field
   at QuickFix.SocketInitiator..ctor(Application application,
MessageStoreFactory factory, SessionSettings settings, MessageFactory
messageFactory)"

Here are the relevant lines (the documentation seems contradictory
over the parameters to SocketInitiator).

           try
            {
                QuickFix.Application qfApp = Qf.GetApp();
                SessionSettings settings = new SessionSettings(QfSettingsFile);
                FileStoreFactory factory = new FileStoreFactory(settings);
                MessageFactory msgFactory = new DefaultMessageFactory();
                SocketInitiator initiator = new SocketInitiator(qfApp,
factory, settings, msgFactory);
                initiator.start();
                initiator.stop();
            }
            catch (ConfigError e)
            {
                Debug.WriteLine(e);
            }

This is the contents of my config file:

[DEFAULT]
ConnectionType=initiator
SenderCompID=STEST
ReconectInterval=60
MillisecondsInTimeStamp=Y
SendRedundantResendRequests=Y
SocketNoDelay=N
PersistMessages=Y

[SESSION]
TargetCompID=TTEST
BeginString=FIX.4.4
SocketConnectPort=9200
SocketConnectHost=147.63.150.34
StartTime=06:00:00
EndTime= 21:30:00
ResetOnLogout=N
ResetOnDisconnect=N
RefreshOnLogon=N
UseDataDictionary=Y
DataDictionary=c:\Users\usr\Autocta\QuickFix\FIX44.xml
ValidateFieldsOutOfOrder=Y
ValidateFieldsHaveValues=Y
ValidateUserDefinedFields=Y
CheckCompID=Y
CheckLatency=Y
MaxLatency=60
ReconnectInterval=30
HeartBtInt=20
FileStorePath=c:\Users\usr\Autocta\QuickFix\LehmanMsg\
LogonTimeout=30
LogoutTimeout=10

Re: [Quickfix-developers] FileStore crashes in .NET?

[Sibte A. <si...@gm...>]

Can it be because of windows file size limits (just guessing)? Do we handle
those in quickfix?

Rick,

Which file system is your FileStore using to store data?

thanks,
-- Sibte

On Tue, May 13, 2008 at 5:10 PM, <or...@qu...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Well, I know there were some fixes put it recently where unmanaged
> exceptions were not properly caught and propogated to the VM.  Maybe it
> has something to do with that.  Do your logs provide any insight on what
> was going on at the time of crash?
>
> --oren
>
> > -------- Original Message --------
> > Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
> > From: Rick Lane <ric...@gm...>
> > Date: Tue, May 13, 2008 2:45 pm
> > To: or...@qu...
> > Cc: qui...@li...
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> <hr>Greetings,
> > I brought up an issue 2 months ago where it seemed that my FileStore
> > might be crashing.  The issue somewhat went away and has now resurfaced
> > -- I'm no longer convinced this occurred from the FileStore, but I am
> > fairly convinced this is a QuickFix issue.
> > My trading application is built in C# .NET 2.0, and so I'm using the
> > quickfix_net and quickfix_net_messages DLLs.  From what I gather about
> > these DLLs, they are .NET wrappers around the native, unmanaged code.
> > The crashes I'm seeing are not of the friendly type -- in other words,
> > they don't give me the option to debug, and they give me no information
> > (they aren't the "You application has experienced an error and needs to
> > close" variety).  Rather, they are the "Runtime Error!!!" with the big
> > red "X" dialogs that signal a hard crash.  I believe this only ever
> > occurs with unmanaged native code, which tells me (because the quickfix
> > DLLs are the only such code) that this must be occurring within these
> > libraries.
> > My application processes /many /messages in a day -- it often processes
> > more than 1 million messages in any given day (I'm not sure if that's
> > common or on the high end, but something tells me it's on the high
> > end).  And so I have a very rapid messaging rate.  What I'm wondering is
> > if anyone has ever seen these types of "hard" application crashes before
> > and possibly any remedies or ideas as to what might be causing it.
> > The absolute worst part about all of this is that Dr Watson dump files
> > (.dmp) are not being generated.  They were generated the first few times
> > crashes occurred, but I installed Visual Studio and that, for some
> > reason, stopped the dump files from being generated.  So I have
> > absolutely no visibility into this error -- any help is greatly
> appreciated.
> > Thanks,
> > Rick
> > or...@qu... wrote:
> > > Never mind.  I can see it's VS8 from your post.  Might be able to do
> > > something about this by changing the build settings.  I don't think
> > > it's a coding error.  I'm looking into the microsoft knowledge base
> > > for possible solutions.
> > >
> > >     -------- Original Message --------
> > >     Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
> > >     From: Rick Lane <ric...@gm...>
> > >     Date: Fri, March 14, 2008 2:41 pm
> > >     To: qui...@li...
> > >     <mailto:qui...@li...>
> > >
> > >     QuickFIX Documentation:
> > >     http://www.quickfixengine.org/quickfix/doc/html/index.html
> > >     QuickFIX Support: http://www.quickfixengine.org/services.html
> > >
> > >
> ------------------------------------------------------------------------
> > >     After some more digging, I'm attempting to load the .dmp file
> > >     generated at the application crash into Visual Studio.  There are
> > >     many entries for quickfix_net.dll (which, as you said, may not
> > >     mean there was a problem with quickfix), but it would be nice to
> > >     be able to load the .pdb file for QuickFix into Visual Studio so I
> > >     can see actual function names instead of just assembly mumbo
> jumbo.
> > >
> > >     I tried loading both the debug/vs8/quickfix_net.pdb and the
> > >     release/vs8/quickfix_net.pdb and for both it said it "did not
> > >     match the module."  Has anyone tried to load these pdb files into
> > >     studio for debugging purposes?  incidentally, the exception is:
> > >     "Unhandled exception at 0x77e4bee7 in user.dmp: 0xC0020001: The
> > >     string binding is invalid."  I've done some research on this and
> > >     in most cases it seems to occur when people are blending managed
> > >     and unmanaged code.  Outside of QuickFix, I do /not /have any
> > >     unmanaged code -- so is this looking more like it might be a
> > >     native issue (after all, isn't the .NET QuickFix library just a
> > >     wrapper around the unmanaged version?).
> > >
> > >     call stack at crash:
> > >
> > >     >    kernel32.dll!77e4bee7()
> > >          [Frames below may be incorrect and/or missing, no symbols
> > >     loaded for kernel32.dll]
> > >          kernel32.dll!77e4bee7()
> > >          quickfix_net.dll!10084f0c()
> > >          quickfix_net.dll!100938d5()
> > >          quickfix_net.dll!10093938()
> > >
> > >
> > >     or...@qu... <mailto:or...@qu...> wrote:
> > >>     I don't know of any outstanding bugs with the filestore.  Do you
> > >>     have any kind of stack trace.  Keep in mind that the
> > >>     quickfix_net.dll will pretty much always show up because events
> > >>     are being passed from quickfix to your application.  So crashes
> > >>     in your application will generally appear to start out in the
> > >>     quickfix dll.  12 MB is pretty big, but not outrageous and I've
> > >>     seen bigger.  None of it is kept in memory, it's only read in as
> > >>     needed for resend requests and such.  Any idea if one was being
> > >>     processed during your crash?
> > >>
> > >>     --oren
> > >>
> > >>         -------- Original Message --------
> > >>         Subject: [Quickfix-developers] FileStore crashes in .NET?
> > >>         From: Rick Lane <ric...@gm...>
> > >>         Date: Fri, March 14, 2008 11:39 am
> > >>         To: qui...@li...
> > >>         <mailto:qui...@li...>
> > >>
> > >>         QuickFIX Documentation:
> > >>         http://www.quickfixengine.org/quickfix/doc/html/index.html
> > >>         QuickFIX Support: http://www.quickfixengine.org/services.html
> > >>
> > >>         Greetings,
> > >>
> > >>         Have there been any documented instances of QuickFix causing
> an
> > >>         application crash in .NET related to the FileStore? My
> > >>         application was
> > >>         running along just fine, entering no orders (and with no
> > >>         orders, and
> > >>         therefore no execution reports) for a couple hours after a
> > >>         very busy
> > >>         morning. So for about an hour, the only traffic through
> QuickFix
> > >>         should've been heartbeats. I received an Application crash --
> > >>         not the
> > >>         good kind, the kind that pretty much doesn't let you do any
> > >>         sort of
> > >>         recovery -- for the first time (I've gotten many crashes due
> > >>         to a null
> > >>         pointer, etc., but these can be caught and therefore
> > >>         recovered from).
> > >>
> > >>         I'm not 100% sure QuickFix caused this -- I'm in the process
> > >>         of thumbing
> > >>         through the memory dump created by Dr Watson (I'm not very
> > >>         good at this)
> > >>         -- but the quickfix_net dll keeps popping up in the log, so I
> > >>         decided to
> > >>         go check out the FileStore file. I was surprised to see it
> > >>         was nearly
> > >>         12 MB (which I guess because of a busy morning, this is to be
> > >>         expected?). This crash could very well have been due to the
> > >>         market data
> > >>         portion of my app (which listens to the CME's FIX/FAST data
> > >>         stream) but
> > >>         I thought I was handling those types of errors better than
> > >>         this, so I
> > >>         just wanted to see if anyone else has seen unexpected crashes
> > >>         w/ the
> > >>         .NET quickfix library, possibly having something to do with
> > >>         the FileStore?
> > >>
> > >>         Thanks in advance,
> > >>         Rick
> > >>
> > >>
> -------------------------------------------------------------------------
> > >>         This SF.net <http://SF.net> email is sponsored by: Microsoft
> > >>         Defy all challenges. Microsoft(R) Visual Studio 2008.
> > >>         http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > >>         _______________________________________________
> > >>         Quickfix-developers mailing list
> > >>         Qui...@li...
> > >>         <mailto:Qui...@li...>
> > >>
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > >>
> > >
> ------------------------------------------------------------------------
> > >
> -------------------------------------------------------------------------
> > >     This SF.net <http://SF.net> email is sponsored by: Microsoft
> > >     Defy all challenges. Microsoft(R) Visual Studio 2008.
> > >     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > >
> ------------------------------------------------------------------------
> > >     _______________________________________________
> > >     Quickfix-developers mailing list
> > >     Qui...@li... <#Compose>
> > >     https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
> ><hr>-------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> <hr>_______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] FileStore crashes in .NET?

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

Well, I know there were some fixes put it recently where unmanaged
exceptions were not properly caught and propogated to the VM.  Maybe it
has something to do with that.  Do your logs provide any insight on what
was going on at the time of crash?

--oren

> -------- Original Message --------
> Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
> From: Rick Lane <ric...@gm...>
> Date: Tue, May 13, 2008 2:45 pm
> To: or...@qu...
> Cc: qui...@li...
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html<hr>Greetings,
> I brought up an issue 2 months ago where it seemed that my FileStore 
> might be crashing.  The issue somewhat went away and has now resurfaced 
> -- I'm no longer convinced this occurred from the FileStore, but I am 
> fairly convinced this is a QuickFix issue.
> My trading application is built in C# .NET 2.0, and so I'm using the 
> quickfix_net and quickfix_net_messages DLLs.  From what I gather about 
> these DLLs, they are .NET wrappers around the native, unmanaged code.  
> The crashes I'm seeing are not of the friendly type -- in other words, 
> they don't give me the option to debug, and they give me no information 
> (they aren't the "You application has experienced an error and needs to 
> close" variety).  Rather, they are the "Runtime Error!!!" with the big 
> red "X" dialogs that signal a hard crash.  I believe this only ever 
> occurs with unmanaged native code, which tells me (because the quickfix 
> DLLs are the only such code) that this must be occurring within these 
> libraries.
> My application processes /many /messages in a day -- it often processes 
> more than 1 million messages in any given day (I'm not sure if that's 
> common or on the high end, but something tells me it's on the high 
> end).  And so I have a very rapid messaging rate.  What I'm wondering is 
> if anyone has ever seen these types of "hard" application crashes before 
> and possibly any remedies or ideas as to what might be causing it. 
> The absolute worst part about all of this is that Dr Watson dump files 
> (.dmp) are not being generated.  They were generated the first few times 
> crashes occurred, but I installed Visual Studio and that, for some 
> reason, stopped the dump files from being generated.  So I have 
> absolutely no visibility into this error -- any help is greatly appreciated.
> Thanks,
> Rick
> or...@qu... wrote:
> > Never mind.  I can see it's VS8 from your post.  Might be able to do 
> > something about this by changing the build settings.  I don't think 
> > it's a coding error.  I'm looking into the microsoft knowledge base 
> > for possible solutions.
> >
> >     -------- Original Message --------
> >     Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
> >     From: Rick Lane <ric...@gm...>
> >     Date: Fri, March 14, 2008 2:41 pm
> >     To: qui...@li...
> >     <mailto:qui...@li...>
> >
> >     QuickFIX Documentation:
> >     http://www.quickfixengine.org/quickfix/doc/html/index.html
> >     QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> >     ------------------------------------------------------------------------
> >     After some more digging, I'm attempting to load the .dmp file
> >     generated at the application crash into Visual Studio.  There are
> >     many entries for quickfix_net.dll (which, as you said, may not
> >     mean there was a problem with quickfix), but it would be nice to
> >     be able to load the .pdb file for QuickFix into Visual Studio so I
> >     can see actual function names instead of just assembly mumbo jumbo.
> >
> >     I tried loading both the debug/vs8/quickfix_net.pdb and the
> >     release/vs8/quickfix_net.pdb and for both it said it "did not
> >     match the module."  Has anyone tried to load these pdb files into
> >     studio for debugging purposes?  incidentally, the exception is:
> >     "Unhandled exception at 0x77e4bee7 in user.dmp: 0xC0020001: The
> >     string binding is invalid."  I've done some research on this and
> >     in most cases it seems to occur when people are blending managed
> >     and unmanaged code.  Outside of QuickFix, I do /not /have any
> >     unmanaged code -- so is this looking more like it might be a
> >     native issue (after all, isn't the .NET QuickFix library just a
> >     wrapper around the unmanaged version?).
> >
> >     call stack at crash:
> >
> >     >    kernel32.dll!77e4bee7()    
> >          [Frames below may be incorrect and/or missing, no symbols
> >     loaded for kernel32.dll]   
> >          kernel32.dll!77e4bee7()    
> >          quickfix_net.dll!10084f0c()    
> >          quickfix_net.dll!100938d5()    
> >          quickfix_net.dll!10093938()    
> >
> >
> >     or...@qu... <mailto:or...@qu...> wrote:
> >>     I don't know of any outstanding bugs with the filestore.  Do you
> >>     have any kind of stack trace.  Keep in mind that the
> >>     quickfix_net.dll will pretty much always show up because events
> >>     are being passed from quickfix to your application.  So crashes
> >>     in your application will generally appear to start out in the
> >>     quickfix dll.  12 MB is pretty big, but not outrageous and I've
> >>     seen bigger.  None of it is kept in memory, it's only read in as
> >>     needed for resend requests and such.  Any idea if one was being
> >>     processed during your crash?
> >>      
> >>     --oren
> >>
> >>         -------- Original Message --------
> >>         Subject: [Quickfix-developers] FileStore crashes in .NET?
> >>         From: Rick Lane <ric...@gm...>
> >>         Date: Fri, March 14, 2008 11:39 am
> >>         To: qui...@li...
> >>         <mailto:qui...@li...>
> >>
> >>         QuickFIX Documentation:
> >>         http://www.quickfixengine.org/quickfix/doc/html/index.html
> >>         QuickFIX Support: http://www.quickfixengine.org/services.html
> >>
> >>         Greetings,
> >>
> >>         Have there been any documented instances of QuickFix causing an
> >>         application crash in .NET related to the FileStore? My
> >>         application was
> >>         running along just fine, entering no orders (and with no
> >>         orders, and
> >>         therefore no execution reports) for a couple hours after a
> >>         very busy
> >>         morning. So for about an hour, the only traffic through QuickFix
> >>         should've been heartbeats. I received an Application crash --
> >>         not the
> >>         good kind, the kind that pretty much doesn't let you do any
> >>         sort of
> >>         recovery -- for the first time (I've gotten many crashes due
> >>         to a null
> >>         pointer, etc., but these can be caught and therefore
> >>         recovered from).
> >>
> >>         I'm not 100% sure QuickFix caused this -- I'm in the process
> >>         of thumbing
> >>         through the memory dump created by Dr Watson (I'm not very
> >>         good at this)
> >>         -- but the quickfix_net dll keeps popping up in the log, so I
> >>         decided to
> >>         go check out the FileStore file. I was surprised to see it
> >>         was nearly
> >>         12 MB (which I guess because of a busy morning, this is to be
> >>         expected?). This crash could very well have been due to the
> >>         market data
> >>         portion of my app (which listens to the CME's FIX/FAST data
> >>         stream) but
> >>         I thought I was handling those types of errors better than
> >>         this, so I
> >>         just wanted to see if anyone else has seen unexpected crashes
> >>         w/ the
> >>         .NET quickfix library, possibly having something to do with
> >>         the FileStore?
> >>
> >>         Thanks in advance,
> >>         Rick
> >>
> >>         -------------------------------------------------------------------------
> >>         This SF.net <http://SF.net> email is sponsored by: Microsoft
> >>         Defy all challenges. Microsoft(R) Visual Studio 2008.
> >>         http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >>         _______________________________________________
> >>         Quickfix-developers mailing list
> >>         Qui...@li...
> >>         <mailto:Qui...@li...>
> >>         https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >>
> >     ------------------------------------------------------------------------
> >     -------------------------------------------------------------------------
> >     This SF.net <http://SF.net> email is sponsored by: Microsoft
> >     Defy all challenges. Microsoft(R) Visual Studio 2008.
> >     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >     ------------------------------------------------------------------------
> >     _______________________________________________
> >     Quickfix-developers mailing list
> >     Qui...@li... <#Compose>
> >     https://lists.sourceforge.net/lists/listinfo/quickfix-developers 
> ><hr>-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/<hr>_______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Thread safety question

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

Not a problem.  QuickFIX protects the session with a mutex so you can
call sendToTarget without worry from any thread.

--oren

> -------- Original Message --------
> Subject: [Quickfix-developers] Thread safety question
> From: John Haldi <jr...@ya...>
> Date: Tue, May 13, 2008 1:34 pm
> To: qui...@li...
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html<hr>I was wondering if anybody might be able to answer the following:
> I'm creating a client trading application which takes advantage of the ThreadedSocketInitiator to make a connection to an exchange.  (I do not currently use the SynchrozinedApplication, if that makes a difference to my question.)  In my trading application, I want to be able to react to an ExecutionReport of type Fill or Partial fill in a particular ETF by responding with a hedge that is comprised of a collection of NewOrderSingle messages.  In other words, I want to send out a basket of orders each time I get a fill.
> In the simplest scenario, I might get a fill for a particular ETF and want to send out 10 buy orders (ten NewOrderSingle messages, one for each different stock in the basket).  So far this application tests without a problem.  To send the basket of orders, I'm grabbing a thread from the threadpool (.NET application, fyi), and generating my orders on that thread and calling SendToTarget for each order I create.  After creating and sending the basket, the thread is returned to the thread pool.  In this manner, I allow my trading client to return from the "CreateBasketOrders" call on the primary thread while the basket itself is created and sent out.
> Here's the part I'm concerned with though.  Imagine a very common scenario in which an order to buy 5,000 shares of a particular ETF comes back in a handful of partial fills in very fast succession (say, for example, 100 share fills, each 2-3 ms apart).  Now imagine that my thread that generates the basket takes 50 ms to actually complete (imagine that I'm sending a basket on the S&P 500, so my basket has 500 NewOrderSingles to create and send).
> If I get 10 fills in rapid fire succession, I will create 10 concurrent threads (from the threadpool) which are each creating some #n of NewOrderSingles and each calling SendToTarget concurrently.  Will quickfix handle the calls to SendToTarget from multiple threads gracefully, or do I have to manage some sort of locking mechanism to ensure that SendToTarget can't be called concurrently by different threads at the same time?  If QF can handle this internally, great.  If not, would it work to create a wrapper function in my app (called perhaps "ThreadSafeSendToTarget") which wraps the SendToTarget method with a ReaderWriterLock object and prevents concurrent calls?
> Any advice would be greatly appreciated.
> Many thanks,
>    John<hr>-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/<hr>_______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] FileStore crashes in .NET?

[Dale W. <wil...@oc...>]

Rick Lane wrote:
> The absolute worst part about all of this is that Dr Watson dump files 
> (.dmp) are not being generated.  They were generated the first few 
> times crashes occurred, but I installed Visual Studio and that, for 
> some reason, stopped the dump files from being generated.  So I have 
> absolutely no visibility into this error -- any help is greatly 
> appreciated.
You might try to see if you can run the application in the debugger all 
day long.  This may cause performance problems given your heavy load, 
but if it doesn't the debugger should catch the failure that is shutting 
you down and give you a chance to diagnose the problem.   In fact, when 
the problem occurs you will probably be able to bring up a new copy of 
the application and finish the trading day -- leaving the failed copy 
hanging in the debugger waiting for your after-hours attention.

Sounds like a nasty one.  Good luck,

Dale

Re: [Quickfix-developers] FileStore crashes in .NET?

[Rick L. <ric...@gm...>]

Greetings,

I brought up an issue 2 months ago where it seemed that my FileStore 
might be crashing.  The issue somewhat went away and has now resurfaced 
-- I'm no longer convinced this occurred from the FileStore, but I am 
fairly convinced this is a QuickFix issue.

My trading application is built in C# .NET 2.0, and so I'm using the 
quickfix_net and quickfix_net_messages DLLs.  From what I gather about 
these DLLs, they are .NET wrappers around the native, unmanaged code.  
The crashes I'm seeing are not of the friendly type -- in other words, 
they don't give me the option to debug, and they give me no information 
(they aren't the "You application has experienced an error and needs to 
close" variety).  Rather, they are the "Runtime Error!!!" with the big 
red "X" dialogs that signal a hard crash.  I believe this only ever 
occurs with unmanaged native code, which tells me (because the quickfix 
DLLs are the only such code) that this must be occurring within these 
libraries.

My application processes /many /messages in a day -- it often processes 
more than 1 million messages in any given day (I'm not sure if that's 
common or on the high end, but something tells me it's on the high 
end).  And so I have a very rapid messaging rate.  What I'm wondering is 
if anyone has ever seen these types of "hard" application crashes before 
and possibly any remedies or ideas as to what might be causing it. 

The absolute worst part about all of this is that Dr Watson dump files 
(.dmp) are not being generated.  They were generated the first few times 
crashes occurred, but I installed Visual Studio and that, for some 
reason, stopped the dump files from being generated.  So I have 
absolutely no visibility into this error -- any help is greatly appreciated.

Thanks,
Rick

or...@qu... wrote:
> Never mind.  I can see it's VS8 from your post.  Might be able to do 
> something about this by changing the build settings.  I don't think 
> it's a coding error.  I'm looking into the microsoft knowledge base 
> for possible solutions.
>
>     -------- Original Message --------
>     Subject: Re: [Quickfix-developers] FileStore crashes in .NET?
>     From: Rick Lane <ric...@gm...>
>     Date: Fri, March 14, 2008 2:41 pm
>     To: qui...@li...
>     <mailto:qui...@li...>
>
>     QuickFIX Documentation:
>     http://www.quickfixengine.org/quickfix/doc/html/index.html
>     QuickFIX Support: http://www.quickfixengine.org/services.html
>
>     ------------------------------------------------------------------------
>     After some more digging, I'm attempting to load the .dmp file
>     generated at the application crash into Visual Studio.  There are
>     many entries for quickfix_net.dll (which, as you said, may not
>     mean there was a problem with quickfix), but it would be nice to
>     be able to load the .pdb file for QuickFix into Visual Studio so I
>     can see actual function names instead of just assembly mumbo jumbo.
>
>     I tried loading both the debug/vs8/quickfix_net.pdb and the
>     release/vs8/quickfix_net.pdb and for both it said it "did not
>     match the module."  Has anyone tried to load these pdb files into
>     studio for debugging purposes?  incidentally, the exception is:
>     "Unhandled exception at 0x77e4bee7 in user.dmp: 0xC0020001: The
>     string binding is invalid."  I've done some research on this and
>     in most cases it seems to occur when people are blending managed
>     and unmanaged code.  Outside of QuickFix, I do /not /have any
>     unmanaged code -- so is this looking more like it might be a
>     native issue (after all, isn't the .NET QuickFix library just a
>     wrapper around the unmanaged version?).
>
>     call stack at crash:
>
>     >    kernel32.dll!77e4bee7()    
>          [Frames below may be incorrect and/or missing, no symbols
>     loaded for kernel32.dll]   
>          kernel32.dll!77e4bee7()    
>          quickfix_net.dll!10084f0c()    
>          quickfix_net.dll!100938d5()    
>          quickfix_net.dll!10093938()    
>
>
>     or...@qu... <mailto:or...@qu...> wrote:
>>     I don't know of any outstanding bugs with the filestore.  Do you
>>     have any kind of stack trace.  Keep in mind that the
>>     quickfix_net.dll will pretty much always show up because events
>>     are being passed from quickfix to your application.  So crashes
>>     in your application will generally appear to start out in the
>>     quickfix dll.  12 MB is pretty big, but not outrageous and I've
>>     seen bigger.  None of it is kept in memory, it's only read in as
>>     needed for resend requests and such.  Any idea if one was being
>>     processed during your crash?
>>      
>>     --oren
>>
>>         -------- Original Message --------
>>         Subject: [Quickfix-developers] FileStore crashes in .NET?
>>         From: Rick Lane <ric...@gm...>
>>         Date: Fri, March 14, 2008 11:39 am
>>         To: qui...@li...
>>         <mailto:qui...@li...>
>>
>>         QuickFIX Documentation:
>>         http://www.quickfixengine.org/quickfix/doc/html/index.html
>>         QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>         Greetings,
>>
>>         Have there been any documented instances of QuickFix causing an
>>         application crash in .NET related to the FileStore? My
>>         application was
>>         running along just fine, entering no orders (and with no
>>         orders, and
>>         therefore no execution reports) for a couple hours after a
>>         very busy
>>         morning. So for about an hour, the only traffic through QuickFix
>>         should've been heartbeats. I received an Application crash --
>>         not the
>>         good kind, the kind that pretty much doesn't let you do any
>>         sort of
>>         recovery -- for the first time (I've gotten many crashes due
>>         to a null
>>         pointer, etc., but these can be caught and therefore
>>         recovered from).
>>
>>         I'm not 100% sure QuickFix caused this -- I'm in the process
>>         of thumbing
>>         through the memory dump created by Dr Watson (I'm not very
>>         good at this)
>>         -- but the quickfix_net dll keeps popping up in the log, so I
>>         decided to
>>         go check out the FileStore file. I was surprised to see it
>>         was nearly
>>         12 MB (which I guess because of a busy morning, this is to be
>>         expected?). This crash could very well have been due to the
>>         market data
>>         portion of my app (which listens to the CME's FIX/FAST data
>>         stream) but
>>         I thought I was handling those types of errors better than
>>         this, so I
>>         just wanted to see if anyone else has seen unexpected crashes
>>         w/ the
>>         .NET quickfix library, possibly having something to do with
>>         the FileStore?
>>
>>         Thanks in advance,
>>         Rick
>>
>>         -------------------------------------------------------------------------
>>         This SF.net <http://SF.net> email is sponsored by: Microsoft
>>         Defy all challenges. Microsoft(R) Visual Studio 2008.
>>         http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>         _______________________________________________
>>         Quickfix-developers mailing list
>>         Qui...@li...
>>         <mailto:Qui...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>     ------------------------------------------------------------------------
>     -------------------------------------------------------------------------
>     This SF.net <http://SF.net> email is sponsored by: Microsoft
>     Defy all challenges. Microsoft(R) Visual Studio 2008.
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     ------------------------------------------------------------------------
>     _______________________________________________
>     Quickfix-developers mailing list
>     Qui...@li... <#Compose>
>     https://lists.sourceforge.net/lists/listinfo/quickfix-developers 
>

[Quickfix-developers] Thread safety question

[John H. <jr...@ya...>]

I was wondering if anybody might be able to answer the following:

I'm creating a client trading application which takes advantage of the ThreadedSocketInitiator to make a connection to an exchange.  (I do not currently use the SynchrozinedApplication, if that makes a difference to my question.)  In my trading application, I want to be able to react to an ExecutionReport of type Fill or Partial fill in a particular ETF by responding with a hedge that is comprised of a collection of NewOrderSingle messages.  In other words, I want to send out a basket of orders each time I get a fill.

In the simplest scenario, I might get a fill for a particular ETF and want to send out 10 buy orders (ten NewOrderSingle messages, one for each different stock in the basket).  So far this application tests without a problem.  To send the basket of orders, I'm grabbing a thread from the threadpool (.NET application, fyi), and generating my orders on that thread and calling SendToTarget for each order I create.  After creating and sending the basket, the thread is returned to the thread pool.  In this manner, I allow my trading client to return from the "CreateBasketOrders" call on the primary thread while the basket itself is created and sent out.

Here's the part I'm concerned with though.  Imagine a very common scenario in which an order to buy 5,000 shares of a particular ETF comes back in a handful of partial fills in very fast succession (say, for example, 100 share fills, each 2-3 ms apart).  Now imagine that my thread that generates the basket takes 50 ms to actually complete (imagine that I'm sending a basket on the S&P 500, so my basket has 500 NewOrderSingles to create and send).

If I get 10 fills in rapid fire succession, I will create 10 concurrent threads (from the threadpool) which are each creating some #n of NewOrderSingles and each calling SendToTarget concurrently.  Will quickfix handle the calls to SendToTarget from multiple threads gracefully, or do I have to manage some sort of locking mechanism to ensure that SendToTarget can't be called concurrently by different threads at the same time?  If QF can handle this internally, great.  If not, would it work to create a wrapper function in my app (called perhaps "ThreadSafeSendToTarget") which wraps the SendToTarget method with a ReaderWriterLock object and prevents concurrent calls?

Any advice would be greatly appreciated.

Many thanks,

   John

[Quickfix-developers] Proposal for automated backups/Log rotation

[Sibte A. <si...@gm...>]

The attached patch is a proto type implementation of Automated backups or
Implicit Log rotation in quickfix. Putting up for feedback and comments.

The basic idea is pretty simple and conventional;

LogRotater thread:
===========

As you might have expected, there is a thread called LogRotater which runs
at the application level scope i.e one for each quickfix engine instance.
And its job is to check the sizes of the log files for each Session. When
the file size reaches a certain limit, it initiates a request for backup.

The LogRotater thread contains a pool of FileLog pointers, which it
sequentially scans in a round robin fashion.

Registration:
========

Sessions are responsible for registering their respective FileLog objects
(if any) to the LogRotater. Registeration is done via the LogRotater::add()
routine. When terminating the Session has to unregister itself via the
LogRotater::remove() routine.

Backup
=====

The backup is performed by simply invoking the FileLog::backup() function,
recently implemented by Oren.

Issues
====
Although both the unit and acceptance tests produce zero (0) failures,
however this is just a proof of concept implementation which may contain
bugs, design flaws and performance bottlenecks. Besides ordinary code
quality, there are alot of things which I have ignored for now, for example
I have not employed the CallStack API. Also at some places instead of
issuing a blocking call to acquire mutex, it would have been more efficient
to use non-blocking attempts to acquire mutexes.

All these issues, plus the additional gotchas which will be uncovered by the
group's feedback would be taken care of in the following version(s) of this
patch.

While reviewing you can ignore anything that comes under #ifdef INS. These
are just debug messages which I was using for my own testing.

ANY types of Comments are graciously welcomed!

thanks,
-- Sibte

Re: [Quickfix-developers] Disconnection on placing order

[Mike G. <mg...@co...>]

Eranga Samararathne wrote:
> SenderCompID = AAA
> TargetCompIdD = BBB

Additionally, make sure that BeginString is set to the correct FIX version.


-- 
Mike Gatny
Connamara Systems, LLC
http://www.connamara.com/

Re: [Quickfix-developers] Disconnection on placing order

[Eranga S. <PE...@ri...>]

Hello,

Make sure your session configuration informations are correct. Specially SenderCompID and TargetCompIdD in both counter parties.

Eg:

If initiator 

SenderCompID = AAA
TargetCompIdD = BBB

then acceptor

SenderCompID = BBB
TargetCompIdD = AAA

Eranga.

-----Original Message-----
From: Srinath Kamath [mailto:sri...@gm...]
Sent: Fri 5/9/2008 12:37 PM
To: qui...@li...
Subject: [Quickfix-developers] Disconnection on placing order
 
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

[Quickfix-developers] Disconnection on placing order

[Srinath K. <sri...@gm...>]

Hi,
   i have done one initiator implementation in vb.net using QuickFix. i am
able to connect to acceptor and exchange heartbeat messages.
   The problem is as soon as i try to place any order, the my
initiator sends out the logout request and i get Session Not Found
exception. What could be the reason ?

Thanks in advance.
Srinath

Re: [Quickfix-developers] possible deadlocking/freeze with routing implementation ?

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

SynchronizedApplication probably isn't the best thing to use in a
scenario like this.  You should probably lock only the resources that
need protecting and release the locks when you no longer need them.  You
are probably deadlocking between the synchronized application mutex and
the session mutex when sending an order.  Unlocking the application
mutex before making the send call will probably resolve your problem.

--oren

> -------- Original Message --------
> Subject: [Quickfix-developers] possible deadlocking/freeze with routing
> implementation ?
> From: quickfixer <li...@ch...>
> Date: Tue, May 06, 2008 6:32 pm
> To: qui...@li...
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> Hi, 
>   I've been using quickfix for about three months in a routing kind of
> situation (similar to this poster:
> http://www.nabble.com/ThreadedSocketAcceptor---Message-resend-tc17067577.html)
> where I have both an initiator and an acceptor.  I am using
> ThreadedSocketAcceptor, ThreadedSocketInitator, and SynchronizedApplication. 
> There are n sessions coming in through the acceptor and 1 out via the
> initiator, and it is a comparitively low message throughput application.  
>   We experienced a situation today where quickfix tried to send a message to
> its outgoing connection, while processing a message received from on of
> incoming connections, somewhere in Session::sendToTarget my quickfix server
> got "stuck" (i.e. I know I called ::sendToTarget, but I never got to the
> part where the message was actually sent, as I did not see the offending
> message in the filestore (am using the FileStoreFactory)).  I am inclined to 
> believe this is a deadlocking situation  but I am not sure on what resource
> I am deadlocking and which are the two (or more!) threads that are
> contending for the resource.  During this period of time (it was about 5
> minutes before someone noticed - as I said "low volume"!), several clients
> timed out because they failed to receive heartbeat responses, and began the
> reconnect process.  For each of these clients I see the incoming heartbeat
> in the individual message store for each client and then later the following
> in the global log: 
> "Accepted connection from x.x.x.x on port yyyy"
> but there is no corresponding response from my server to neither the
> heartbeat nor the new connection, presumably because those messages are
> queued up waiting for the thread to finish processing the original
> sendToTarget which is "stuck". I cannot however, figure out why the original
> sendToTarget is "stuck" nor if it is deadlocked what it is waiting on.  
>   The quickfix server was bounced, and everybody recovered and the offending
> message was resent, and so everything was fine in the end, but I was
> wondering if someone could help to figure out what I am doing in the code
> that caused this errant issue.  Any thoughts, or pointers as to where to
> look for a possible issue would be _much_ appreciated.  
> Regards,
> Liz
> -- 
> View this message in context: http://www.nabble.com/possible-deadlocking-freeze-with-routing-implementation---tp17093661p17093661.html
> Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] possible deadlocking/freeze with routingimplementation?

[Mark T. K. <mke...@di...>]

a per-thread stack trace of the deadlocked instance would be interesting to
see.  /mark

quickfixer wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> 
> Hi, 
> 
>   I've been using quickfix for about three months in a routing kind of
> situation (similar to this poster:
> http://www.nabble.com/ThreadedSocketAcceptor---Message-resend-tc17067577.html)
> where I have both an initiator and an acceptor.  I am using
> ThreadedSocketAcceptor, ThreadedSocketInitator, and SynchronizedApplication. 
> There are n sessions coming in through the acceptor and 1 out via the
> initiator, and it is a comparitively low message throughput application.  
> 
>   We experienced a situation today where quickfix tried to send a message to
> its outgoing connection, while processing a message received from on of
> incoming connections, somewhere in Session::sendToTarget my quickfix server
> got "stuck" (i.e. I know I called ::sendToTarget, but I never got to the
> part where the message was actually sent, as I did not see the offending
> message in the filestore (am using the FileStoreFactory)).  I am inclined to 
> believe this is a deadlocking situation  but I am not sure on what resource
> I am deadlocking and which are the two (or more!) threads that are
> contending for the resource.  During this period of time (it was about 5
> minutes before someone noticed - as I said "low volume"!), several clients
> timed out because they failed to receive heartbeat responses, and began the
> reconnect process.  For each of these clients I see the incoming heartbeat
> in the individual message store for each client and then later the following
> in the global log: 
> "Accepted connection from x.x.x.x on port yyyy"
> but there is no corresponding response from my server to neither the
> heartbeat nor the new connection, presumably because those messages are
> queued up waiting for the thread to finish processing the original
> sendToTarget which is "stuck". I cannot however, figure out why the original
> sendToTarget is "stuck" nor if it is deadlocked what it is waiting on.  
> 
>   The quickfix server was bounced, and everybody recovered and the offending
> message was resent, and so everything was fine in the end, but I was
> wondering if someone could help to figure out what I am doing in the code
> that caused this errant issue.  Any thoughts, or pointers as to where to
> look for a possible issue would be _much_ appreciated.  
> 
> Regards,
> Liz

This communication and any attachments may contain confidential/proprietary information and is intended for information purposes only. It is not an invitation or offer to purchase interests from Diamondback.  Any representation to the contrary is unintentional.  This communication is intended only for the person(s) to whom it is addressed.  If you are not the intended recipient you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message or any attachments is not permitted.  If you have received this in error, please notify the sender immediately by e-mail and delete this message.  All e-mails sent to or received from this address will be received by Diamondback's company e-mail system and is subject to archival and possible review by someone other than the recipient.  This notice is automatically appended to each e-mail message leaving Diamondback.

Re: [Quickfix-developers] MsgType = AS, AllocationReport, Fix44

[mr a. <mr...@gm...>]

Oren-

Thanks for your input.  I fixed the other two error messages I was
receiving.  I'm not sure I quite understand the error I am getting from tag
14 (the one below).  Is it because msgtype=AS doesn't support tag 14?  How
would I adjust the data dictionay file to match their spec (to expect tag 14
for any AS message types?)

thanks!
azmat

On Tue, May 6, 2008 at 5:00 PM, <or...@qu...> wrote:

>

The other one is because tag 14 is being put in the message when it isn't
> defined as a member.  Any idea
> why you are getting messages like this?  You may need to adjust your data
> dictionary file to their spec.
>
> --oren
>

Re: [Quickfix-developers] Daily Sequence Number Resets?

[ARORA, A. I. <Atu...@rb...>]

Thanks for the reply Shane.

I believe the config setting you sent will enable me to have week long session. May be I was not clear in what I was asking.

I am working on the post trade feed from a FIX based acceptor and have a requirement of maintaining 24 hrs connectivity. I need to reset the sequence numbers when the trade date gets rolled over and from this point onwards previous day's trades are [or shall] not be available.

On top of it if there is a disconnection in the middle of the day I need to request back all the trades since the start of the day.

Hence, what I do
1. Once in a day I "force" the session re-set by sending nextTargetMsgSeqNum=1, nextSenderMsgSeq=1,ResetSeqNumFlag=true and MsgSeqNum=1 in the first logon after the trade date gets rolled over. Which is between 23:30:00 [StartTime] which sets up brand new session with previous trading day's trades not available.

2. In case there is a disconnection in the middle of the trading day I log back in sending nextTargetMsgSeqNum=1. This re-sends me all the trades since the start of the trading day as per my requirements.

Though I am able keep connectivity open 24 hrs but would like to give it a pause over the weekend. If I put in StartDay and EndDay along with the StartTime and EndTime the day-to-day session re-set stops to happen. I need day-to-day session plus the processing needs to stopped over the weekend.

Regds
Atul


-----Original Message-----
From: Shane Trotter [mailto:str...@co...]
Sent: Tuesday, May 06, 2008 3:10 PM
To: ARORA, Atul, IDC
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Daily Sequence Number Resets?

Atul,

This session would be set in the config file as follows:

StartDay=mon
EndDay=fri
# Note that StartTime and EndTime must be specified in GMT StartTime=00:30:00 EndTime=06:00:00

On Mon, May 5, 2008 at 10:39 PM, atularora78 <atu...@rb...> wrote:
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
>  QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>  Hi Shane,
>
>  What about for not having a session working over the weekend ? I mean
> dis-connecting after the end of trading day on Friday say 6PM I want
> to  start my session again on Monday 00:30 Hrs.
>
>  Note: I am maintaining 24 hrs connectivity to acceptor.
>
>  Thanks in advance.
>
>  Regds
>  Atul
>
>
>
>
>
>  Shane Trotter wrote:
>  >
>  > QuickFIX Documentation:
>  > http://www.quickfixengine.org/quickfix/doc/html/index.html
>  > QuickFIX Support: http://www.quickfixengine.org/services.html
>  >
>  > Yes,  remove StartDay/EndDay as you will be using daily sessions.
>  >
>  > Set StartTime and EndTime to your normal daily session (But note
> that  > you must use UTC time) and it will reset daily.
>  >
>  > On 3/10/08, mr azmat <mr...@gm...> wrote:
>  >> So if I remove the StartDay and EndDay parameters, the sequence
> numbers  >> will  >> reset every day between the EndTime and StartTime
> (s)?
>  >> However, I want to not trade from Friday 4PM till Sunday 6PM, but
> reset  >> on a  >> daily basis between 4PM and 6PM.  Does that make
> sense?
>  >>
>  >>
>  >>
>  >> thanks!
>  >> azmat
>  >>
>  >>
>  >> On Mon, Mar 10, 2008 at 11:56 AM, Shane Trotter
> <str...@co...>  >> wrote:
>  >> > Azmat,
>  >> >
>  >> > Yes, QuickFIX should reset your sequence numbers between sessions.
>  >> >
>  >> > Note that if you use a week-long session as decided by the
> config file  >> > option StartDay and EndDay, your sequence numbers
> will be reset  >> > between the week session and not the day session.
>  >> >
>  >> >
>  >> >
>  >> >
>  >> > On 3/10/08, azmat <mr...@gm...> wrote:
>  >> > > QuickFIX Documentation:
>  >> http://www.quickfixengine.org/quickfix/doc/html/index.html
>  >> > >  QuickFIX Support:
>  >> http://www.quickfixengine.org/services.html
>  >> > >
>  >> > >
>  >> > >  All-
>  >> > >
>  >> > >  My counter-party requires that I reset both the sequence
> numbers on  >> all  >> our  >> > >  sessions every day before the
> StartTime.  How is this doable?  I did  >> take a  >> > >  look at
> these three parameters for the config file, but they don't  >> exactly
> >> > >  fit my need.
>  >> > >
>  >> > >  ResetOnLogon
>  >> > >  ResetOnLogout
>  >> > >  ResetOnDisconnect
>  >> > >
>  >> > >  I don't need to reset the sequence numbers during the day
> (during  >> incidental  >> > >  logoffs or abnormal resets, etc) but
> between the time the trading  >> day  >> comes  >> > >  to an end and
> begins.  My question is if I set the StartTime and  >> EndTime  >> > >
> parameters in the config file, will the quickfix engine  >>
> automatically  >> reset  >> > >  sequence numbers in this "down time"?
> And if not, then how would I  >> > >  accomplish this?
>  >> > >
>  >> > >  thanks!
>  >> > >  azmat
>  >> > >  --
>  >> > >  View this message in context:
>  >>
> http://www.nabble.com/Daily-Sequence-Number-Resets--tp15950889p1595088
> 9.html  >> > >  Sent from the QuickFIX - Dev mailing list archive at
> Nabble.com.
>  >> > >
>  >> > >
>  >> > >
>  >>
> ----------------------------------------------------------------------
> ---  >> > >  This SF.net email is sponsored by: Microsoft  >> > >
> Defy all challenges. Microsoft(R) Visual Studio 2008.
>  >> > >
>  >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  >> > >  _______________________________________________
>  >> > >  Quickfix-developers mailing list  >> > >
> Qui...@li...
>  >> > >
>  >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>  >> > >
>  >> >
>  >> >
>  >> > --
>  >> > Shane Trotter
>  >> > Connamara Systems, LLC
>  >> >
>  >>
>  >>
>  >
>  >
>  > --
>  > Shane Trotter
>  > Connamara Systems, LLC
>  >
>  >
> ----------------------------------------------------------------------
> ---  > This SF.net email is sponsored by: Microsoft  > Defy all
> challenges. Microsoft(R) Visual Studio 2008.
>  > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  > _______________________________________________
>  > Quickfix-developers mailing list
>  > Qui...@li...
>  > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>  >
>  >
>
>  --
>  View this message in context:
> http://www.nabble.com/Daily-Sequence-Number-Resets--tp15950889p1707154
> 5.html
>
> Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>
>
>
> ----------------------------------------------------------------------
> ---  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com
> /javaone
>
>
> _______________________________________________
>  Quickfix-developers mailing list
>  Qui...@li...
>  https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



--
Shane Trotter
Connamara Systems, LLC

***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorised and regulated by the Financial Services Authority 
 
This e-mail message is confidential and for use by the 
addressee only. If the message is received by anyone other 
than the addressee, please return the message to the sender 
by replying to it and then delete the message from your 
computer. Internet e-mails are not necessarily secure. The 
Royal Bank of Scotland plc does not accept responsibility for 
changes made to this message after it was sent. 

Whilst all reasonable care has been taken to avoid the 
transmission of viruses, it is the responsibility of the recipient to 
ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its 
systems or data. No responsibility is accepted by The 
Royal Bank of Scotland plc in this regard and the recipient should carry 
out such virus and other checks as it considers appropriate. 
Visit our websites at: 
www.rbs.com
www.rbs.com/gbm
www.rbsgc.com
***********************************************************************************

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Quickfix-developers] possible deadlocking/freeze with routing implementation ?

[quickfixer <li...@ch...>]

Hi, 

  I've been using quickfix for about three months in a routing kind of
situation (similar to this poster:
http://www.nabble.com/ThreadedSocketAcceptor---Message-resend-tc17067577.html)
where I have both an initiator and an acceptor.  I am using
ThreadedSocketAcceptor, ThreadedSocketInitator, and SynchronizedApplication. 
There are n sessions coming in through the acceptor and 1 out via the
initiator, and it is a comparitively low message throughput application.  

  We experienced a situation today where quickfix tried to send a message to
its outgoing connection, while processing a message received from on of
incoming connections, somewhere in Session::sendToTarget my quickfix server
got "stuck" (i.e. I know I called ::sendToTarget, but I never got to the
part where the message was actually sent, as I did not see the offending
message in the filestore (am using the FileStoreFactory)).  I am inclined to 
believe this is a deadlocking situation  but I am not sure on what resource
I am deadlocking and which are the two (or more!) threads that are
contending for the resource.  During this period of time (it was about 5
minutes before someone noticed - as I said "low volume"!), several clients
timed out because they failed to receive heartbeat responses, and began the
reconnect process.  For each of these clients I see the incoming heartbeat
in the individual message store for each client and then later the following
in the global log: 
"Accepted connection from x.x.x.x on port yyyy"
but there is no corresponding response from my server to neither the
heartbeat nor the new connection, presumably because those messages are
queued up waiting for the thread to finish processing the original
sendToTarget which is "stuck". I cannot however, figure out why the original
sendToTarget is "stuck" nor if it is deadlocked what it is waiting on.  

  The quickfix server was bounced, and everybody recovered and the offending
message was resent, and so everything was fine in the end, but I was
wondering if someone could help to figure out what I am doing in the code
that caused this errant issue.  Any thoughts, or pointers as to where to
look for a possible issue would be _much_ appreciated.  

Regards,
Liz
-- 
View this message in context: http://www.nabble.com/possible-deadlocking-freeze-with-routing-implementation---tp17093661p17093661.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] MsgType = AS, AllocationReport, Fix44

[Shane T. <str...@co...>]

Azmat,

UserDefinedFields are only User Defined Fields as specified by the FIX
Specification.  Normal tags (55) do not fall under this range.

-- 
Shane Trotter
Connamara Systems, LLC

On Tue, May 6, 2008 at 4:43 PM, mr azmat <mr...@gm...> wrote:
> Shane,
>
> Below is my config file.  Should it include anything else?
> I've done well with just this much information, so far.
>
>
>    # default settings for sessions
>    [DEFAULT]
>    ConnectionType=initiator
>    ReconnectInterval=10
>    HeartBtInt=60
>    FileLogPath=.
>    FileStorePath=.
>    StartTime=12:30:00
>    EndTime=21:30:00
>    #StartDay=Sunday
>    #EndDay=Friday
>
>    # Order Session
>    [SESSION]
>    BeginString=FIX.4.2
>    SenderCompID=blah2
>    TargetCompID=blah3
>    SocketConnectPort=PORT#
>    SocketConnectHost=IP#
>    DataDictionary=FIX42.xml
>
>    # Drop Copy Session
>    [SESSION]
>    BeginString=FIX.4.4
>    SenderCompID=blah1
>    TargetCompID=blah4
>    SocketConnectPort=PORT#
>    SocketConnectHost=IP#
>    DataDictionary=FIX44.xml
>
>
>
> On Tue, May 6, 2008 at 4:37 PM, Shane Trotter <str...@co...>
> wrote:
> > azmat,
> >
> > Paste the contents of your config file (with anything applicable to
> > DataDictionary).  Invalid tag number: 6081 looks like you are trying
> > to validate user tags and using a data dictionary.
> >
> > If you do need to use a data dictionary still, you need to modify it
> > to either 1) include the user-defined tags (6081) OR 2) In your config
> > file set "ValidateUserDefinedFields=N"
> >
> >
> > --
> > Shane Trotter
> > Connamara Systems, LLC
> >
> >
> >
> >
> > On Tue, May 6, 2008 at 4:34 PM, azmat <mr...@gm...> wrote:
> > > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > >  QuickFIX Support: http://www.quickfixengine.org/services.html
> > >
> > >
> > >
> > >  I get these sorts of messages in my event log:
> > >
> > >  20080506-19:55:11 : Message 79 Rejected: Invalid tag number:6081
> > >  20080506-20:32:54 : Message 132 Rejected: Required tag missing:55
> > >  20080506-20:33:55 : Message 135 Rejected: Tag not defined for this
> message
> > >  type:14
> > >
> > >  I believe they correlate with the 35=AS messages that were received,
> but
> > >  never processed.  Shouldn't fromApp be called no matter what?
> > >
> > >  thanks!
> > >  azmat
> > >
> > >
> > >
> > >
> > >  Shane Trotter wrote:
> > >  >
> > >  > QuickFIX Documentation:
> > >  > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > >  > QuickFIX Support: http://www.quickfixengine.org/services.html
> > >  >
> > >
> > > > azmat,
> > >  >
> > >  > Are you using a data dictionary for validation?
> > >  >
> > >  > --
> > >  > Shane Trotter
> > >  > Connamara Systems, LLC
> > >  >
> > >  --
> > >  View this message in context:
> http://www.nabble.com/MsgType-%3D-AS%2C-AllocationReport%2C-Fix44-tp17091080p17092823.html
> > >
> > >
> > > Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > >  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > >  Don't miss this year's exciting event. There's still time to save $100.
> > >  Use priority code J8TL2D2.
> > >
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > >  _______________________________________________
> > >  Quickfix-developers mailing list
> > >  Qui...@li...
> > >  https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > >
> >
>
>