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