quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] TargetCompID/SenderCompID in Logon

[Jeff B. <jef...@ya...>]

Sorry, meant TargetSubID and SenderSubID.

Caleb Epstein <cal...@gm...> wrote: On 11/2/06, Jeff Bartley  wrote:

> Is there a way to specify the TargetCompID and SenderCompID in the initial
> logon message?

Those are properties of the Session itself.  You need to specify them
in order to define a session in your configuration file.

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

-- 
Caleb Epstein


 
---------------------------------
Want to start your own business? Learn how on  Yahoo! Small Business. 

Re: [Quickfix-developers] TargetCompID/SenderCompID in Logon

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

On 11/2/06, Jeff Bartley <jef...@ya...> wrote:

> Is there a way to specify the TargetCompID and SenderCompID in the initial
> logon message?

Those are properties of the Session itself.  You need to specify them
in order to define a session in your configuration file.

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

-- 
Caleb Epstein

[Quickfix-developers] TargetCompID/SenderCompID in Logon

[Jeff B. <jef...@ya...>]

Is there a way to specify the TargetCompID and SenderCompID in the initial logon message?  

Looking through the code in Session.cpp my guess is, probably not.

Thanks,

Jeff Bartley

 
---------------------------------
Get your email and see which of your friends are online - Right on the  new Yahoo.com

Re: [Quickfix-developers] Cygwin

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

Hi Clebson,

Try running configure with --disable-shared --enable-static

then do a 'make clean all'

See if that helps.

--oren

On Nov 1, 2006, at 12:41 PM, Clebson Derivan wrote:

> Hello,
>
> I'm trying to compile the latest stable version  
> (quickfix-1.12.4.tar.gz)
> of quickfix with Cygwin and I'm getting some errors, someone can help
> me.

[Quickfix-developers] SocketNodelay

[<que...@bn...>]

Hello,

I inform you that the setting SocketNodelay (very useful) is not working
for "initiator" session.


Rgds,

Quentin.


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

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

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

[Quickfix-developers] Nik Volpe is out of the office.

[Nick V. <ni...@ad...>]

I will be out of the office starting  01/11/2006 and will not return until
06/11/2006.

I will have limited access to email so will respond to your message when I
return.  For urgent matters, please call +44 79 80 03 56 94.

Thanks.


Thanks.


**************************************************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any  unauthorized use of the information contained
in this email or its attachments is prohibited.  If this email is received in
error, please contact the sender and delete the material from your
computer systems. Do not use, copy, or disclose the contents of this
email or any attachments.
Abu Dhabi Investment Authority (ADIA) accepts no responsibility for
the content of this email to the extent that the same consists of
statements and opinions made which are the senders own and not
made on behalf of ADIA.  Nor does ADIA accept any liability for any
errors or omissions in the content of this email caused by electronic
and technical failures.
Although ADIA has taken reasonable precautions to ensure that no
viruses are present in this email, ADIA accepts no responsibility for
any loss or damage arising from the use of this email or its
attachments.
**************************************************************************************************************

Re: [Quickfix-developers] Compile error in Exceptions.h

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

>> Error        1       error C2664: 'FormatMessage' : cannot convert
parameter
>> 5 from 'char [2048]' to 'LPTSTR'
>> c:\source\quickfix\quickfix
>
> \include\quickfix\Exceptions.h    247


Brian,

It seems to be an error related to unicode.
You cannot compile quickfix with unicode.
Thus, in your project settings go to:

Configuration Properties | General | Character Set
and change it to Use Multi-Byte Character Set.

BR,
Djalma

On 10/31/06, Oren Miller <or...@qu...> wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Were you also trying to create a custom message?  Were you ever able
> to compile your project?
>
> --oren
>
> On Oct 31, 2006, at 2:22 AM, briancurtin wrote:
>
> > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> > html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> >
> > I'm seeing this same issue currently and I was wondering if Mike
> > Smith or
> > anyone else has come across it and would be willing to pass on a
> > hint or
> > two.
> >
> > I'm new to QuickFIX (and FIX on the whole) and this is the first
> > application
> > I'm writing from scratch, using the tradeclient example somewhat as
> > a guide
> > in places. Everything else in my project compiles fine, it's just
> > the error
> > that Mike has below is holding things back.
> >
> > Thanks,
> >
> > Brian Curtin
> >
> > What causes this FormatMessage error to
> >
> > Mike Smith-14 wrote:
> >>
> >> QuickFIX Documentation:
> >> http://www.quickfixengine.org/quickfix/doc/html/index.html
> >> QuickFIX Support: http://www.quickfixengine.org/services.html
> >>
> >> I'm currently writing a Session Acceptor program in Visual Studio
> >> 2005
> >> C++.  I wanted to create a custom message type to pass back to the
> >> initiator.  So, what I did was...
> >>
> >> 1.  Create a TraderLogon.h file under quickfix_vs8->Message->Message
> >> Header->fix42.
> >> 2.  Update MessageCracker.h under the same directory structure.
> >> 3.  Updated Values.h under Field Header Files directory.
> >>
> >> I then compiled quickfix_vs8 and everything was fine.
> >>
> >> I then went to compile my acceptor application and got the following
> >> error.
> >>
> >> Error        1       error C2664: 'FormatMessage' : cannot convert
> parameter
> >> 5 from 'char [2048]' to 'LPTSTR'
> >> c:\source\quickfix\quickfix\include\quickfix\Exceptions.h    247
> >>
> >> I couldn't figure out how to get past this, so I backed out all my
> >> changes and recompiled quickfix_vs8.  I then recompiled my acceptor
> >> application, but I still get the same error.
> >>
> >> I know this is pretty obscure, but does anyone know how I might
> >> get past
> >> this?
> >>
> >> Thanks,
> >>
> >> Mike
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Compile error in Exceptions.h

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

Were you also trying to create a custom message?  Were you ever able  
to compile your project?

