RE: [Quickfix-developers] QuickFix (Java) does not logon?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

>> We are still developing with it.  I've found it a little bit difficult
at
>> times, but usually most of the core dumps and stuff are a result of
things
>> like instantiating fields with null values and such.  So far though,
it's
>> been able to do what we need.

Gary.  Can you please let us know the situations in which you get core
dumps.  We can certainly fix things like this.  The java interface,
particularly under solaris, is quite new and it looks like it is becoming
the popular choice. I would like us to handle such problems more gracefully
in the future, for instance by throwing a proper exception.  One thing we
need to start doing is to produce a unit test suite for java like the C++
one.

>> In comparison to Javelin, it does lack quite a bit.  First, it's not
really
>> a FIX engine in itself.  It just lets you build your own FIX engine.  It
>> doesn't have any built in API for an application to connect to a FIX
engine
>> and then send / receive messages.

Exactly right.  QuickFIX itself was designed as a core FIX API.  QuickFIX
could potentially be used as the fix processor for commercial FIX engines
that provide such functionality, making FIX engines easier and cheaper to
produce (and hopefully license) than before.  We also hope at some point to
start building such API's on top of QuickFIX in the future.  If your
company would allow you to submit some of your work that would probably
give us a push.  Also, sounds like making message serializable would go
along way.

>> Some other related missing
>> functionality is a local store for messages that the engine has received
>> for a given Session.  We need to store these messages in case our fix
>> engine gets the message, but the fromApp() doesn't successfully deliver
it
>> to our remote application.

Yeah.  The contract is that once your fromApp method returns, QuickFIX
believes you have now assumed responsibility
for that message.  We had made the decision not to store incoming messages
because it isn't strictly required by the protocol and can have a severe
performance penalty depending on what you are doing.  Probably not so bad
for flat files, but if you are using a database, the extra IO can be
significant.  It will most certainly add up if you are doing something like
processing a lot of large market data messages.

There is no reason that this can't be made into a configuration setting
however.

--oren

                      gary.mui@sungard.                                                                                                
                      com                      To:       "Alvin Wang" <xw...@qt...>                                        
                                               cc:       (bcc: Oren Miller/Corporate/ThoughtWorks/US)                                  
                      12/13/2002 10:08         Subject:  RE: [Quickfix-developers] QuickFix (Java) does not logon?                     
                      AM                                                                                                               

Hi Alvin,

We are still developing with it.  I've found it a little bit difficult at
times, but usually most of the core dumps and stuff are a result of things
like instantiating fields with null values and such.  So far though, it's
been able to do what we need.

In comparison to Javelin, it does lack quite a bit.  First, it's not really
a FIX engine in itself.  It just lets you build your own FIX engine.  It
doesn't have any built in API for an application to connect to a FIX engine
and then send / receive messages.  We're building that part ourselves using
RMI and an intermediate message object structure (since
org.quickfix.Message isn't serializable).  Some other related missing
functionality is a local store for messages that the engine has received
for a given Session.  We need to store these messages in case our fix
engine gets the message, but the fromApp() doesn't successfully deliver it
to our remote application.  But this may also be a positive since by
delivering just the libraries, people can build whatever application is
best suited for them.

Though these are somewhat big things, as I said, it does seem to do what we
need.  I also especially like the flexibility in being able to easily add
custom fields, use those custom fields in repeating groups, and also
customize the validation routines.  To do these things in Javelin, you need
a special build from them and you never really know how long that can take
for them to create for you.  We've at least heard these things from one of
your clients that use Javelin.  Of course, there's also the big issue that
in its cheapest form, the Appia engine costs something like $30K plus
annual license costs.

We will certainly be continuing to work with QuickFIX unless something else
fairly significant comes up - we have a production release planned for late
January.  The other good thing is that the mailing list (especially  Oren)
is a pretty good source for finding out issues and suggesting new things.
On the other hand, now that I remember, it did take me a while to finally
get all the packages and environment stuff straightened out so I could do a
clean Solaris build of QuickFIX.  But now I've got everything worked out
and am spending most of my time on calling the Java interface to send and
receive the messages we need.

Let me know what you guys decide and if you go with java interface in
QuickFIX, I'm sure we'll have things to share....

Thanks,

Gary Mui
Prescient Markets, Inc         914-989-3118  (W)
445 Hamilton Avenue          914-422-3693  (F)
White Plains, NY 10601

Please visit us at http://www.cpmarket.com

                    "Alvin Wang"

                    <xwang@qtechser        To:     <gar...@su...>

                    vices.com>             cc:

                                           Subject:     RE:
[Quickfix-developers] QuickFix (Java) does not logon?
                    12/13/02 10:45

                    AM

Hi! Gary, thanks again for your email. We are evaluating QuickFix. Compared
with Javelin, I think it is a little too simple and not stable. Could you
let me know your opinion regarding quickfix. Did you put it to production?
Do you have any problem using it?

Thanks so much!

Alvin