[QFJ-322] Bad checksum passes FIXMessageDecoder validation Created: 09/Jul/08 Updated: 06/Oct/08 Resolved: 19/Aug/08 |
|
| Status: | Closed |
| Project: | QuickFIX/J |
| Component/s: | Message Generation |
| Affects Version/s: | 1.3.1 |
| Fix Version/s: | 1.3.3 |
| Type: | Bug | Priority: | Default |
| Reporter: | Jay Walters | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Java 6, Windows XP |
||
| Description |
|
The FIXMessageDecoder.startsWith method has a bug, and the other functions in FIXMessageDecoder do not properly handle percolating the case back up to the caller. Specifically, if the pattern is matching against the end of a ByteBuffer it only matches the first character of the pattern. If the pattern doesn't match, there is no way to percolate a MessageDecoderResult.NOT_OK back up to the caller, it will just send back NEED_DATA. It is best illustrated by running the following JUnit test Paste into the FIXMessageDecoderTest class public void testPatternMatching() throws Exception { decoder = new FIXMessageDecoder("UTF-16"); setUpBuffer("8=FIX.4.2\0019=12\00135=X\001108=30\0011wmyadz"); MessageDecoderResult decoderResult = decoder.decode(null, buffer, decoderOutput); assertEquals("wrong decoder result", MessageDecoderResult.NOT_OK, decoderResult); } |
| Comments |
| Comment by Steve Bate [ 10/Jul/08 ] |
|
I have a fix for the bug in startsWith (there is also a bug in how the failed startsWith is handled). It's been awhile since I've been in the guts of MINA buffer handling, but IIRC returning a NOT_OK will result in a ProtocolCodecException being thrown by MINA and any data left in the current buffer is lost. Therefore, the intent is to log the error and then continue processing data in the buffer (which could contain another message fragment). |