quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] quickfix & delphi

[Djalma R. d. S. F. <drs...@gm...>]

Hi Abel,

It is often difficult to interface native code which is compiled by
different compilers.
Quickfix C++ lib exports functions with thiscall calling convension.

I believe that it is not compatible with Delphi, as far as I know Delphi
prefers fastcall or stdcall.
I worked with Delphi a long time ago (Delphi 4).  I had some experience
importing COM and C DLLs with stdcall and frankly I don't believe that it i=
s
possible to use quickfix.lib in Delphi.

I suggest that you go to managed code and import quickfix_net.dll and
quickfix_net_messages.dll in your Delphi projects.

Djalma

On 3/27/07, Abel Monroy <am...@bo...> wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello everyone,
>
> We have been using quickfix in our linux applications for a long time
> and now we are trying to use it in our Windows apps. Someone has used
> Delphi 2006 with QuickFix? We are having problems trying to  use the
> .lib into Dephi projects, has anybody done this before or have some idea
> about what are the steps in order to get a Delphi application with
> QuickFix?
> Best Regards
>
> Abel Monroy
> Visual Trader
>
>
>
>
> ****************************** AVISO LEGAL ******************************
> La informaci=F3n contenida en este mensaje es para uso exclusivo de su
> destinatario. No debe copiarse, transmitirse a terceros ni guardarse por
> estos =FAltimos, salvo autorizaci=F3n del remitente.
> Puede contener informaci=F3n confidencial o legalmente protegida cuyo
> r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de que ha=
ya sido
> enviada por correo electr=F3nico.
> Su env=EDo por error a una persona distinta de su destinatario real no
> implica que se haya modificado tal destinatario ni supone renuncia a su
> eventual car=E1cter confidencial o al r=E9gimen legal que rija su utiliza=
ci=F3n.
> Cualquier opini=F3n expresada en este mensaje vincular=E1 exclusivamente =
a la
> persona que lo haya remitido, excepto cuando el mensaje establezca lo
> contrario y el remitente est=E9 autorizado para establecer que dichas
> opiniones vincular=E1n a esta entidad.
> En el supuesto de que este correo se recibiera por error, rogamos proceda=
n
> a borrarlo, sin reenviarlo a terceros ni conservarlo en cualquier soporte=
 y
> nos informen inmediatamente llamando al tel=E9fono 34 91 7095566 o a la
> direcci=F3n de correo electr=F3nico remitente. Gracias.
> ****************************** DISCLAIMER ******************************
> The information contained in this message is for the exclusive use of the
> named person. It can not be copied, transmitted to third parties or store=
d
> by the latter, except if authorised by the sender.
> It may contain confidential or legally privileged information whose legal
> regime is not affected by the fact that this information has been sent by
> e-mail.
> Its erroneous transmission to a person other than the real named person
> neither implies any modification of this named person nor a renunciation =
of
> the eventual confidentiality or legal regime affecting the use of concern=
ed
> message.
> Any views expressed in this message are binding exclusively upon the
> individual sender, except where the message states otherwise and the send=
er
> is authorised to bind this entity.
> If you receive this message in error, please delete it without
> transmitting it to any third party or keeping it in any form and notify u=
s
> immediately either by phone (34 91 7095566) or using the e- mail address =
of
> the sender. Thank You.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] quickfix & delphi

[Abel M. <am...@bo...>]

Hello everyone,

We have been using quickfix in our linux applications for a long time=20
and now we are trying to use it in our Windows apps. Someone has used=20
Delphi 2006 with QuickFix? We are having problems trying to  use the=20
.lib into Dephi projects, has anybody done this before or have some idea =

about what are the steps in order to get a Delphi application with =
QuickFix?
Best Regards

Abel Monroy
Visual Trader




****************************** AVISO LEGAL =
******************************
La informaci=F3n contenida en este mensaje es para uso exclusivo de su =
destinatario. No debe copiarse, transmitirse a terceros ni guardarse por =
estos =FAltimos, salvo autorizaci=F3n del remitente.
Puede contener informaci=F3n confidencial o legalmente protegida cuyo =
r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de que =
haya sido enviada por correo electr=F3nico.
Su env=EDo por error a una persona distinta de su destinatario real no =
implica que se haya modificado tal destinatario ni supone renuncia a su =
eventual car=E1cter confidencial o al r=E9gimen legal que rija su =
utilizaci=F3n.
Cualquier opini=F3n expresada en este mensaje vincular=E1 exclusivamente =
a la persona que lo haya remitido, excepto cuando el mensaje establezca =
lo contrario y el remitente est=E9 autorizado para establecer que dichas =
opiniones vincular=E1n a esta entidad.
En el supuesto de que este correo se recibiera por error, rogamos =
procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en =
cualquier soporte y nos informen inmediatamente llamando al tel=E9fono =
34 91 7095566 o a la direcci=F3n de correo electr=F3nico remitente. =
Gracias.
****************************** DISCLAIMER ******************************
The information contained in this message is for the exclusive use of =
the named person. It can not be copied, transmitted to third parties or =
stored by the latter, except if authorised by the sender.
It may contain confidential or legally privileged information whose =
legal regime is not affected by the fact that this information has been =
sent by e-mail.=20
Its erroneous transmission to a person other than the real named person =
neither implies any modification of this named person nor a renunciation =
of the eventual confidentiality or legal regime affecting the use of =
concerned message.
Any views expressed in this message are binding exclusively upon the =
individual sender, except where the message states otherwise and the =
sender is authorised to bind this entity.=20
If you receive this message in error, please delete it without =
transmitting it to any third party or keeping it in any form and notify =
us immediately either by phone (34 91 7095566) or using the e- mail =
address of the sender. Thank You.

