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

[Brad H. <Bra...@gb...>]

Hi Steve,

I've added the bug reports as requested. Would you prefer that "obvious"
ones go straight to the bug tracker in future?  Are there guidelines on
the severity and priorities to use?

> 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?

There are quite a few - the javadoc/serialized-form.html page will show
them (the ones that are ok list the serialVersionUID, the ones that
aren't don't), or you can configure eclipse to show a warning for them.
Many of the generated classes have inner classes that don't define it.
Eg: =20
Class quickfix.fix40.Allocation.NoAllocs extends Group implements
Serializable=20
Class quickfix.fix40.Allocation.NoAllocs.NoDlvyInst extends Group
implements Serializable=20
Class quickfix.fix40.Allocation.NoExecs extends Group implements
Serializable=20
Class quickfix.fix40.Allocation.NoMiscFees extends Group implements
Serializable=20
Class quickfix.fix40.Allocation.NoOrders extends Group implements
Serializable=20

Rough list of the others:

Class quickfix.BooleanField extends Field implements Serializable=20
Class quickfix.BusinessRejectReasonText extends
quickfix.field.BusinessRejectReason implements Serializable=20
Class quickfix.CharField extends Field implements Serializable=20
Class quickfix.ConfigError extends java.lang.Exception implements
Serializable=20
Class quickfix.DateField extends Field implements Serializable
Class quickfix.DoubleField extends Field implements Serializable=20
Class quickfix.Field extends java.lang.Object implements Serializable=20
Class quickfix.FieldConvertError extends java.lang.Exception implements
Serializable=20
Class quickfix.FieldMap extends java.lang.Object implements Serializable

Class quickfix.FieldNotFound extends java.lang.Exception implements
Serializable=20
Class quickfix.FieldType extends java.lang.Object implements
Serializable=20
Class quickfix.Group extends FieldMap implements Serializable=20
Class quickfix.IncorrectDataFormat extends java.lang.Exception
implements Serializable=20
Class quickfix.IncorrectTagValue extends java.lang.Exception implements
Serializable=20
Class quickfix.IntField extends Field implements Serializable=20
Class quickfix.InvalidMessage extends java.lang.Exception implements
Serializable=20
Class quickfix.Message.Header extends FieldMap implements Serializable=20
Class quickfix.Message.Trailer extends FieldMap implements Serializable=20
Class quickfix.RejectLogon extends java.lang.Exception implements
Serializable=20
Class quickfix.RuntimeError extends java.lang.RuntimeException
implements Serializable=20
Class quickfix.SessionException extends java.lang.RuntimeException
implements Serializable=20
Class quickfix.SessionNotFound extends java.lang.Exception implements
Serializable=20
Class quickfix.StringField extends Field implements Serializable=20
Class quickfix.UnsupportedMessageType extends java.lang.Exception
implements Serializable=20
Class quickfix.UtcDateOnlyField extends DateField implements
Serializable=20
Class quickfix.UtcTimeOnlyField extends DateField implements
Serializable=20
Class quickfix.UtcTimeStampField extends DateField implements
Serializable=20

I think my problems were exacerbated by making the DataDictionary
serializable - all the Field classes were being sent around. =20

>> There were also some I didn't look into further:
>>=20
>> - 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?

I haven't had a chance to look into this further yet - will let you know
when I do.

Cheers,
Brad.


-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
Sent: Tuesday, 13 September 2005 1:21 AM
To: qui...@li...
Subject: RE: [Quickfix-developers] [qfj] Publishing Messages to JMS

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

> 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.
>=20
> 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=20
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/
=20
> 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:
>=20
>      	ResourceLoader defaultResourceLoader =3D new
> DefaultResourceLoader();
>       dataDictionary =3D 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=20
for finding data dictionaries.
=20
> 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:"=20
URL handler and use the existing URL-based constructor. The way
you are doing it probably easier.
=20
> quickfix.SocketInitiator.onPoll() throws a ClassCastException if it
gets
> a Session object from the event queue - it needs the same instanceof
> checks as onBlock().
>=20
> 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?
=20
> There were also some I didn't look into further:
>=20
> - 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.
=20
> 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=20
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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers