RE: [Quickfix-developers] [qfj] Publishing Messages to JMS

[Steve B. <st...@te...>]

> Brad Harvey wrote:
> The DataDictionary class isn't serializable, and messages keep a
> reference to this class which causes a java.io.NotSerializableException:
> quickfix.DataDictionary when I try to publish to JMS.
> 
> There's nothing stopping the DataDictionary and dependent classes from
> being made Serializable, but it may not be desirable to be sending this
> on every message.  I notice Message's clone method has been overridden
> to not copy the data dictionary, so this can be used to workaround the
> problem.  What impact will this have when I go to actually trying to use
> the message on the other side of the JMS queue?  I haven't got to the
> stage of trying messages with repeating groups yet.

Hi Brad,

This is a bug. We have unit tests for message serialization but the
data dictionary is always null so it doesn't cause a problem. That 
the problem when not doing test-first development. :-) It appears the
data dictionary might only be used for message parsing. If so, I'm
not sure if we need to keep a reference to it or not. I'll look into
some more after modifying the unit test.

Can you add a bug report for this?

http://www.quickfixengine.org/bugtracker/
 
> Many of the Serializable classes are missing serialVersionUID fields.  I
> think this is only a practical problem if you're using different
> compiled classes on either side of the serialization (I was initially
> publishing with eclipse compiled classes and receiving with the ant
> built jar and ran into some serialVersionUID mismatch problems).

I see the Field, FieldMap, and the FieldOrderComparator inner class
are missing serialVersionUIDs. I'll add those. Were there other classes
that were causing you problems?

> I wanted to be able to pick up the data dictionaries from my classpath.
> DefaultSessionFactory tries to load using FileInputStream(path) with no
> easy way to plug in something else.  As a temporary workaround I have
> replaced this with a Spring resource loader:
> 
>      	ResourceLoader defaultResourceLoader = new
> DefaultResourceLoader();
>       dataDictionary = new
> DataDictionary(defaultResourceLoader.getResource(path).getInputStream())
> ;

The constructor that takes a string for the filename will try to load
the data dictionary from either a URL or a file path. This was, more
or less, the intent of the JNI data dictionary API. The constructor
taking the input stream was intended to be used for the purpose you
describe above and for testing. At some point I'd like to add a data
dictionary locator class that encapsulates the mechanisms 
for finding data dictionaries.
 
> I can now specify the data dictionary location as classpath:FIX42.xml to
> pick it up from the classpath, FIX42.xml to read from file, or even
> http://www.quickfixengine.org/FIX42.xml if I want to eat up some
> bandwidth :)  Obviously this approach isn't directly suitable for
> quickfixj unless you want to add Spring as a dependency.  Perhaps a
> pluggable DataDictionaryFactory would be helpful?

The string based constructor should already be able to load data
dictionaries using HTTP. Opening a stream for a java.net.URL is
the first technique the data dictionary class attempts to use to
load it's data. The FileInputStream is the backup strategy. It's
a hassle with Java, but you could actually write a "classpath:" 
URL handler and use the existing URL-based constructor. The way
you are doing it probably easier.
 
> quickfix.SocketInitiator.onPoll() throws a ClassCastException if it gets
> a Session object from the event queue - it needs the same instanceof
> checks as onBlock().
> 
> quickfix.netty.AbstractSocketInitiator.quickfixSessions never gets
> filled in as far as I can tell, so isLoggedOn() and getSessions() don't
> work.

Can you also add bug reports for these issues?
 
> There were also some I didn't look into further:
> 
> - If I start an initiator and send a message before the logon process is
> completed the message doesn't go anywhere.  If I explicitly wait until
> the session is logged on then it works fine.

Is there a resend request after the logon? What is the expected behavior
of FIX when a message is sent before a session has been associated with
a connection? What does the C++ engine do in this case?

> - If a session is disconnected it doesn't seem to logon again.  It says
> 'Initiating Logon' but nothing further happens.

This has already been fixed in the beta branch of CVS.
 
> Sorry if I seem to be pointing out a lot of negatives - I do realise
> quickfixj is beta.  Keep up the good work!

It's no problem at all. I was hoping for more of this type of feedback,
so I appreciate it. We were planning to do another release with a few
previous bug fixes and an new SleepyCat JE message store, but 
I'd like to fix these problems first.

BTW, Barry Kaplan has been doing a lot of experimentation with Spring
and QuickFIX/J (but not JMS, so far). The code is not currently in CVS
but you may want to contact him about some collaboration or code sharing.
Eventually, I'd like to add the Spring-related code to CVS assuming there
is enough interest. Barry's email address is mailto://bkaplan@memelet.com/.

Regards,

Steve