Re: [Quickfix-developers] Socket Monitoring/Verification

[Djalma R. d. S. F. <drs...@gm...>]

Hi Oren,

Thank you for the answer.

Yes, you are right, I remember the problems with blocking sockets (better
the way it is now).

But, after checking better the source code, I think that there is still an
information not provided and I would like to suggest the following:

How about having SendToTarget throwing IOException, instead of hiding it
from the developer in SendRaw?

By catching this exception, the application would be able to know that
message wasn't  persisted.

But, this would be even better if message was persisted before sending.
Because if IOException is thrown by SendToTarget, this would mean that the
message was not sent either persisted. Isn't it dangerous to send before
persisting?

What is your opinion?

bool Session::sendRaw( Message& message, int num )
{ QF_STACK_PUSH(Session::sendRaw)

  Locker l( m_mutex );

  try
  {
    ...
    if ( Message::isAdminMsgType( msgType ) )
    {
      ...
    }
    else
    {
      // do not send application messages if they will just be cleared
      if( !isLoggedOn() && shouldSendReset() )
        return false;

      try
      {
        m_application.toApp( message, m_sessionID );
        message.toString( messageString );
        if ( isLoggedOn() )
          result = send( messageString );
      }
      catch ( DoNotSend& ) { return false; }
    }

    if ( !num )
    {
      MsgSeqNum msgSeqNum;
      header.getField( msgSeqNum );
      if( m_persistMessages )
        m_state.set( msgSeqNum, messageString );
      m_state.incrNextSenderMsgSeqNum();
    }
    return result;
  }
  catch ( IOException& e )
  {
    m_state.onEvent( e.what() );
    return false;
  }

  QF_STACK_POP
}

Regards,
Djalma


On 3/26/07, Oren Miller <or...@qu...> wrote:
>
> Unfortunately this just isn't possible.  The Socket implementations
> uses non-blocking sockets.  When the SendToTarget call returns,
> QuickFIX just doesn't know whether or not the message has been
> successfully sent or not.  Blocking sockets solve that problem (as we
> used to use), but causes much worse problems in the form of
> deadlocks.  So really we are conveying to you as much information as
> we have.  When true is returned, we have persisted the message
> (guaranteed) and sent it on the socket (perhaps successfully, perhaps
> not, we do not know at this point) .  This is all we know and all we
> can return to you.
>
> On Mar 25, 2007, at 1:49 PM, Djalma Rosa dos Santos Filho wrote:
>
> > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> > html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi guys,
> >
> > Thank you Dave for the answers. I have to agree with you that FIX
> > is an optimistic model.
> > But, it would be clearer and easier for me if SendToTarget could
> > return one of the following 3 values:
> >
> > 0 - message successfully sent
> > 1 - message not sent, but seqnum incremented and message stored to
> > be resent after reconnection
> > 2 - message won't be sent for some reason (because toApp threw
> > DoNotSend or an IOException was raised e.g.), which means no
> > possiblity of resending after reconnection
>
>

Re: [Quickfix-developers] Calling user code in quickfix thread

[Sridhar V. <sva...@li...>]

Thank you for the response. This is definitely a good option. I am not
sure of the performance cost since the QF thread would block on every
message.

Is there any case here were we could deadlock if the worker thread tried
to call some QF API. i.e, does QF hold onto any locks before calling the
callback?

Could happen if QF did the following:
QF thread: (Hold some lock L1) -> invoke say QF::fromApp callback ->
callback blocks on semaphore=20
Worker thread: -> process fix message or some other BL message -> call
QF API requiring lock L1 as part of processing, and we are dead locked.

I don't see QF holding any lock before calling the callback from looking
at the code, but I want to be sure that this is the case for all
callbacks and we can have a reliable mechanism.

Thanks,
-Sridhar Vasudevan

________________________________________
From: Brian Erst [mailto:azz...@ya...]=20
Sent: Monday, March 26, 2007 10:59 AM
To: Sridhar Vasudevan; qui...@li...
Subject: Re: [Quickfix-developers] Calling user code in quickfix thread

Alternatively, you could create a separate thread that does all your
business logic needs, but enforce a "single work unit at a time" mode
for processing QF units.

For example, you create a worker thread that reads "work commands" off
of an internal queue. You create two synchronization objects: a "FIX
message processed" (initially set to "false") auto reset event and a
"work unit queued" semaphore (initially set to 0).

Whenever you need to do some work (process a FIX message, do your other
processing), you create a "work unit object" that contains the type of
work you want to do (process FIX msg, do other thing) and the data
needed to perform the task. You place it on the internal work queue and
raise the semaphore.

In the case of a FIX message, you then wait on the "FIX message
processed" event - blocking the thread until the job is done.

The worker thread blocks on the semaphore. When the semaphore is raised,
it does its job and, if the job was processing a FIX message, it raises
the "FIX message processed" event, freeing the QF thread. You then loop
back to the semaphore block.

Now, QF will only send you a single message at a time to your worker
thread, which also does all your other business logic work. In this
example, your non-FIX BL thread can queue multiple work units at a time,
but you can modify that by making the "FIX message processed" event more
generic. Add a secondary event to allow you to interrupt the semaphore
block (for quick shutdowns) and you've got a simple, workable system.

I write code like that all the time - it turns out to be about 30-40
lines of code, wrapped up in a little class.

- Brian Erst
Thynk Software, Inc.
----- Original Message ----
From: Sridhar Vasudevan <sva...@li...>
To: qui...@li...
Sent: Monday, March 26, 2007 9:36:46 AM
Subject: [Quickfix-developers] Calling user code in quickfix thread
QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