--oren

On Oct 31, 2006, at 2:22 AM, briancurtin wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I'm seeing this same issue currently and I was wondering if Mike  
> Smith or
> anyone else has come across it and would be willing to pass on a  
> hint or
> two.
>
> I'm new to QuickFIX (and FIX on the whole) and this is the first  
> application
> I'm writing from scratch, using the tradeclient example somewhat as  
> a guide
> in places. Everything else in my project compiles fine, it's just  
> the error
> that Mike has below is holding things back.
>
> Thanks,
>
> Brian Curtin
>
> What causes this FormatMessage error to
>
> Mike Smith-14 wrote:
>>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> I'm currently writing a Session Acceptor program in Visual Studio  
>> 2005
>> C++.  I wanted to create a custom message type to pass back to the
>> initiator.  So, what I did was...
>>
>> 1.  Create a TraderLogon.h file under quickfix_vs8->Message->Message
>> Header->fix42.
>> 2.  Update MessageCracker.h under the same directory structure.
>> 3.  Updated Values.h under Field Header Files directory.
>>
>> I then compiled quickfix_vs8 and everything was fine.
>>
>> I then went to compile my acceptor application and got the following
>> error.
>>
>> Error	1	error C2664: 'FormatMessage' : cannot convert parameter
>> 5 from 'char [2048]' to 'LPTSTR'
>> c:\source\quickfix\quickfix\include\quickfix\Exceptions.h	247	
>>
>> I couldn't figure out how to get past this, so I backed out all my
>> changes and recompiled quickfix_vs8.  I then recompiled my acceptor
>> application, but I still get the same error.
>>
>> I know this is pretty obscure, but does anyone know how I might  
>> get past
>> this?
>>
>> Thanks,
>>
>> Mike

Re: [Quickfix-developers] Compile error in Exceptions.h

[briancurtin <bri...@gm...>]

I'm seeing this same issue currently and I was wondering if Mike Smith or
anyone else has come across it and would be willing to pass on a hint or
two.=20

I'm new to QuickFIX (and FIX on the whole) and this is the first applicatio=
n
I'm writing from scratch, using the tradeclient example somewhat as a guide
in places. Everything else in my project compiles fine, it's just the error
that Mike has below is holding things back.

Thanks,

Brian Curtin

What causes this FormatMessage error to=20

Mike Smith-14 wrote:
>=20
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> I'm currently writing a Session Acceptor program in Visual Studio 2005
> C++.  I wanted to create a custom message type to pass back to the
> initiator.  So, what I did was...
>=20
> 1.  Create a TraderLogon.h file under quickfix_vs8->Message->Message
> Header->fix42.
> 2.  Update MessageCracker.h under the same directory structure.
> 3.  Updated Values.h under Field Header Files directory.
>=20
> I then compiled quickfix_vs8 and everything was fine.
>=20
> I then went to compile my acceptor application and got the following
> error.
>=20
> Error=091=09error C2664: 'FormatMessage' : cannot convert parameter
> 5 from 'char [2048]' to 'LPTSTR'
> c:\source\quickfix\quickfix\include\quickfix\Exceptions.h=09247=09
>=20
> I couldn't figure out how to get past this, so I backed out all my
> changes and recompiled quickfix_vs8.  I then recompiled my acceptor
> application, but I still get the same error.
>=20
> I know this is pretty obscure, but does anyone know how I might get past
> this?
>=20
> Thanks,
>=20
> Mike
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20
>=20

--=20
View this message in context: http://www.nabble.com/Compile-error-in-Except=
ions.h-tf1626703.html#a7090112
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] Debug Assertion Failed when using getStore() method

[<pet...@em...>]

Hi all,

I have a problem with Session.lookupSession(sessionID).getStore() method to retrieve the MessageStore.
When I use this function in my code and it is called in the program, i get then the following debug error:

Debug Assertion Failed!

Program: .... name of the app
File: dbgdel.cpp
Line: 52

Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

For information on how your program can cause an assertion failure, see the Visual C++ documentaion on asserts.

Know someone, where could be problem? I'm developing the application in C# and method getStore() im calling in 

onMessage( QuickFix41.OrderCancelReject cancel_reject, SessionID sessionID)

where i want to find some information about original message, which I want to cancel.

Thanks for your help.

Petr

Re: [Quickfix-developers] How to stop quickfix validation?

[Ajay K. <Aja...@tr...>]

I don't know if the component/repeating group validation problem exists
in QuickFIX 1.12. I had to make a couple of fixes and a minor extension
to QF 1.11 source code (there wasn't a way to layer them on top) to make
it work for my project.  I submitted those source code changes since
they were generically useful, but since they weren't picked up it makes
the barrier to upgrade a little bit higher for me. I will certainly let
you know my results when I get the chance to reapply my changes to
current QuickFIX version and retest.

Regards,

- Ajay

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Tuesday, October 24, 2006 12:35 PM
To: Ajay Kamdar
Cc: San...@ub...; qui...@li...
Subject: Re: [Quickfix-developers] How to stop quickfix validation?


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

Do you have an example of this?  Does this problem still exist in 1.12?

--oren

> 2) The validation logic for nested repeating groups and components=20
> doesn't always work correctly in QF 1.11.1. I had submitted a patch to

> fix the validation logic a couple of months back, but I don't
> believe it
> got picked up. Once you get past #1, chances are you might run =20
> problems
> with QF's validation logic for nested repeating groups and components.
>
> HTH,
>
> - Ajay

-------------------------------------------------------------------------=
--

The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by anyone =
else
is unauthorized. If you are not the intended recipient, any disclosure, =
copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.

TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.

Re: [Quickfix-developers] Quickfix for FIX 5.0.....

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

First of all, there is some additional info (as you may have known)
http://www.fixprotocol.org/committees/gtc/documents
http://www.fixprotocol.org/documents/2943/FIX%205.0%20FAQs.doc

