Quantcast

throw own Exception on fromApp for preventing SequenceIncrement in Messagstore

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

throw own Exception on fromApp for preventing SequenceIncrement in Messagstore

faehne
Hi,

i have a short question:

Is it possible to prevent the SequenceInc (so there will be an resend later) after the
Call of fromApp?

Cause i process the incoming Message in fromApp completly synch to guarantee, that it
will be stored in the connected system. If the storing to system failed, i will throw an Exception
or just do an Action, that causes, not to increment the incoming-Seqnum.

Maybe i can use the available Exceptions to force an reject to the other side, but Fieldnotfound, InvalidDataformat, InvalidtagValue and Messagetype supported seems not to fit with the information i want to send (want to send something like "backend not available" in the reject).

Hope have an idea... thanks a lot.
faehne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: throw own Exception on fromApp for preventing SequenceIncrement in Messagstore

Øyvind Matheson Wergeland
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


You can create your own reject message, but it does not seem appropriate to reject a message if the client behaves correctly.

What role does your software play in the process chain?

 -Øyvind

Den 15. mars 2012 kl. 09:35 skrev faehne <[hidden email]>:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> i have a short question:
>
> Is it possible to prevent the SequenceInc (so there will be an resend later)
> after the
> Call of fromApp?
>
> Cause i process the incoming Message in fromApp completly synch to
> guarantee, that it
> will be stored in the connected system. If the storing to system failed, i
> will throw an Exception
> or just do an Action, that causes, not to increment the incoming-Seqnum.
>
> Maybe i can use the available Exceptions to force an reject to the other
> side, but Fieldnotfound, InvalidDataformat, InvalidtagValue and Messagetype
> supported seems not to fit with the information i want to send (want to send
> something like "backend not available" in the reject).
>
> Hope have an idea... thanks a lot.
> faehne
>
>
> --
> View this message in context: http://quickfix-j.364392.n2.nabble.com/throw-own-Exception-on-fromApp-for-preventing-SequenceIncrement-in-Messagstore-tp7374877p7374877.html
> Sent from the QuickFIX/J mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: throw own Exception on fromApp for preventing SequenceIncrement in Messagstore

faehne
Our app simply route the fix-message to a message-broker (amq, ibm mq-s)...

So i have to garantee, that every call of fromApp have a high grade of data integry.

So an reject or the preventing of SequenceIncrementation should handle the worst case (mq-broker is not available anymore).

I saw such mechanism at other partners, we are connected (they send messages like 35=3...58=Backend not available). But i would prefer a solution, that just do not inc the seqnum ;-)

But maybe you can give me a short hint, how i can send my own reject-Message... thanks a lot.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: throw own Exception on fromApp for preventing SequenceIncrement in Messagstore

Grant Birchmeier
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



This strikes me as a rather unorthodox way of doing things.  If you have a non-FIX-related error on your side, why are you telling your FIX component to pretend there was a FIX transmission error?

You're hacking QuickFIX's proven procedures to compensate for possible errors in your components.

I suggest you find some other way to handle this.  Perhaps you can catch exceptions and write this lost data to an alternate location (file/db) if the store-to-system failed, and have some other process monitor your alternate location to perform recovery actions.

Don't compromise QuickFIX because you don't trust your other systems.

-Grant




On Mon, Mar 19, 2012 at 2:36 AM, faehne <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Our app simply route the fix-message to a message-broker (amq, ibm mq-s)...

So i have to garantee, that every call of fromApp have a high grade of data
integry.

So an reject or the preventing of SequenceIncrementation should handle the
worst case (mq-broker is not available anymore).

I saw such mechanism at other partners, we are connected (they send messages
like 35=3...58=Backend not available). But i would prefer a solution, that
just do not inc the seqnum ;-)

But maybe you can give me a short hint, how i can send my own
reject-Message... thanks a lot.

--
View this message in context: http://quickfix-j.364392.n2.nabble.com/throw-own-Exception-on-fromApp-for-preventing-SequenceIncrement-in-Messagstore-tp7374877p7384842.html
Sent from the QuickFIX/J mailing list archive at Nabble.com.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: throw own Exception on fromApp for preventing SequenceIncrement in Messagstore

Dan Corneanu
This post has NOT been accepted by the mailing list yet.
In reply to this post by faehne
faehne wrote
Cause i process the incoming Message in fromApp completly synch to guarantee, that it
will be stored in the connected system. If the storing to system failed, i will throw an Exception
or just do an Action, that causes, not to increment the incoming-Seqnum.

Maybe i can use the available Exceptions to force an reject to the other side, but Fieldnotfound, InvalidDataformat, InvalidtagValue and Messagetype supported seems not to fit with the information i want to send (want to send something like "backend not available" in the reject).
I have a similar use case. I am thinking of handling it as following:
1. detect that the resource is down
2. send a logout message to the couter-party.
3. throw a RuntimeException (will prevent the seq number from being incremented)
4. poll the external resource and when it comes up again, send a logon message and resume processing

Would this be a viable solution?

Regards,
Dan
Loading...