Hello,
We are using the C++ (1.10.2) version of quickfix to implement an
application which has a fix connection and another messaging connection.
We have a few questions related to quickfix spawning its own thread and
calling all callbacks in the context of the thread it spawned.=20

1. Is it possible to call a user defined callback periodically in the QF
thread, so we can do all other non QF related processing in this thread
itself, for example process messages from our messaging connection, etc?


2. If we were to push all fix messages received in the callback onto a
queue, and do all processing on a different thread, then we run the risk
that if the process is bounced then messages in the queue are lost,
since from QF perspective the message has been processed since the
callback exited successfully, while infact its still queued to be
processed on a different thread.=20
While there are ways outside of QF to get around this, we were wondering
if there was a way we could reliably modify the persisted "sequence
number" from the main thread, such that upon restart it can request
resend of fix messages based on what has really been processed.

3. Another option is to not have quickfix spawn its own thread, but
instead we have a mechanism were we would periodically call some QF
function so quickfix can do its processing, effectively having a single
threaded application.

Are any of these feasible options and if so what will need to be done on
our side?=20

We are exploring these options as we would like to avoid having business
logic code running in multiple threads if that's possible.

Thanks in advance,
Sridhar Vasudevan



------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Socket Monitoring/Verification

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

Unfortunately this just isn't possible.  The Socket implementations  
uses non-blocking sockets.  When the SendToTarget call returns,  
QuickFIX just doesn't know whether or not the message has been  
successfully sent or not.  Blocking sockets solve that problem (as we  
used to use), but causes much worse problems in the form of  
deadlocks.  So really we are conveying to you as much information as  
we have.  When true is returned, we have persisted the message  
(guaranteed) and sent it on the socket (perhaps successfully, perhaps  
not, we do not know at this point) .  This is all we know and all we  
can return to you.

On Mar 25, 2007, at 1:49 PM, Djalma Rosa dos Santos Filho wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi guys,
>
> Thank you Dave for the answers. I have to agree with you that FIX  
> is an optimistic model.
> But, it would be clearer and easier for me if SendToTarget could  
> return one of the following 3 values:
>
> 0 - message successfully sent
> 1 - message not sent, but seqnum incremented and message stored to  
> be resent after reconnection
> 2 - message won't be sent for some reason (because toApp threw  
> DoNotSend or an IOException was raised e.g.), which means no  
> possiblity of resending after reconnection

Re: [Quickfix-developers] Calling user code in quickfix thread

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

Alternatively, you could create a separate thread that does all your business logic needs, but enforce a "single work unit at a time" mode for processing QF units.

For example, you create a worker thread that reads "work commands" off of an internal queue. You create two synchronization objects: a "FIX message processed" (initially set to "false") auto reset event and a "work unit queued" semaphore (initially set to 0).

Whenever you need to do some work (process a FIX message, do your other processing), you create a "work unit object" that contains the type of work you want to do (process FIX msg, do other thing) and the data needed to perform the task. You place it on the internal work queue and raise the semaphore.

In the case of a FIX message, you then wait on the "FIX message processed" event - blocking the thread until the job is done.

The worker thread blocks on the semaphore. When the semaphore is raised, it does its job and, if the job was processing a FIX message, it raises the "FIX message processed" event, freeing the QF thread. You then loop back to the semaphore block.

Now, QF will only send you a single message at a time to your worker thread, which also does all your other business logic work. In this example, your non-FIX BL thread can queue multiple work units at a time, but you can modify that by making the "FIX message processed" event more generic. Add a secondary event to allow you to interrupt the semaphore block (for quick shutdowns) and you've got a simple, workable system.

I write code like that all the time - it turns out to be about 30-40 lines of code, wrapped up in a little class.

- Brian Erst
Thynk Software, Inc.

----- Original Message ----
From: Sridhar Vasudevan <sva...@li...>
To: qui...@li...
Sent: Monday, March 26, 2007 9:36:46 AM
Subject: [Quickfix-developers] Calling user code in quickfix thread

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


Hello,
We are using the C++ (1.10.2) version of quickfix to implement an
application which has a fix connection and another messaging connection.
We have a few questions related to quickfix spawning its own thread and
calling all callbacks in the context of the thread it spawned. 

1. Is it possible to call a user defined callback periodically in the QF
thread, so we can do all other non QF related processing in this thread
itself, for example process messages from our messaging connection, etc?


2. If we were to push all fix messages received in the callback onto a
queue, and do all processing on a different thread, then we run the risk
that if the process is bounced then messages in the queue are lost,
since from QF perspective the message has been processed since the
callback exited successfully, while infact its still queued to be
processed on a different thread. 
While there are ways outside of QF to get around this, we were wondering
if there was a way we could reliably modify the persisted "sequence
number" from the main thread, such that upon restart it can request
resend of fix messages based on what has really been processed.

3. Another option is to not have quickfix spawn its own thread, but
instead we have a mechanism were we would periodically call some QF
function so quickfix can do its processing, effectively having a single
threaded application.

Are any of these feasible options and if so what will need to be done on
our side? 

We are exploring these options as we would like to avoid having business
logic code running in multiple threads if that's possible.

Thanks in advance,
Sridhar Vasudevan



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Calling user code in quickfix thread

[Sridhar V. <sva...@li...>]

Hello,
We are using the C++ (1.10.2) version of quickfix to implement an
application which has a fix connection and another messaging connection.
We have a few questions related to quickfix spawning its own thread and
calling all callbacks in the context of the thread it spawned.=20

1. Is it possible to call a user defined callback periodically in the QF
thread, so we can do all other non QF related processing in this thread
itself, for example process messages from our messaging connection, etc?


2. If we were to push all fix messages received in the callback onto a
queue, and do all processing on a different thread, then we run the risk
that if the process is bounced then messages in the queue are lost,
since from QF perspective the message has been processed since the
callback exited successfully, while infact its still queued to be
processed on a different thread.=20
While there are ways outside of QF to get around this, we were wondering
if there was a way we could reliably modify the persisted "sequence
number" from the main thread, such that upon restart it can request
resend of fix messages based on what has really been processed.

3. Another option is to not have quickfix spawn its own thread, but
instead we have a mechanism were we would periodically call some QF
function so quickfix can do its processing, effectively having a single
threaded application.

Are any of these feasible options and if so what will need to be done on
our side?=20

We are exploring these options as we would like to avoid having business
logic code running in multiple threads if that's possible.

Thanks in advance,
Sridhar Vasudevan

Re: [Quickfix-developers] Socket Monitoring/Verification

[Djalma R. d. S. F. <drs...@gm...>]

Hi guys,

Thank you Dave for the answers. I have to agree with you that FIX is an
optimistic model.
But, it would be clearer and easier for me if SendToTarget could return one
of the following 3 values:

0 - message successfully sent
1 - message not sent, but seqnum incremented and message stored to be resent
after reconnection
2 - message won't be sent for some reason (because toApp threw DoNotSend or
an IOException was raised e.g.), which means no possiblity of resending
after reconnection

This way, I would have information to know what really happened with the
message and I would be more confortable to decide what to do.

@Jim, if you have SenderCompID, TargetCompID and BeginString then you
already have the SessionID, see the available FIX::SessionID constructors.

Another solution is getting the SessionID from the mounted message:

FIX::Session* pSession = FIX::Session::lookupSession( message.getSessionID()
);
if( pSession )
{
    if( pSession->isLoggedOn() )
    {
        if (!FIX::Session::sendToTarget( message ))
        {
            // error handling here (optional?)
        }
    }
}

Regards,
Djalma

On 3/25/07, Dave Linaker <dav...@ma...> wrote:
>
> Hi Djalma,
>
> > Yes, these are exactly the same techniques I use in my application to
> > detect the availability of connections.
> >
> > In the past, before sending, I used to check if session was logged on,
> as
> > Dave showed in his example. But, later I verified that SendToTarget
> > already does it internally and then I decided to stop doing it, so I
> could
> > avoid the performance penalty of a double-checking.
>
> True, but this only prevents it from actually being sent while the
> connection is down, it would still be stored and consume a sequence
> number,
> and later on be sent when the inevitable ResendRequest arrives.  You could
> of course prevent the stored message from being resent by throwing a
> DoNotSend when the connection is reestablished. So I guess it depends on
> what you want to achieve:
>
> - if you always want the message to be sent then I think there is little
> to
> be gained by checking the logon state before sending.
> - if you only want the message to sent if there is an active connection
> then you could either:
>
>     - check the logon state before sending, or
>     - send it anyway, and prevent the resend in toApp() with DoNotSend
>
> > If a connection problem occurs after the message is written to the
> store,
> > the function will return true, although the message was not sent. In
> this
> > case, Dave is right, the message won't be lost, but only if the app is
> > lucky enough to get a soon reconnection and if the counterparty sends a
> > ResendRequest, after detecting the message sequence number gap.
> >
> > I think that for mission-critical systems this is dangerous to rely on
> the
>
> > desire of the counterparty to resend messages, there should be an
> > alternative in QF, like a function/queue from where to get the messages
> > that were not sent due to unavailability of a socket connections. With
> > this function, the application could force the "resending" of these
> > messages even if a SequenceReset is received.
>
> I think the ResendRequest is inevitable provided that the subsequent
> reconnection takes place during the same session. Each message that is
> stored consumes a sequence number regardless of whether it is actually
> sent.
> So, if you have sent some messages while the connection was down, when you
> logon, your Logon message will have a later sequence number and the other
> side will see a gap and must perform a gap fill operation to fill that
> gap.
> The counterparty is required to process messages in sequence so they must
> fill any gaps. I think there should always be a ResendRequest to recover
> the
> messages sent while the connection was down (i.e. it is not optional on
> the
> part of the counterparty).  FIX is an optimistic model, which means you
> are
> always reliant on the counterparty to identify any missed messages.
>
> Cheers,
> Dave
>
>

Re: [Quickfix-developers] Socket Monitoring/Verification

[Dave L. <dav...@ma...>]

Hi Djalma,

> Yes, these are exactly the same techniques I use in my application to=20
> detect the availability of connections.
>=20
> In the past, before sending, I used to check if session was logged on, =
as=20
> Dave showed in his example. But, later I verified that SendToTarget=20
> already does it internally and then I decided to stop doing it, so I =
could
> avoid the performance penalty of a double-checking.

True, but this only prevents it from actually being sent while the
connection is down, it would still be stored and consume a sequence =
number,
and later on be sent when the inevitable ResendRequest arrives.  You =
could
of course prevent the stored message from being resent by throwing a
DoNotSend when the connection is reestablished. So I guess it depends on
what you want to achieve:

 - if you always want the message to be sent then I think there is =
little to
be gained by checking the logon state before sending.
 - if you only want the message to sent if there is an active connection
then you could either:

    - check the logon state before sending, or
    - send it anyway, and prevent the resend in toApp() with DoNotSend

> If a connection problem occurs after the message is written to the =
store,=20
> the function will return true, although the message was not sent. In =
this=20
> case, Dave is right, the message won't be lost, but only if=A0 the app =
is=20
> lucky enough to get a soon reconnection and if the counterparty sends =
a=20
> ResendRequest, after detecting the message sequence number gap.=20
>=20
> I think that for mission-critical systems this is dangerous to rely on =
the