I am not sure if they will publish the repository files.

As long as the message can be delivered once, can be guaranteed delivery,
and in the right order, it can be on any non-FIX session for example MQ.
Another thing they talked is like a firm can use FIX 5 session to send an
order in FIX 4.2 and then allocate using FIX 4.4 for example.
(I think QF needs to think a way to make the application easily forward
compatible, for example how to reuse the existing application code using
quickfix.fix44 package work with FIX 5? and how to reuse the application
code to work on both FIX 44 and FIX 5 rather than rewriting the code using
"quickfix.fix5" package?)

Then there are concept of extension package and service pack.

Then some new support on the business side, like FX, advancement in order
routing, and regulatory initiatives......





                                                                           
             Oren Miller                                                   
             <oren@quickfixeng                                             
             ine.org>                                                   To 
                                       Alvin Wang <AW...@FF...>         
             10/28/2006 04:28                                           cc 
             PM                        Eranga                              
                                       <pe...@ri...>,      
                                       qui...@li... 
                                       ge.net,                             
                                       quickfix-developers-bounces@lists.s 
                                       ourceforge.net,                     
                                       qui...@li... 
                                       t,                                  
                                       <qui...@li.... 
                                       net>                                
                                                                   Subject 
                                       Re: [Quickfix-developers] Quickfix  
                                       for FIX 5.0.....                    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           



Do you know if they plan on freely distributing the repository or is
it still only going to be available to members only.  That's has been
a key problem with directly supporting the repository in the past, we
simply are not allowed to redistribute it as is.  If not we will
likely end up generating the QF data dictionary from the repository.
We have code that can do this assuming their format hasn't changed
significantly.

We do have plans to support FAST.  FIX 5.0 and FAST support are both
significant projects and we will need to prioritize to figure out
which we want to tackle first.

Any other information you have would be very useful.  Did they go
over any scenarios regarding the transport independence?  I was
wondering how it will effect resend requests.

--oren

On Oct 26, 2006, at 3:12 PM, Alvin Wang wrote:

