[QFJ-191] Add transactional behaviour to fromApp() callback Created: 06/Jun/07  Updated: 13/Aug/07  Resolved: 13/Aug/07

Status: Closed
Project: QuickFIX/J
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Default
Reporter: Jörg Thönnes Assignee: Steve Bate
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

Currently, if the fromApp() callback returns, ie the application message has been forwarded to the application layer,
the next expected sequence number of incoming message will be incremented.

If the Java application crashes inside the fromApp() callback, the sequence number stays as is, and after the next logon
the incoming sequence number is too low. Therefore, the message being processed in the fromApp() callback during
the crash will be refetched using a ResendRequest.

On the other hand, if some exception occurs inside the fromApp() callback (e.g. due to fatal processing errors in the application
layer) it would make sense to rollback the processed message by not incrementing the incoming sequence number.
This will cause the message to be redelivered using a ResendRequest.

To accomplish this the fromApp() callback should catch any exceptions (or at least some specific ones) and abstain from incrementing
the incoming sequence number.

As a sub-task prior to this issue I would see to separate the verify processing from the fromApp processing.

Further improvements would include full JTA (Java Transaction API) support (create another JIRA issue for this).

 Comments   
Comment by Steve Bate [ 10/Jun/07 ]

Hello,

I've investigated this issue and it appears the code already has the behavior you describe, at least for unchecked exceptions. An unchecked exception will propagate up to the communication layer, which will then discard the message. However, the sequence numbers will never have been incremented so the message will be resent when the next message arrives and a sequence gap is detected.

Is this the behavior you wanted? What problem were you having?

Thanks,

Steve

Comment by Jörg Thönnes [ 10/Jun/07 ]

Our application does some sort of message processing directly in the fromApp() callback.
If that fails due to an exception, I would like to have some sort of rollback.

If this already works for unchecked exceptions, I may just wrap any exception into a RuntimeException.
Would this work?

Cheers, Jörg

Comment by Steve Bate [ 10/Jun/07 ]

What type of exception was being thrown when the application failed? There are some checked/declared exceptions on the interface. If those are thrown, it depends on the type of message whether the expected sequence number is incremented or not.

Comment by Jörg Thönnes [ 11/Jun/07 ]

Now we implemented something like:

fromApp( ... ) {

try

{ processMessage( ... ); }

catch ( e )

{ throw new RuntimeException( text, e ); }

}

and it works as expected. Possibly a dedicated QF/J exception instead of the general RuntimeException
would be nicer.

Thanks a lot, Jörg

Comment by Steve Bate [ 27/Jul/07 ]

As I commented earlier, I believe the code has the desired behavior for RuntimExceptions. Can we close this issue?

Generated at Tue Jul 01 07:36:37 UTC 2025 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.