> desire of the counterparty to resend messages, there should be an=20
> alternative in QF, like a function/queue from where to get=A0 the =
messages=20
> that were not sent due to unavailability of a socket connections. With =

> this function, the application could force the "resending" of these=20
> messages even if a SequenceReset is received.=20

I think the ResendRequest is inevitable provided that the subsequent
reconnection takes place during the same session. Each message that is
stored consumes a sequence number regardless of whether it is actually =
sent.
So, if you have sent some messages while the connection was down, when =
you
logon, your Logon message will have a later sequence number and the =
other
side will see a gap and must perform a gap fill operation to fill that =
gap.
The counterparty is required to process messages in sequence so they =
must
fill any gaps. I think there should always be a ResendRequest to recover =
the
messages sent while the connection was down (i.e. it is not optional on =
the
part of the counterparty).  FIX is an optimistic model, which means you =
are
always reliant on the counterparty to identify any missed messages.=20

Cheers,
Dave

Re: [Quickfix-developers] Socket Monitoring/Verification

[Djalma R. d. S. F. <drs...@gm...>]

Yes, these are exactly the same techniques I use in my application to detect
the availability of connections.

In the past, before sending, I used to check if session was logged on, as
Dave showed in his example. But, later I verified that SendToTarget already
does it internally and then I decided to stop doing it, so I could avoid the
performance penalty of a double-checking.

As far as I know, the only Exception raised by SendToTarget is the
FIX::SessionNotFound, nothing related to sockets (this is good in my
opinion).

But, in order to avoid losing messages, I suggest the verification of its
return value. If SendToTarget returns false, it means that the message has
not been sent and that it won't be resent, since it was not written in the
session's Store.

If a connection problem occurs after the message is written to the store,
the function will return true, although the message was not sent. In this
case, Dave is right, the message won't be lost, but only if  the app is
lucky enough to get a soon reconnection and if the counterparty sends a
ResendRequest, after detecting the message sequence number gap.

I think that for mission-critical systems this is dangerous to rely on the
desire of the counterparty to resend messages, there should be an
alternative in QF, like a function/queue from where to get  the messages
that were not sent due to unavailability of a socket connections. With this
function, the application could force the "resending" of these messages even
if a SequenceReset is received.

Regards,
Djalma

On 3/25/07, Dave Linaker < dav...@ma...> wrote:
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> >    I am working on a QuickFIX App that connects to a counterparty
> > where the connection is not very reliable.  Checking the logs, I see on
> > average half a dozen to ten re-logins each market day.  I want to be a
> > lot more proactive about tracking the status of the connection, and if
> > possible, when it is time to send out an application message, check to
> > see that the connection is good before even attempting to send it.  I've
>
> > put a try {} around my sendToTarget calls and attempted to catch
> > exceptions related to the socket, but none get thrown.  Even when I
> > am testing and deliberately break the network connection, I still get
> > no exception thrown.
> >
>
> No there won't be, the messages are persisted and will ultimately be
> resent
> when the connection is reestablished.
>
> >    Does anyone have a decent rundown on what facilities are there in
> > QuickFIX to monitor the status of the socket at a low level?  Are there
> > any flags or fields on the Session that I can check?  Should I force a
> > Test message before attempting to send Orders, etc.?  I don't want to
> > hack QuickFIX itself if I can avoid it.
> >
>
> The onLogout() in your interface will be called whenever there is a logout
> or disconnection, so you could also use this to handle unexpected
> disconnects.
>
> You could check the session to see if it is logged on before you send the
> message, perhaps something like:
>
> FIX::Session* pSession = FIX::Session::lookupSession( sessionID );
> if( pSession ) {
>   if( pSession->isLoggedOn() ) {
>       FIX::Session::sendToTarget( message, sessionID );
>   }
> }
>
> Cheers,
> Dave
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Socket Monitoring/Verification

[Jim W. <wi...@wi...>]

   First, many thanks for the reply.


Dave Linaker wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>   
>>    I am working on a QuickFIX App that connects to a counterparty
>> where the connection is not very reliable.  Checking the logs, I see on
>> average half a dozen to ten re-logins each market day.  I want to be a
>> lot more proactive about tracking the status of the connection, and if
>> possible, when it is time to send out an application message, check to
>> see that the connection is good before even attempting to send it.  I've
>> put a try {} around my sendToTarget calls and attempted to catch
>> exceptions related to the socket, but none get thrown.  Even when I
>> am testing and deliberately break the network connection, I still get
>> no exception thrown.
>>
>>     
>
> No there won't be, the messages are persisted and will ultimately be resent
> when the connection is reestablished.
>   
   Unless you throw DoNotSend in toApp, correct?
>>    Does anyone have a decent rundown on what facilities are there in
>> QuickFIX to monitor the status of the socket at a low level?  Are there
>> any flags or fields on the Session that I can check?  Should I force a
>> Test message before attempting to send Orders, etc.?  I don't want to
>> hack QuickFIX itself if I can avoid it.
>>
>>     
>
> The onLogout() in your interface will be called whenever there is a logout
> or disconnection, so you could also use this to handle unexpected
> disconnects.
>
> You could check the session to see if it is logged on before you send the
> message, perhaps something like:
>
> FIX::Session* pSession = FIX::Session::lookupSession( sessionID );
> if( pSession ) {
>   if( pSession->isLoggedOn() ) {
>       FIX::Session::sendToTarget( message, sessionID );
>   } 
> }
>
>   
   I managed to work out something similar, by checking the