> We went to FPL's Technology Focus Day 2006 today:
> http://www.fixprotocol.org/documents/2893/FPL_Technology_Focus_Day.pdf
>
> Besides transport independence framework and running different FIX
> versions
> on the same session, FIX 5 will use XML to organize repository (some
> similar to quickfix's xml dictionaries). Just wonder if QuickFIX and
> QuickFIX/J can leverage that directly. Another big thing is FAST
> protocol.
> Do QuickFIX and QuickFIX/J plan to support FAST?
>
> Thanks.





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

Re: [Quickfix-developers] Quickfix for FIX 5.0.....

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

We went to FPL's Technology Focus Day 2006 today:
http://www.fixprotocol.org/documents/2893/FPL_Technology_Focus_Day.pdf

Besides transport independence framework and running different FIX versions
on the same session, FIX 5 will use XML to organize repository (some
similar to quickfix's xml dictionaries). Just wonder if QuickFIX and
QuickFIX/J can leverage that directly. Another big thing is FAST protocol.
Do QuickFIX and QuickFIX/J plan to support FAST?

Thanks.



                                                                          =
=20
             Oren Miller                                                  =
=20
             <oren@quickfixeng                                            =
=20
             ine.org>                                                   To=
=20
             Sent by:                  Eranga                             =
=20
             quickfix-develope         <pe...@ri...>      =
=20
             rs-bounces@lists.                                          cc=
=20
             sourceforge.net           qui...@li...=
=20
                                       ge.net,                            =
=20
                                       qui...@li...=
=20
             10/25/2006 02:56          t                                  =
=20
             AM                                                    Subject=
=20
                                       Re: [Quickfix-developers] Quickfix =
=20
                                       for FIX 5.0.....                   =
=20
                                                                          =
=20
                                                                          =
=20
                                                                          =
=20
                                                                          =
=20
                                                                          =
=20
                                                                          =
=20



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

Well the first cut will be likely to use the Session Protocol as the first
supported transport for application messages.=A0 This can be implemented wi=
th
relatively little change to the architecture as it is pretty similar to how
the previous versions work already.=A0 This will require supporting the new
versioning constructs while maintaining backwards compatibility with the
old ones.=A0 There will probably have to be some changes to how data
dictionaries work, since I guess we will need two of them.

The first release of QF with 5.0 support will probably only implement
transporting application messages over the session protocol.=A0=A0After tha=
t I
suppose it will come down to the first viable use case of sending
application messages over a different transport.

--oren

On Oct 25, 2006, at 12:50 AM, Eranga Samararathna wrote:

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



      Hi,


      How is the quickfix / quickfixj preparation for FIX 5.0? Is quickfix
      need architecture change to address the new loosely coupled FIX
      application layer and FIX session layer?


      BR,


      Eranga


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1=
21642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers





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

Re: [Quickfix-developers] [Quickfix-users] Quickfix for FIX 5.0.....

[Nick E. <ni...@de...>]

Hi,

Well, actually the whole story of initial message was quite simple -- my =
eye caugth word architecture, not the subject. Thus, you've qualified it =
as blame... Why I didn't adopt quickfix/j? It was early beta those days =
and relplicates original quickfix design, hence also didn't provide =
batch processing, which is crucial (I don't like idea of processing =
messages one-by-one on any stage (even transport), sorry).

On other side what is nice for quickfix/j at least implementation =
details (synchronization issues/sequence reset) could be easily fixed by =
java developers that's a huge bonus as I think about 90% of quickfix =
deployments is java platform. And it's free from mistery sig segv =
crashes we've seen on sparc solaris (x86 linux was ok).

As for quoting/replying issue... You've just stole my words :). Would =
you read carefully my questions and your answers?

10mlns per sec transaction issue. Well yes, it was a trick from my side =
to show you how easy to missinterpret the opponent's words. Exactly what =
you've done.

Once again Don't you really think I'm spending my time posting here to =
down quickfix??? If so, you are wrong! It was attempt to share thoughts =
and expirience. You didn't like it. That's ok. The truth is that I like =
quickfix initiative (why do you think I'm still reading mail list?).=20

My words were taugh, but I've figured out that this is the only approach =
then things get stagnating... I'm sorry about that.





  ----- Original Message -----=20
  From: Oren Miller=20
  To: Nick Evgeniev=20
  Cc: qui...@li... ; =
qui...@li...=20
  Sent: Saturday, October 28, 2006 8:54 PM
  Subject: Re: [Quickfix-developers] [Quickfix-users] Quickfix for FIX =
5.0.....


  No Nick.  You bounded into the message board guns a blazin' attacking =
the project while thread-jacking a discussion of FIX 5.0 support, and =
then sleek into the role of the tempered rationalist when someone calls =
you on it.  You then use the boring old trick of cherry picking the =
points you want to respond to and completely removing the others =
entirely.  If I don't quote it it's like it never happened!  I don't =
need to justify my statement and I can make the other person look =
foolish at the same time!


  You're the guy that sucker punches someone then steps back and says =
"Whoa whoa, don't be so emotional, let's be rational about this." =
Classy.  You didn't come here for a rational exchange, you came to take =
potshots.


  If it's so easy, why you didn't take a couple days to adapt QuickFIX/J =
to your needs instead of writing a whole engine from scratch is rather =
curious.  But that's your choice.  If what you have works for you, =
that's great.  QuickFIX isn't for everyone.  You've made it very clear =
it's not for you.  You're not the first nor the last that will take a =
pass on QuickFIX.  Hopefully some day you will release your bounty unto =
the world.


  For the record, the number of transactions was meant to be total, not =
per session.  I make no claim of anyone processing 10,000,000 orders a =
second.  No one does that many.  The sentence was awkward and your =
interpretation is understandable, but was not the meaning I meant to =
convey.  Most of the systems I refer to run these sessions in a single =
process.  Point is that calling QuickFIX nothing more than a sandbox =
implementation is patently false.


  --oren


  On Oct 26, 2006, at 10:15 AM, Nick Evgeniev wrote:


    Hi,

    Thank you for such emotional answer I'll try to reply not to the =
emotions but facts
        1. quickfix does implicit transaction management passing fix =
messages one-by-one (transaction completed if client didn't trhow an =
exception). obviously while serving the message I have to perform =
tranaction in the database. hence we have obvious (just for me?) =
limitation on messages per second throughput. Hey, ma! where is the =
batches??? Even jms api has nice contract -- message.confirm(); =
confirming all the previousmessages received so far.


      Wrong. Wrong. Wrong.  Not even wrong. You have somehow come under =
the impression that QuickFIX is a message queuing product.  Let me be =
the first to dissuade you of that notion.  You want a transactional =
message queue?  Then stick the message in a transactional message queue. =
 There are lots of products out there that do that, QuickFIX isn't one =
of them. Users who build high performance systems do not want the added =
over head of a transactional message queue just because you can't figure =
out how to piece the two together.  Believe it or not, some who write =
high frequency trading systems have figured out how to do so without a =
message queue or a database.  I'll leave you to figure out how.
    You're missing the whole point. I'm not talking about storing =
messages in the database I'm talking about business transactions. They =
are about to happen somethere either in sync or async way, right? Hence =
the point was that quickfix doesn't make things easier in this way, =
because I have to use another abstraction to do batching. Please read it =
literally -- "I want to do batch insert at the end of the chain to =
insert 1000 orders in database at once". The only working solution with =
quickfix is to route it's messages somethere to perform async =
processing. Hence to use it not like queue but rather like transport =
adapter... You also pointed this out but in very inpolite manner. Such =
infrastructure involves a couple of rmi calls which also slows things =
down. It's always a good position to tell -- hey you're an idiot we've =
provided you a tool that is just a trasport! don't expect more. But may =
I ask you a question? Is architecture I'm describing would be harder to =
implement? Would it result bigger code? (I would not say for c++ but in =
java the code will be even simpler:)) As result you will have much more =
flexible product.

      Organizations like Reuters, CME, Pipeline, optionsXpress and many =
others have built massive systems with QuickFIX which run hundreds of =
simultaneous sessions processing hundreds or thousands of messages per =
second.  The fact that you can't only speaks to your incompetence.  =
Please. Leave QuickFIX out of it.
    100 * 100 * 1000 =3D=3D 10 000 000 optionsXpress is able to process =
10 millions orders per second? don't make my shoes laugh :)

    Jumping on person is your style right? Is it because of lacking =
arguments? Do you know how many boxes do they use to handle it? Do you =
know why? because if you use fixengine just as transport  you have to =
build/buy messaging infrastracture set several boxes to perform task =
that could be done just by one blade server... Sometimes you don't care =
about it sometimes you do.
        2. Broken push message model implementation: thread in native =
code holding the lock while propagating message to java. get deadlock =
prone code as a bonus right? It's easy to fix but much better to have =
pull message model.


      Broken is highly exaggerated and isn't born out in the field.  =
Since you say it's easy to fix it is surprising you bring this up as a =
major issue and even more surprising you've not submitted a patch.
    It was not a top issue it's just an annoying implementation detail. =
And I'm not a c++ developer. just java. sorry. But basicly all you need =
is not to hold monitor while calling java code, but use lock idiom -- =
flag checking under the mutex.

        3. Never ending reset sequence fixes which are just never =
working right in all (valid) cases.


      Most of the reset scenarios have been fixed.  Almost nobody =
notices bugs here because almost nobody uses this functionality.  One =
person who did, you, didn't do anything to help the situation. Not all =
scenarios have been implemented because no one is really demanding them. =
 We went for years without any reset support and no one even noticed. =20
    Everything is quite simple. Nobody warns me neither in documentation =
nor other way. Hey, dude! our reset sequence code is alpha qaulity use =
it on your own risk. It was kind of surprise to me.. and finally decison =
was made to get rid of quickfix because of the reason #1 not #3.
      I'll tell you what's going on here Nick.  You made some promises =
to deliver, you failed, and now QuickFIX is going to be the fall guy.  =
It took you 6 months to figure out that QuickFIX didn't meet your needs? =
 That's some evaluation, did someone pay for you to waste all that time?
    Probably you do have god's number because you know things you're not =
supposed to know. would you send it to me? Yes I was paid because =
solution with qf was developed in about a month, most time of which were =
spent on integration issues. And it was working ok... But finally we =
decided to develop ourown implementation in pure java that is why I'm =
talking about six month...



      QuickFIX is designed to meet the needs of thousands of users.  It =
is designed to be portable, works with standard and broken =
implementation of the FIX protocol, integrates with any database, file =
storage, custom storage, custom and out of the box logging, has a web =
interface, documentation, tons of settings, is written in portable C++ =
that compiles under many compilers on many operating systems.  It builds =
right out of the box and also comes in pre-built binaries for windows.  =
It has APIs in C++, Java, .NET, Ruby and Python plus a full from scratch =
pure Java implementation. That's just for starters. It's been in =
production use for 5 years and has, let me just say, an astounding =
amount of production implementations by an even more astounding group of =
well respected financial companies.                                      =
                                              .
    Probably this should be output to log on startup to prevent =
complains :)
      So you can write an implementation in a single platform that meets =
your specific needs designed to fit into your exact architecture.  Big =
deal hotshot.
    java is supposed to work on many platforms :)... bigdeal?
      I'm sorry to hear that your leaving, but Don't worry about us =
