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

[Gene G. <mus...@ya...>]

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