As we discussed on the mailing list, it is not correct for an application to explicitly request a message resend. The FIX session processes messages in the order of the message sequence numbers. Let's say the session's next expected incoming sequence number is 100. Your application requests message 75 to be resent. The session receives the message, sees the PossDup flag is set and that the sequence number is less than the expected next sequence number. The message is then dropped because it has already been processed by the application. This is normal FIX session behavior.

Thanks. That makes more sense now. The only thing is that if the original message was rejected, my application did not get chance to process it. By customizing the dictionary to let QFJ to allow the message, we want to re-process the message.

An alternative is to read the message from messages_log table and construct the Message object from String (how to do that?) and call toApp method programmatically

This issue actually lead to a practical question. In our reality, 99% of time QFJ rejects messages for the reasons that are not our concern. we actually want to receive those messages even though they do not stick to the FIX spec. We cannot force counterparty what to do, so we have to basically keep a customized dicitonary for each counterparty. It would be nicer to allow us to configure QFJ to be more forgiving. I would classify the checks into 2 classes, one is more criitical (like having header, trailer, and checksum is correct....); while the other is less critical and QFJ can allow us to turn them off using ONE single switch.