Nick.  From now on everyone on the list will look to what someone once =
posted on this very list as our guiding inspiration.


      "as for everything else -- just keep moving! quickfix rocks :)"
          -- Nick Evgeniev (May 31, 2005)
    I don't reclaim my words :)... Keep moving! change it to be more =
high performant, as changes are not as expensive :))

Re: [Quickfix-developers] [Quickfix-users] Quickfix for FIX 5.0.....

[Nick E. <ni...@de...>]

Hi,

Thank you for such emotional answer I'll try to reply not to the =
emotions but facts
    1. quickfix does implicit transaction management passing fix =
messages one-by-one (transaction completed if client didn't trhow an =
exception). obviously while serving the message I have to perform =
tranaction in the database. hence we have obvious (just for me?) =
limitation on messages per second throughput. Hey, ma! where is the =
batches??? Even jms api has nice contract -- message.confirm(); =
confirming all the previous messages received so far.


  Wrong. Wrong. Wrong.  Not even wrong. You have somehow come under the =
impression that QuickFIX is a message queuing product.  Let me be the =
first to dissuade you of that notion.  You want a transactional message =
queue?  Then stick the message in a transactional message queue.  There =
are lots of products out there that do that, QuickFIX isn't one of them. =
Users who build high performance systems do not want the added over head =
of a transactional message queue just because you can't figure out how =
to piece the two together.  Believe it or not, some who write high =
frequency trading systems have figured out how to do so without a =
message queue or a database.  I'll leave you to figure out how.
You're missing the whole point. I'm not talking about storing messages =
in the database I'm talking about business transactions. They are about =
to happen somethere either in sync or async way, right? Hence the point =
was that quickfix doesn't make things easier in this way, because I have =
to use another abstraction to do batching. Please read it literally -- =
"I want to do batch insert at the end of the chain to insert 1000 orders =
in database at once". The only working solution with quickfix is to =
route it's messages somethere to perform async processing. Hence to use =
it not like queue but rather like transport adapter... You also pointed =
this out but in very inpolite manner. Such infrastructure involves a =
couple of rmi calls which also slows things down. It's always a good =
position to tell -- hey you're an idiot we've provided you a tool that =
is just a trasport! don't expect more. But may I ask you a question? Is =
architecture I'm describing would be harder to implement? Would it =
result bigger code? (I would not say for c++ but in java the code will =
be even simpler:)) As result you will have much more flexible product.

  Organizations like Reuters, CME, Pipeline, optionsXpress and many =
others have built massive systems with QuickFIX which run hundreds of =
simultaneous sessions processing hundreds or thousands of messages per =
second.  The fact that you can't only speaks to your incompetence.  =
Please. Leave QuickFIX out of it.
100 * 100 * 1000 =3D=3D 10 000 000 optionsXpress is able to process 10 =
millions orders per second? don't make my shoes laugh :)

Jumping on person is your style right? Is it because of lacking =
arguments? Do you know how many boxes do they use to handle it? Do you =
know why? because if you use fixengine just as transport  you have to =
build/buy messaging infrastracture set several boxes to perform task =
that could be done just by one blade server... Sometimes you don't care =
about it sometimes you do.
    2. Broken push message model implementation: thread in native code =
holding the lock while propagating message to java. get deadlock prone =
code as a bonus right? It's easy to fix but much better to have pull =
message model.


  Broken is highly exaggerated and isn't born out in the field.  Since =
you say it's easy to fix it is surprising you bring this up as a major =
issue and even more surprising you've not submitted a patch.
It was not a top issue it's just an annoying implementation detail. And =
I'm not a c++ developer. just java. sorry. But basicly all you need is =
not to hold monitor while calling java code, but use lock idiom -- flag =
checking under the mutex.

    3. Never ending reset sequence fixes which are just never working =
right in all (valid) cases.


  Most of the reset scenarios have been fixed.  Almost nobody notices =
bugs here because almost nobody uses this functionality.  One person who =
did, you, didn't do anything to help the situation. Not all scenarios =
have been implemented because no one is really demanding them.  We went =
for years without any reset support and no one even noticed. =20
Everything is quite simple. Nobody warns me neither in documentation nor =
other way. Hey, dude! our reset sequence code is alpha qaulity use it on =
your own risk. It was kind of surprise to me.. and finally decison was =
made to get rid of quickfix because of the reason #1 not #3.
  I'll tell you what's going on here Nick.  You made some promises to =
