Re: [Quickfix-users] QuickFIXEngine user experience

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

Hi,


>> When runs as a client (initiator) does not handle properly out of sync 
>> message sequence situation regardless config settings (see bug #19 it 
>> seems to be there for ages).
>
> OK, there is a patch attached. Does it work for you?

Actually, I've found this bug right after fixing this bug.. My fix is quite 
simple I'm adding reset flag to logon message on application side i.e. 
within toAdmin() message call.

>> When runs as server thread accepting connections silently exits on 
>> unknown fields in login message.
>
> Hmmm, could you provide more details here?

Yes. I was trying to logon with Username & Password fields set to fix4.2 
session, w/o adding such fields to the spec first... After such attempt 
quickfix stops from listenning socket.

>> java port does not deal properly with classloaders.
>
> Java API, the (pure) Java port of Steve Bates is in CVS. This is bug 58 
> with patches attached. I did not find time to have a closer look at it, 
> but it will make using QF with JBoss (and other application server) and 
> eclipse much easier.

Actually I was talking about java + native part port. Don't know how to name 
it in case of pure java port presens. The bug is quite simple -- once you 
have either Acceptor or Initiator started, quickfix starts new internal 
thread w/o saving context class loader or at least classloader which has 
loaded Acceptor/Initiator... Later when calls from this thread are made to 
parse incoming messages, system classloader is being used. Hence you can get 
ClassNotFoundException for newly loaded classes.. Right now I'm 
workarounding this by restoring original classloader in fromApp() call..

There is yet another bug (or feature) that may be an issue in multithreaded 
application using quickfix... Quickfix holds a session lock while 
dispatching new message (preventing other threads from sending concurrent 
messages) so if you have to synchronize dispatching thread with another 
thread which in turn also may send a message -- you have a deadlock.. There 
are several fixes for this problem -- either write clearly in docs about 
threading issues, or inject lock management from quickfix core, or at least 
make such locks accessible for application. The last approach has an 
advantage as it would not break existing quickfix applications.