Re: [Quickfix-developers] Java Application::fromApp provides Message with lost groups

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

I think the behavior that you are proposing is a good
design change. 

I think, however, that both mechanisms (per-session
and per-beginstring) custom dicts ought to be
supported, and if only one is feasible, my personal
preference would be BeginString (with, perhaps global
-- once per application--custom overwrite)

A downside of looking up protocol in session is that
it will add a circular dependency (Message<->Session),
and a non-transparent Message side-effect.

I like beginstring because it makes Message truly
self-contained, there is no chance of making an error
of creating message with one data dictionary, and
later parsing string from it with another one.

Allowing a single for all sessions overwrite will
handle the situation when beginstring cannot be
changed, yet custom protocol is called for.

I also suggest that whatever ends up being
implemented, in the typical situation (i.e. no custom
protocols), settings file will no longer need to
reference external XMLs.

Gene

--- OM...@th... wrote:
> 
> Good catch guys.  That is a good patch.  Anyone
> using groups in java should
> apply it, I'll also add it to the repository.
> 
> You are right in noting that the design for groups
> is not perfect.  It
> wasn't until support for groups was added that a
> DataDictionary all of the
> sudden was required in order to parse a message, so
> there are definately a
> few issues that have bled over.
> 
> I think that having the default data dictionaries
> embedded into the code
> for use by the message is probably a good idea.  I
> think it is a better
> idea than just using the configuration file because
> I see use for the
> message class as a standalone class.
> 
> When there are sessions available, I think it would
> be good to have
> setString pick out the SessionID, do a
> lookupSession, and pull out the data
> dictionary for that session if available.  If the
> session does not exist
> and no data dictionary is passed in, it will use the
> default based on the
> beginstring.  If a data dictionary is passed in, it
> will be used no matter
> what.  This should avoid the need for custom begin
> strings.  Thoughts?
> 
> --oren
> 
> 
> 
>
|---------+----------------------------------------------->
> |         |           Gene Gorokhovsky              
>      |
> |         |           <mus...@ya...>          
>      |
> |         |           Sent by:                      
>      |
> |         |          
> qui...@li...ur|
> |         |           ceforge.net                   
>      |
> |         |                                         
>      |
> |         |                                         
>      |
> |         |           11/19/2002 11:10 AM           
>      |
> |         |                                         
>      |
>
|---------+----------------------------------------------->
>  
>
>----------------------------------------------------------------------------------------------|
>   |                                                 
>                                             |
>   |       To:       OM...@th...,
> qui...@li...          |
>   |       cc:       se...@mi...              
>                                             |
>   |       Subject:  [Quickfix-developers] Java
> Application::fromApp provides Message with lost   |
>   |        groups                                   
>                                             |
>  
>
>----------------------------------------------------------------------------------------------|
> 
> 
> 
> 
> Sergey Gribov and myself discovered the following
> problem (QuickFIX 1.3.2):
> When receiving a message with Group fields, the
> message is corrupted --  group information is lost,
> and message length is invalid, by the time it
> reaches
> Java Application fromApp and fromAdmin callbacks.
> 
> We traced the problem to JNI layer. Here is the
> patch
> for src/java/Conversions.h (tested on Linux/gcc
> 3.2.1)
> 
> 124c124
> <   pMessage->setString( message.toString() );
> ---
> >   *pMessage = message;
> 141c141
> <   pMessage->setString( message.toString() );
> ---
> >   *pMessage = message;
> 
> ------------------------------------------
> While the above patch fixes the immediate problem at
> hand, this does expose a design issue: setString
> does
> not work correctly for messages with repeating
> groups
> if DataDictionary is not supplied. The resulting
> message has a corrupted structure (group count field
> has correct count, the rest of group field are
> present
> only once). Athough setString returns false
> (constructor using it even throws), I think that
> this
> method with DataDictinary not supplied is dangerous
> and should be hidden from the public interface
> altogether, or at the very least it should throw an
> exception.
> 
> The upshot is that the message cannot be safely
> restored from a string without somehow externally
> knowing the DataDictionary needed for that, despite
> source string containing the protocol version (which
> cannot be extracted without constructing Message...)
> 
> I think that there could be a collection  of
> DataDictionaries available to Message internally
> based
> on the protocol's BeginString value.
> They could be loaded based on entries in the Default
> Section of the CFG file
> DataDictionary.FIX41=./FIX41.xml, or perhaps their
> content should be even be hard-coded as the strings
> in
> one of the header files, since providing a data-dict
> XML different from the one used to generate code may
> not be such a hot idea. That way sessions will refer
> to the version of the protocol, with XML spec being
> an
> optional override, and Message class will pick up
> the
> correct spec themselves using BeginString, instead
> of
> always relying on the DataDictionary parameter.
> 
> Custom tags will requite a custom XML spec
> associated
> with a custom FIX beginstring, or recompilation of
> quickfix code, which I do not see as much of  a
> problem, since this is already required for
> type-safe
> usage of the custom tags.
> 
> Changes are also required for non-validating mode,
> since this mode is currently broken for reception of
> messages with repeating groups -- Java fromApp is
> silently never called, and C++ fromApp gets a
> corrupted message.
> Perhaps this mode should be an explicit setting in
> the
> config file, with meaningful exceptions thrown when
> a
> message with repeating tags is received.
> 
> Gene
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - Let the expert host your site
> http://webhosting.yahoo.com
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by: To learn the
> basics of securing
> your web site with SSL, click here to get a FREE
> TRIAL of a Thawte
> Server Certificate:
> http://www.gothawte.com/rd524.html
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 
> 
> 
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by: To learn the
> basics of securing 
> your web site with SSL, click here to get a FREE
> TRIAL of a Thawte 
> Server Certificate:
> http://www.gothawte.com/rd524.html
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com