deliver, you failed, and now QuickFIX is going to be the fall guy.  It =
took you 6 months to figure out that QuickFIX didn't meet your needs?  =
That's some evaluation, did someone pay for you to waste all that time?
Probably you do have god's number because you know things you're not =
supposed to know. would you send it to me? Yes I was paid because =
solution with qf was developed in about a month, most time of which were =
spent on integration issues. And it was working ok... But finally we =
decided to develop ourown implementation in pure java that is why I'm =
talking about six month...



  QuickFIX is designed to meet the needs of thousands of users.  It is =
designed to be portable, works with standard and broken implementation =
of the FIX protocol, integrates with any database, file storage, custom =
storage, custom and out of the box logging, has a web interface, =
documentation, tons of settings, is written in portable C++ that =
compiles under many compilers on many operating systems.  It builds =
right out of the box and also comes in pre-built binaries for windows.  =
It has APIs in C++, Java, .NET, Ruby and Python plus a full from scratch =
pure Java implementation. That's just for starters. It's been in =
production use for 5 years and has, let me just say, an astounding =
amount of production implementations by an even more astounding group of =
well respected financial companies.                                      =
                                              .
Probably this should be output to log on startup to prevent complains :)
  So you can write an implementation in a single platform that meets =
your specific needs designed to fit into your exact architecture.  Big =
deal hotshot.
java is supposed to work on many platforms :)... bigdeal?
  I'm sorry to hear that your leaving, but Don't worry about us Nick.  =
>From now on everyone on the list will look to what someone once posted =
on this very list as our guiding inspiration.


  "as for everything else -- just keep moving! quickfix rocks :)"
      -- Nick Evgeniev (May 31, 2005)
I don't reclaim my words :)... Keep moving! change it to be more high =
performant, as changes are not as expensive :))

Re: [Quickfix-developers] logonTimedOut and logoutReason

[EclipseCap <tob...@ec...>]

Oren,

Thank you for that information.  I am glad that it wasn't there rather than
myself not finding it.

Thanks,

Tim




Tim.

Currently the logging is generally the only thing that gives a reason  
why something like this happens.  You can, if you like, implement  
your own logger to receive these messages through callbacks if you  
like. There isn't any sort of enumeration that is really understood  
by an application all that well since it is just text.  For instance,  
the logger will record "Timed out waiting for logon response" in this  
scenario.

At this point, just about any reason QF has for disconnecting that it  
knows about, there will be some message in the log indicating the  
reason.  You may not be so lucky in knowing why the other side  
disconnected.  Their maching may have shut down, they may have forced  
the socket closed, taken the machine down, received a sequence number  
that is too low or you sent the wrong comp id (at which point they  
are permitted by the spec to just disconnect you).  In some scenarios  
they may send you a logout message with a reason in the text field,  
but again it is not really reliably parsable by a machine.

I'm not sure what you mean by knowing that "QuickFIX has stopped  
trying".  Do you just mean for that particular connection attempt?   
Unless you tell it otherwise, QuickFIX will continue trying  
indefinitely as long as it is within the defined session time.  The  
configuration has settings for changing the reconnect interval, as  
well as the logon timeout.  This timeout refers to the time it sends  
a Logon to the time it expects the response.  If it fails to receive  
the logon response in this time frame, it will close the connection  
and retry at the next reconnect interval.

--oren

On Oct 25, 2006, at 5:01 PM, EclipseCap wrote:

> I am trying to capture logonTimedOut function.  I am not having  
> trouble
> connecting, but when I do I want my application to know that  
> QuickFix has
> stopped trying.
>
> I also want to grab the reason why the session was disconnected.   
> Either
> initiated by the client or server.
>
> I am sure it is right in front of me and I am just missing it.
>
> Thanks,
>
> Tim


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-- 
View this message in context: http://www.nabble.com/logonTimedOut-and-logoutReason-tf2510463.html#a7011187
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] Configuration failed: ../spec/FIX42.xml: Could not parse data dictionary file

[Parthosarathi K. <par...@gm...>]

hi,

i am fairly new to quickfix. to understand quickfix i have started with the
example applications (tradeclient ,executor and the ordermatch) the client
application seems to work fine but when ever i run the server applications
(ordermatch and executor) the code breaks down on further debugging the
application's code it gives me the following error



Configuration failed: ../spec/FIX42.xml: Could not parse data dictionary
file



could anyone throw some light on this issue as i have checked that the
FIX42.xml file is present but still cannot be read.
-- 
Regards
parthosarathi

[Quickfix-developers] qf crashes on logout callback

[H. S. <st...@un...>]

hi oren,

it seems that the logout callback is triggered too late on "irregular"
disconnections.
if e.g. you get a timeout while waiting for a logon response or timeout
waiting for a reply on a test request, the logout callback is triggered
normally. if you try to access data from the sessionid - e.g.
sessionID.getSenderCompID().getValue() - quickfix crashes.

seems like the session was removed before the callback is triggered
(this is just an assumption as i did not investigate code)



thread(135282688):
  at Session::lookupSession(Session.cpp:1448)
thread(135544832):
  at process_sleep(Utility.cpp:501)
  at ThreadedSocketInitiator::onStart(ThreadedSocketInitiator.cpp:76)
  at Initiator::startThread(Initiator.cpp:302)
thread(135545856):
  at ThreadedSocketConnection::read(ThreadedSocketConnection.cpp:81)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
thread(135586816):
  at socket_close(Utility.cpp:170)
  at
ThreadedSocketConnection::disconnect(ThreadedSocketConnection.cpp:72)
  at Session::disconnect(Session.cpp:542)
  at Session::next(Session.cpp:122)
  at ThreadedSocketConnection::read(ThreadedSocketConnection.cpp:81)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
