[QFJ-251] Reprocessing missed FIX messages - application side. Created: 27/Sep/07 Updated: 15/Nov/12 Resolved: 28/Sep/07 |
|
| Status: | Closed |
| Project: | QuickFIX/J |
| Component/s: | None |
| Affects Version/s: | 1.1.0 |
| Fix Version/s: | None |
| Type: | Other | Priority: | Default |
| Reporter: | Parag Mehta | Assignee: | Steve Bate |
| Resolution: | Not a bug | Votes: | 0 |
| Labels: | None | ||
| Environment: |
all |
||
| Description |
|
Wondering if application has missed processing some FIX messages (e.g. due to exceptions in other code), is it possible to use any quickfixj API point to get a range of messages to be send back to the application from FIX? I.e. the messages are still in the db, they just want to be resend to the callback. Also how many messages are stored in the messages table, when would this table be truncated (when session resets?). Thanks. |
| Comments |
| Comment by Steve Bate [ 28/Sep/07 ] |
|
The resend capability of FIX (and QFJ) is intended to be used for recovery from communication errors between counterparties. It only stores /sent/ messages in case they need to be sent again later. It sounds like you would need received messages if there is an local application error. The message log can provide this capability but there is no API for accessing the log. However, if you use a JdbcLog then you could write ad hoc queries against the incoming message table. You could even modify the schema to add a column that indicates whether the application has completed processing a specific message. Also be aware that if an application message processing callback throws an exception (it would have to be an unchecked exception), the session's incoming message sequence number is not incremented. This means that when the next message arrives, the session will request a resent from the counterparty. This can have a similar effect to what you are wanting. |