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 :))