During quickfix adoption for one of the projects I've been consulting I've
found the following bugs (or issues):
1. quickfix uses atof() function for parsing doubles which is locale aware.
So on systems having locale with decimal separator other than dot all
doubles will be silently stripped to its whole part only (i.e. 1.32 becomes
1.00 and so on). Even more atof() will convert everything starting with a
digit to double giving you no knowledge if it's actually not a double at all
(i.e. 1.1haba will be converted to 1.1)
locale solution: quickfix must use setlocale() to set it's locale to C or
en_US. a quick workaround on unix platforms is to export either LC_ALL=C or
LC_NUMERIC=C prior to running quickfix application.
parsing solution: use strtod() instead of atof() to parse doubles. it gives
you the pointer to a char at which parsing has stopped. If it's zero --
everything is ok. It will do more strict double conversion which I belive is
essential for trading app :)
2. thread safety. quickfix has implicit thread safety i.e. it perform
internal synchronization on Session.sendToTarget() (it's java syntax). While
it does simplify the things for simpliest cases it also leads to deadlocks
if application tries to do extra synchronization between streams. So it
would be better if quickfix is either does no synchronization at all leaving
everything to developer or does export internal mutexes via getSessionLock()
or something alike.
3. Thread context ClassLoader issue with java port. quickfix starts internal
thread when user calls Acceptor.start(), or Initiator.start(), but it does
not save thread context class loader, so later when you're trying to create
classes accessible from this classloader as a consequnce of MessageCracker
call ClassNotFound Exception will be thrown.
solution: remeber thread context classloader in started thread (yet better
deligate thread creation and running to client application).
workaround: save thread context classloader and restore it manually.
4. Quickfix stops accepting connections on unexpected fields in logon
message. I was lucky enough to send logon message to quickfix server with
username/password fields set w/o adding them to fix-spec first. The reaction
was amazing -- quickfix just stopped listening on its port w/o any error.
solution: well.. what do you expect me to say? :) the server must be robust
that's it. nothing should stop it from working except explicit kill. :)
5. Actuallly is a request for enhancement -- it might be a good idea to
provide set of extensible converters to do backward message conversion i.e.
(fix44.ExecutionReport to fix43.ExecutionReport and so on) otherwise (I
think) everybody's writing such converters by their own.
ps: as for everything else -- just keep moving! quickfix rocks :)