SocketInitiator isLoggedOn() method before attempting to send.
Still, your technique seems a little more elegant -- but it begs the
question of how exactly I get the sessionID.  The function where
I'm generating the messages to be sent is not a method that gets
the sessionID passed in automatically.  It gets called in the main
loop of the run() method, where the sessionID does not appear to
be immediately available.  I have to admit I'm primarily a C
programmer, not C++, and there is a definite learning curve
trying to figure out QuickFIX internals by inspecting the source.
I have global variables storing the Sender and Target CompID
values as strings, as well as the FIX4.X string -- can I just *build*
a FIX::SessionID on the fly in the routine and use it?  Or possibly
build it in the run application and pass it in every time to my
outgoing message routine?

> Cheers,
> Dave
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>   

Re: [Quickfix-developers] Socket Monitoring/Verification

[Dave L. <dav...@ma...>]

>    I am working on a QuickFIX App that connects to a counterparty
> where the connection is not very reliable.  Checking the logs, I see on
> average half a dozen to ten re-logins each market day.  I want to be a
> lot more proactive about tracking the status of the connection, and if
> possible, when it is time to send out an application message, check to
> see that the connection is good before even attempting to send it.  I've
> put a try {} around my sendToTarget calls and attempted to catch
> exceptions related to the socket, but none get thrown.  Even when I
> am testing and deliberately break the network connection, I still get
> no exception thrown.
> 

No there won't be, the messages are persisted and will ultimately be resent
when the connection is reestablished.

>    Does anyone have a decent rundown on what facilities are there in
> QuickFIX to monitor the status of the socket at a low level?  Are there
> any flags or fields on the Session that I can check?  Should I force a
> Test message before attempting to send Orders, etc.?  I don't want to
> hack QuickFIX itself if I can avoid it.
> 

The onLogout() in your interface will be called whenever there is a logout
or disconnection, so you could also use this to handle unexpected
disconnects.

You could check the session to see if it is logged on before you send the
message, perhaps something like:

FIX::Session* pSession = FIX::Session::lookupSession( sessionID );
if( pSession ) {
  if( pSession->isLoggedOn() ) {
      FIX::Session::sendToTarget( message, sessionID );
  } 
}

Cheers,
Dave

[Quickfix-developers] Socket Monitoring/Verification

[Jim W. <wi...@wi...>]

 Folks,

   I am working on a QuickFIX App that connects to a counterparty
where the connection is not very reliable.  Checking the logs, I see on
average half a dozen to ten re-logins each market day.  I want to be a
lot more proactive about tracking the status of the connection, and if
possible, when it is time to send out an application message, check to
see that the connection is good before even attempting to send it.  I've
put a try {} around my sendToTarget calls and attempted to catch
exceptions related to the socket, but none get thrown.  Even when I
am testing and deliberately break the network connection, I still get
no exception thrown.

   Does anyone have a decent rundown on what facilities are there in
QuickFIX to monitor the status of the socket at a low level?  Are there
any flags or fields on the Session that I can check?  Should I force a
Test message before attempting to send Orders, etc.?  I don't want to
hack QuickFIX itself if I can avoid it.

   I'm currently using QuickFIX 1.10.2 but intend to upgrade to 1.12.4
this weekend.  Can I expect any major gotchas during the upgrade?

many thanks,
Jim Wiggs

Re: [Quickfix-developers] [Quickfix-users] FIX 4.2 Commission error....

[Djalma R. d. S. F. <drs...@gm...>]

Hi Eranga,

It seems to me that quickfix is not being able to convert  the field value
to double (AMT, PRICE and FLOAT are all double).

Can you show the content of the message being rejected?

Are you sure that the field has a digit like 12=2625.34 or 12=2000.00 ?

Djalma


On 3/23/07, Eranga Samararathna <pe...@ri...> wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> What I did Change the FIX42.xml file.
>
> E.g. : <field number="12" name="Commission" type="AMT"/>
>
> I changed this type Property to PRICE , FLOAT
>
> -----Original Message-----
> From: John Haldi [mailto:JH...@al...]
> Sent: Friday, March 23, 2007 5:48 PM
> To: Eranga Samararathna
> Subject: RE: [Quickfix-users] FIX 4.2 Commission error....
>
> When you say you change the specification, are you saying that you
> change the XML data dictionary to expect a different type?
>
> -----Original Message-----
> From: Eranga Samararathna [mailto:pe...@ri...]
> Sent: Friday, March 23, 2007 12:21 AM
> To: John Haldi; qui...@li...;
> qui...@li...
> Subject: RE: [Quickfix-users] FIX 4.2 Commission error....
>
> I am sending a order ( 35 =D ) with both 12 and 13 tags. Once Exchange
> ack the order ( 39 =0 ) it sends back me both tags ( 12 and 13 ). At
> that time my FIX engine reject that execution report saying "Incorrect
> data format for value". This happens only when I set tag 12 value for
> Double. It works perfect with int values.
>
> I change the Specification type from "AMT" to "PRICE". Again to "FLOAT"
> I am using Quickfix through a JNI.
> But still problem there. Pl help me to solve this issue.
>
>
> Eranga
>
> -----Original Message-----
> From: John Haldi [mailto:JH...@al...]
> Sent: Thursday, March 22, 2007 8:19 PM
> To: Eranga Samararathna
> Subject: RE: [Quickfix-users] FIX 4.2 Commission error....
>
>
> Is the error you are referring to coming from the IDE at design time or
> is it a FIX error at run time from your acceptor application?
>
> Also, what are you setting CommType (tag=13) to?  Perhaps if you don't
> set it there is no default value?  I've never used this field so I'm not
> sure.  But when I try to "get" the value, I know that the default class
> returns a double var type.
>
>    John
>
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of
> Eranga Samararathna
> Sent: Thursday, March 22, 2007 10:17 AM
> To: qui...@li...;
> qui...@li...
> Subject: [Quickfix-users] FIX 4.2 Commission error....
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

