[QFJ-786] First three fields getting truncated when converting from string to message using Message constructor Created: 03/Jun/14  Updated: 02/Apr/15  Resolved: 12/Jun/14

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.5.3
Fix Version/s: 1.6.0

Type: Bug Priority: Critical
Reporter: raghuram potluri Assignee: Christoph John
Resolution: Fixed Votes: 0
Labels: None
Environment:

windows


 Description   

when using below code sinppet either first or second or third tag getting truncated.

scenario 1:
public class TestMessage {

public static void main(String[] args) {
String st = "35=D12=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000";

quickfix.Message msg;
try

{ msg = new Message(st,false); System.out.println("original message"+st); System.out.println("quickfixj message"+msg); }

catch (InvalidMessage e)

{ // TODO Auto-generated catch block e.printStackTrace(); }



}

}
Output =
original message 35=D12=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000
quickfixj message 9=13612=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.00010=232
First tag 35=D which was present in original string is missing after converting to message.

Scenario 2:
public class TestMessage {

public static void main(String[] args) {
String st = "8=FIX4.29=11012=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000";

quickfix.Message msg;
try { msg = new Message(st,false); System.out.println("original message "+st); System.out.println("quickfixj message "+msg); } catch (InvalidMessage e) { // TODO Auto-generated catch block e.printStackTrace(); }

}

}
Output:
original message 8=FIX4.29=11012=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000
quickfixj message 8=FIX4.29=12413=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.00010=182

Now you can see third tag which is 12=0.000001 is truncated.

 Comments   
Comment by Christoph John [ 04/Jun/14 ]

I think it is quite hard to parse a message that is incomplete, e.g. the header is missing required fields. After adding all required header and trailer fields you could try to do the following:
new Message(st, dd, false)

Where dd is a DataDictionary which is applicable to your used FIX version.

Comment by Christoph John [ 05/Jun/14 ]

If you have further questions, please use the mailing list: https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Comment by raghuram potluri [ 05/Jun/14 ]

John,
definitely this is a bug coz this is not what happening when we are using quickfix for .net.
string message ="1=03100631~11=140605JWI4440~15=USD~21=1~35=D~38=6~40=1~47=A~54=1~55=UNP~59=0~60=20140605-13:58:51.016~63=0~79=03100631~336=1~377=N~581=A~6020=COMPUS~86028=JWI~86029=4440~";

message = message.Replace( '~', ( char )1 );

Console.WriteLine(message);

QuickFix.Message msg = new QuickFix.Message( message,false );

string newMessage = msg.ToString();

Console.WriteLine( newMessage );

Let us know if you would be able to resolve this ?

Comment by Christoph John [ 06/Jun/14 ]

QuickFIX/n is not QuickFIX/J. But I will take a look at it.

Comment by raghuram potluri [ 09/Jun/14 ]

Thanks John. Please let me know if you find anything.

Comment by Christoph John [ 12/Jun/14 ]

This is now fixed. When parsing the header the first three tags were checked for their correct position which meant that they were effectively skipped if they were not the expected header tags BeginString, BodyLength or MsgType.
This has now been changed to only check the first three fields if message validation is enabled.

Comment by raghuram potluri [ 16/Jun/14 ]

Thx John. Will test and let you know if I still see any issues.appreciate your quick repsonse on this issue.

Generated at Sun May 05 13:02:50 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.