FW: [Quickfix-developers] [qfj] Publishing Messages to JMS
Brought to you by:
orenmnero
|
From: Brad H. <Bra...@gb...> - 2005-09-13 00:09:42
|
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 |