[Quickfix-developers] Quickfix/J FileStore performance

[bmazlish <bma...@ya...>]

I am trying to understand the performance hit I get by using a FileLogStore
in quickfix/J.  In reading through the archives, the filestore appears to
add a marginal performance hit (message by Oren Miller dated 8-8-2006).
However, this is not my experience with quickfix/j.  In order to test this
out, I turn off all logging so that the only i/o is the messagestore.  When
I run 5000 new order singles through my test program, each call to
Session.sendToTarget takes under a millisecond when using a MemoryStore.
However, when I replace the MemoryStore with a FileStore my performance
drops and each call takes ~75 milliseconds for each call.  In digging
through the code, it appears that the randomaccessfiles are being
initialized with the "rwd" mode -- thus requiring every message to get
written to disk.  
 
I have two questions:
 
1- Is 75 ms reasonable?  It seems far greater than the stats I have seen
from this list (presumably C version)-- is this a java vs C issue?  Or
potentially how randomaccessfile's are implemented in java?
 
2- If i were to change the constructors of the RandomAccessFiles to just use
"rw" mode, I believe I would be safe as long as the OS doesn't crash.  Is
this correct?  
 
Thanks for your help.
 
I am running this on an HP DL145 server class machine running fc4 with
hardware raid scsi drives and JVM 1.5.11.  
 
 

Re: [Quickfix-developers] [Quickfix-users] FIX 4.2 Commission error....

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

What I did Change the FIX42.xml file. 

E.g. : <field number="12" name="Commission" type="AMT"/>

I changed this type Property to PRICE , FLOAT 

-----Original Message-----
From: John Haldi [mailto:JH...@al...] 
Sent: Friday, March 23, 2007 5:48 PM
To: Eranga Samararathna
Subject: RE: [Quickfix-users] FIX 4.2 Commission error....

When you say you change the specification, are you saying that you
change the XML data dictionary to expect a different type? 

-----Original Message-----
From: Eranga Samararathna [mailto:pe...@ri...] 
Sent: Friday, March 23, 2007 12:21 AM
To: John Haldi; qui...@li...;
qui...@li...
Subject: RE: [Quickfix-users] FIX 4.2 Commission error....

I am sending a order ( 35 =D ) with both 12 and 13 tags. Once Exchange
ack the order ( 39 =0 ) it sends back me both tags ( 12 and 13 ). At
that time my FIX engine reject that execution report saying "Incorrect
data format for value". This happens only when I set tag 12 value for
Double. It works perfect with int values.

I change the Specification type from "AMT" to "PRICE". Again to "FLOAT"
I am using Quickfix through a JNI.
But still problem there. Pl help me to solve this issue.


Eranga

-----Original Message-----
From: John Haldi [mailto:JH...@al...]
Sent: Thursday, March 22, 2007 8:19 PM
To: Eranga Samararathna
Subject: RE: [Quickfix-users] FIX 4.2 Commission error....


Is the error you are referring to coming from the IDE at design time or
is it a FIX error at run time from your acceptor application?

Also, what are you setting CommType (tag=13) to?  Perhaps if you don't
set it there is no default value?  I've never used this field so I'm not
sure.  But when I try to "get" the value, I know that the default class
returns a double var type.

   John

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Eranga Samararathna
Sent: Thursday, March 22, 2007 10:17 AM
To: qui...@li...;
qui...@li...
Subject: [Quickfix-users] FIX 4.2 Commission error....

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Re: [Quickfix-developers] [Quickfix-users] FIX 4.2 Commission error....

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

I am sending a order ( 35 =D ) with both 12 and 13 tags. Once Exchange ack
the order ( 39 =0 ) it sends back me both tags ( 12 and 13 ). At that time
my FIX engine reject that execution report saying "Incorrect data format for
value". This happens only when I set tag 12 value for Double. It works
perfect with int values.

I change the Specification type from "AMT" to "PRICE". Again to "FLOAT"
I am using Quickfix through a JNI.
But still problem there. Pl help me to solve this issue.


Eranga

-----Original Message-----
From: John Haldi [mailto:JH...@al...] 
Sent: Thursday, March 22, 2007 8:19 PM
To: Eranga Samararathna
Subject: RE: [Quickfix-users] FIX 4.2 Commission error....


Is the error you are referring to coming from the IDE at design time or
is it a FIX error at run time from your acceptor application?

Also, what are you setting CommType (tag=13) to?  Perhaps if you don't
set it there is no default value?  I've never used this field so I'm not
sure.  But when I try to "get" the value, I know that the default class
returns a double var type.

   John

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Eranga Samararathna
Sent: Thursday, March 22, 2007 10:17 AM
To: qui...@li...;
qui...@li...
Subject: [Quickfix-users] FIX 4.2 Commission error....

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

[Quickfix-developers] FIX 4.2 Commission error....

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

Hi,

 

When I set double values for Commission ( Tag 12 ) I am getting "Incorrect
data format for value" error. I change the Specification type from "AMT" to
"PRICE". Again to "FLOAT"

But still problem there. Pl help me to solve this issue.

 

BR,

 

Eranga

[Quickfix-developers] Log Viewer Start Error

[DaveX <dav...@ya...>]

Hi

I downloaded QF log viewer 1.1.1, when I start the quickfix-logviewer.bat. I
got the following error:

C:\>"C:\jdk1.3.1_20/bin/java" -Xmx512M -classpath
quickfixj.jar;quickfix-logview
er.jar quickfix.logviewer.Main FIX44.xml
Exception in thread "main" java.lang.NoClassDefFoundError:
quickfix/logviewer/Main

There is something missing. Can someone please help?

Dave
-- 
View this message in context: http://www.nabble.com/Log-Viewer-Start-Error-tf3435504.html#a9578367
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] QF on Windows x64