thread(135599104):
  at ThreadedSocketConnection::read(ThreadedSocketConnection.cpp:81)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
thread(135822336):
  at Initiator::setDisconnected(Initiator.cpp:157)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
zsh: abort (core dumped)



let me know if i can help.

cheers,
heri
hi oren,

it seems that the logout callback is triggered too late on "irregular"
disconnections.
if e.g. you get a timeout while waiting for a logon response or timeout
waiting for a reply on a test request, the logout callback is triggered
normally. if you try to access data from the sessionid - e.g.
sessionID.getSenderCompID().getValue() - quickfix crashes.

seems like the session was removed before the callback is triggered
(this is just an assumption as i did not investigate code)



thread(135282688):
  at Session::lookupSession(Session.cpp:1448)
thread(135544832):
  at process_sleep(Utility.cpp:501)
  at ThreadedSocketInitiator::onStart(ThreadedSocketInitiator.cpp:76)
  at Initiator::startThread(Initiator.cpp:302)
thread(135545856):
  at ThreadedSocketConnection::read(ThreadedSocketConnection.cpp:81)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
thread(135586816):
  at socket_close(Utility.cpp:170)
  at
ThreadedSocketConnection::disconnect(ThreadedSocketConnection.cpp:72)
  at Session::disconnect(Session.cpp:542)
  at Session::next(Session.cpp:122)
  at ThreadedSocketConnection::read(ThreadedSocketConnection.cpp:81)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
thread(135599104):
  at ThreadedSocketConnection::read(ThreadedSocketConnection.cpp:81)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
thread(135822336):
  at Initiator::setDisconnected(Initiator.cpp:157)
  at
ThreadedSocketInitiator::socketThread(ThreadedSocketInitiator.cpp:203)
zsh: abort (core dumped)



let me know if i can help.

cheers,
heri

Re: [Quickfix-developers] [Quickfix-users] Quickfix for FIX 5.0.....

[Nick E. <ni...@de...>]

Hi,

I'm neither selling nor advertising our engine, just stating the fact. =
If you think that my points aren't valid just tell me where I'm wrong. =
Probably commercial engines are much worse than quickfix just  don't =
know, haven't tried them.
I can just repeat mine:

1. quickfix does implicit transaction management passing fix messages =
one-by-one (transaction completed if client didn't trhow an exception). =
obviously while serving the message I have to perform tranaction in the =
database. hence we have obvious (just for me?) limitation on messages =
per second throughput. Hey, ma! where is the batches??? Even jms api has =
nice contract -- message.confirm(); confirming all the previous messages =
received so far.

2. Broken push message model implementation: thread in native code =
holding the lock while propagating message to java. get deadlock prone =
code as a bonus right? It's easy to fix but much better to have pull =
message model.

3. Never ending reset sequence fixes which are just never working right =
in all (valid) cases.

4. At least as of version 1.11.* native code crashes (or silent death of =
acceptor thread) on invalid messages in login phase.

5. Last but not the least -- very GC unfriendly. shure it's not the =
issue until you implement batches, or explicit transaction management.
  ----- Original Message -----=20
  From: Oren Miller=20
  To: Nick Evgeniev=20
  Cc: Eranga Samararathna ; qui...@li... ; =
qui...@li...=20
  Sent: Wednesday, October 25, 2006 7:05 PM
  Subject: Re: [Quickfix-users] Quickfix for FIX 5.0.....


  Great points Nick.  If anyone wants a real fix engine, contact =
ni...@de....


  --oren


  On Oct 25, 2006, at 9:37 AM, Nick Evgeniev wrote:


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


    Hi,

    don't know about fix 5.0
    quickfix obviously needs architecture changes in it's current state =
it suited well only for fix sandboxes, as it has no explicit transaction =
management, hence it has no batching operations. it has brokenly =
designed synchronization and as a bonus has numerous errors in reset =
sequence handling and unexpected crashes in native code in connection =
handling.
    The last two issues are implementation details, but the first two =
are crucial for high volume transaction processing.
    We'd been evaluating quickfix for about half year, but finally =
decided to drop it in favor of homegrown engine because of issues I've =
written above.
    Just wonder that nowadays, after all the litrechure regarding =
highspeed message parsing available for $30 bucks at amazon, we have =
such brokenly designed product :(

Re: [Quickfix-developers] logonTimedOut and logoutReason

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

Tim.

Currently the logging is generally the only thing that gives a reason  
why something like this happens.  You can, if you like, implement  
your own logger to receive these messages through callbacks if you  
like. There isn't any sort of enumeration that is really understood  
by an application all that well since it is just text.  For instance,  
the logger will record "Timed out waiting for logon response" in this  
scenario.

At this point, just about any reason QF has for disconnecting that it  
knows about, there will be some message in the log indicating the  
reason.  You may not be so lucky in knowing why the other side  
disconnected.  Their maching may have shut down, they may have forced  
the socket closed, taken the machine down, received a sequence number  
that is too low or you sent the wrong comp id (at which point they  
are permitted by the spec to just disconnect you).  In some scenarios  
they may send you a logout message with a reason in the text field,  
but again it is not really reliably parsable by a machine.

I'm not sure what you mean by knowing that "QuickFIX has stopped  
trying".  Do you just mean for that particular connection attempt?   
Unless you tell it otherwise, QuickFIX will continue trying  
indefinitely as long as it is within the defined session time.  The  
configuration has settings for changing the reconnect interval, as  
well as the logon timeout.  This timeout refers to the time it sends  
a Logon to the time it expects the response.  If it fails to receive  
the logon response in this time frame, it will close the connection  
and retry at the next reconnect interval.

--oren

On Oct 25, 2006, at 5:01 PM, EclipseCap wrote:

> I am trying to capture logonTimedOut function.  I am not having  
> trouble
> connecting, but when I do I want my application to know that  
> QuickFix has
> stopped trying.
>
> I also want to grab the reason why the session was disconnected.   
> Either
> initiated by the client or server.
>
> I am sure it is right in front of me and I am just missing it.
>
> Thanks,
>
> Tim

Re: [Quickfix-developers] The open approach (was Re: Quickfix for FIX 5.0)

[Clive M. <cl...@va...>]

On Thursday 26 October 2006 00:32, Graham Miller wrote:

> As long-time users of QuickFIX, we felt we needed to respond, given
> that we believe your opinion part of a very small minority.  

Well said, Graham. Having worked with 2 other closed-source Fix engines, give 
me QuickFix any day of the week.

Regards

Clive
-- 
Clive Messer <cl...@va...>

[Quickfix-developers] The open approach (was Re: Quickfix for FIX 5.0)

[Graham M. <gm...@ma...>]

Nick,

As long-time users of QuickFIX, we felt we needed to respond, given
that we believe your opinion part of a very small minority.  Your
objections are too vague to be sure, but it seems that your
displeasure with QuickFIX may stem from an impedance mismatch between
what QuickFIX currently aims to deliver and what you need to implement
your trading system.  This is certainly the forum to discuss these
issues.

However, it makes absolutely no sense to us why anyone would drop
QuickFIX entirely, given the size of the FIX specification and the
very permissive license under which QuickFIX is distributed. Do not
like the networking code? Swap in your own.  Need a Delphi API? Add
one. The fact that you have chosen to toss the thousands of hours of
work that have been contributed to the QuickFIX project, so that you
can re-implement it all yourself seems to indicate that you have not
done the cost-benefit analysis very carefully.

The implementation details of sequence reset handling and crashes have
recently garnered a fair amount of traffic on the mailing lists
(perhaps this is why you are so acutely aware of them).  To us this
only shows the strength of the process.  We have no reason to believe
that closed-source commercial implementations like the one you're
proposing have any fewer defects--indeed we have seen a few with many
more defects--and they lack the facility for peer review that we value
in QuickFIX.

We have placed our bets on the open approach, and we do not envy you
the long hard road ahead.

graham
and the Marketcetera team

-- 
Marketcetera Trading Platform
download.run.trade.
www.marketcetera.org

On Oct 25, 2006, at 9:37 AM, Nick Evgeniev wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> don't know about fix 5.0
> quickfix obviously needs architecture changes in it's current state
> it suited well only for fix sandboxes, as it has no explicit
> transaction management, hence it has no batching operations. it has
> brokenly designed synchronization and as a bonus has numerous
> errors in reset sequence handling and unexpected crashes in native
> code in connection handling.
> The last two issues are implementation details, but the first two
> are crucial for high volume transaction processing.
> We'd been evaluating quickfix for about half year, but finally
> decided to drop it in favor of homegrown engine because of issues
> I've written above.
> Just wonder that nowadays, after all the litrechure regarding
> highspeed message parsing available for $30 bucks at amazon, we
> have such brokenly designed product :(
>

[Quickfix-developers] logonTimedOut and logoutReason

[EclipseCap <tob...@ec...>]

I am trying to capture logonTimedOut function.  I am not having trouble
connecting, but when I do I want my application to know that QuickFix has
stopped trying. 

I also want to grab the reason why the session was disconnected.  Either
initiated by the client or server.

I am sure it is right in front of me and I am just missing it.

Thanks,

Tim

-- 
View this message in context: http://www.nabble.com/logonTimedOut-and-logoutReason-tf2510463.html#a7001312
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] [Quickfix-users] Quickfix for FIX 5.0.....

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

The body and session files are not log files.  You need to pass a  
logger to the initiator.

--oren

> I'm finding that when I specify some socketconnecthosts, then  
> ToAdmin will fire after I start the initiator.  However, for other  
> socketconnecthosts ToAdmin never fires.  Is there any way to debug  
> this?  I don't seem to be getting any relevant log messages -- the  
> body and session log files are empty.  I'm in vb.net.
>
> thank you in advance

Re: [Quickfix-developers] [Quickfix-users] Quickfix for FIX 5.0.....

[cstrader <cst...@cs...>]

I'm finding that when I specify some socketconnecthosts, then ToAdmin =
will fire after I start the initiator.  However, for other =
socketconnecthosts ToAdmin never fires.  Is there any way to debug this? =
 I don't seem to be getting any relevant log messages -- the body and =
session log files are empty.  I'm in vb.net.

thank you in advance


  ----- Original Message -----=20
  From: Oren Miller=20
  To: Nick Evgeniev=20
  Cc: qui...@li...=20
  Sent: Wednesday, October 25, 2006 11:27 AM
  Subject: Re: [Quickfix-developers] [Quickfix-users] Quickfix for FIX =
5.0.....


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




-------------------------------------------------------------------------=
-----


  Great points Nick.  If anyone wants a real fix engine, contact =
ni...@de....


  On Oct 25, 2006, at 9:37 AM, Nick Evgeniev wrote:


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


    Hi,

    don't know about fix 5.0
    quickfix obviously needs architecture changes in it's current state =
it suited well only for fix sandboxes, as it has no explicit transaction =
management, hence it has no batching operations. it has brokenly =
designed synchronization and as a bonus has numerous errors in reset =
sequence handling and unexpected crashes in native code in connection =
handling.
    The last two issues are implementation details, but the first two =
are crucial for high volume transaction processing.
    We'd been evaluating quickfix for about half year, but finally =
decided to drop it in favor of homegrown engine because of issues I've =
written above.
    Just wonder that nowadays, after all the litrechure regarding =
highspeed message parsing available for $30 bucks at amazon, we have =
such brokenly designed product :(





-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  Using Tomcat but need to do more? Need to support web services, =
security?
  Get stuff done quickly with pre-integrated technology to make your job =
easier
  Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
  =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642


-------------------------------------------------------------------------=
-----


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