[Djalma R. d. S. F. <drs...@gm...>]

Hi Francis,

My opinion is that Windows is trying to run your application as a 64 bit
program and actually we know it is not.

x86 code can run only under WOW64, normally the DLL's are loaded from
%windir%\SysWoW64\.

But it seems that you can run .NET application as a 32 bit program only if
compiled with .NET Framework 1.1.

http://support.microsoft.com/?scid=kb%3Ben-us%3B896456&x=15&y=13

Anyway, It is much more easier deploying native 64 bit application and I've
never had problems compiling QF for x64/ia64 native and .NET.

I suggest that you install VS2005 SP1 and later run vcredist_x64.exe in your
x64 Server.

Following is a good tutorial for creating 64 bit applications.

http://blogs.msdn.com/deeptanshuv/archive/2006/04/11/573795.aspx

Regards,
Djalma

On 3/17/07, Francis Gingras <fr...@at...> wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Is anyone using QuickFix.NET on a x64 Windows 2003 server?  I installed
> the MSV* dlls but it still wouldn't let me start my QF app compiled to any
> CPU with .NET 2.
>
> Missing dependencies are:
> MSVCM80.DLL
> MSVCP80.DLL
> MSVCR80.DLL
>
> I believe the last two are false positives:
> DEVMGR.DLL
> DWMAPI.DLL (a Vista dll ??)
>
> So I installed vcredist_x86.exe and that took care of the MSV
> dependencies.  The app still won't run (the same code runs fine on WinXP), I
> get :
>
> "Could not load file or assembly 'quickfix_net, Version=1.0.2632.4101,
> Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt
> was made to load a program with an incorrect format."
>
> I recompiled the app for x86 so at least it works in compatibility mode
> but it's not optimal.  Trying to compile QF for x64 crashes VS2005.  If
> anyone resolved the issue I'd appreciate the info.
>
> Thanks,
>
> Francis
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] QF on Windows x64

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

Is anyone using QuickFix.NET on a x64 Windows 2003 server?  I installed the MSV* dlls but it still wouldn't let me start my QF app compiled to any CPU with .NET 2.

Missing dependencies are:
MSVCM80.DLL
MSVCP80.DLL
MSVCR80.DLL

I believe the last two are false positives:
DEVMGR.DLL
DWMAPI.DLL (a Vista dll ??)

So I installed vcredist_x86.exe and that took care of the MSV dependencies.  The app still won't run (the same code runs fine on WinXP), I get :

"Could not load file or assembly 'quickfix_net, Version=1.0.2632.4101, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."

I recompiled the app for x86 so at least it works in compatibility mode but it's not optimal.  Trying to compile QF for x64 crashes VS2005.  If anyone resolved the issue I'd appreciate the info.

Thanks,

Francis

Re: [Quickfix-developers] session reset

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

FYI, we are adding support for local time in the next release.

--oren

On Mar 15, 2007, at 9:48 AM, Caleb Epstein wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> On 3/15/07, Nick Bilak <be...@gm...> wrote:
>> i have a problem of session being reset every day at 17:00EST
>> session is configured as weekly:
>>
>> StartTime=00:00:00
>> EndTime=00:00:00
>>
>> is my session config wrong or should i get updated version of  
>> quickfix?
>
> Those times are in GMT.  17:00 EST == midnight GMT.
>
> http://quickfixengine.org/quickfix/doc/html/configuration.html
>
> -- 
> Caleb Epstein

Re: [Quickfix-developers] session reset

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

On 3/15/07, Nick Bilak <be...@gm...> wrote:
> i have a problem of session being reset every day at 17:00EST
> session is configured as weekly:
>
> StartTime=00:00:00
> EndTime=00:00:00
>
> is my session config wrong or should i get updated version of quickfix?

Those times are in GMT.  17:00 EST == midnight GMT.

http://quickfixengine.org/quickfix/doc/html/configuration.html

-- 
Caleb Epstein

Re: [Quickfix-developers] Unit testing failing on Windows

[Matt H. <mat...@ya...>]

The password is set, I just removed it for this posting.

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

> What about your password?
> 
> --oren
> 
> On Mar 14, 2007, at 7:22 AM, Matt Hocker wrote:
> 
> > Sorry, meant to follow up to the entire list. Yes, I have set up  
> > ut.cfg. Here
> > is the file. FYI, I installed SQL Express 2005 with the named  
> > instance of
> > QUICKFIX.
> >
> > C:\quickfix\test\cfg>type ut.cfg
> > [DEFAULT]
> > #MySQLStoreDatabase=quickfix
> > #MySQLStoreUser=root
> > # MySQLStorePassword=[password]
> > #MySQLStoreHost=localhost
> > # MySQLStorePort=[port]
> >
> > #PostgreSQLStoreDatabase=quickfix
> > #PostgreSQLStoreUser=postgres
> > # PostgreSQLStorePassword=[password]
> > #PostgreSQLStoreHost=localhost
> > # PostgreSQLStorePort=[port]
> >
> > OdbcStoreUser=sa
> > # OdbcStorePassword=[password]
> > OdbcStoreConnectionString=DATABASE=quickfix;DRIVER={SQL
> > Server};SERVER=(local)\Q
> > UICKFIX;
> 
> 



 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

[Quickfix-developers] session reset

[Nick B. <be...@gm...>]

Hi,

i have a problem of session being reset every day at 17:00EST
session is configured as weekly:

StartTime=00:00:00
EndTime=00:00:00
StartDay=mo
EndDay=sa

 i am using quickfix 1.12.4 downloaded back in sept.06

is my session config wrong or should i get updated version of quickfix?


-- 
Regards,
    Nick.