Re: [Quickfix-users] QuickFIX/J newbie needs tips on robustness

[Jerry W. <je...@we...>]

Your Brokers support is (In my experience) fairly average...
I really don't expect too much more from brokers.

I have a question to your problem:
1) Is it one?

The Fix Specs say that the ClOrdID is Unique per Order.
I would expect your broker to check this.  
If the ClOrdID already exists then He should reject the NewOrderSingle.

In this form, you have no problem with sending duplicates.

As long as your ClOrdID remains the same...

Of course if he rejects the NewOrderSingle, you still got the problem
of finding out what OrderId He gave to the thing....

But Someday some thing will happen to the order resulting in a message,
and the message will have the OrderID...  

Check if your broker accepts Deletes without OrderID, so that deletes are 
possible durring this unknown period.


2) Isn't this a rather theoretical case?Won't QuickFix Recovery get this for 
you?
Jerry Westrick.


On Wednesday 19 July 2006 06:39, Scott Maxwell wrote:
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX
> Support: http://www.quickfixengine.org/services.html
>
> I'm a FIX (and QuickFIX) newbie, using QuickFIX/J to write a simple
> trading application.  The basic system design includes a database into
> which pending orders are written, and my application, which
> periodically sweeps the database, placing any pending orders.
>
> Naturally, I want to ensure that orders aren't placed twice (because
> they'll appear to the broker as two separate orders), so after sending
> the order message to the broker, my application updates the database
> to say that the order has been sent.  Later, when the order is
> accepted or rejected by the broker, the database will be updated again
> to say so.
>
> One concern I have is this: suppose the power goes out (or pick your
> favorite disaster) after the order message has been sent but before
> the database has been updated to say it was sent.  Now, when my
> application wakes up again, it will think the order was never sent,
> and will (re-)send it to the broker.
>
> Realizing this, I attacked the problem in two parts.  First, I changed
> the code to do things the other way around: flag the order as sent,
> then send the order message.  Second, when my application starts up,
> it looks at all orders flagged as sent (but not yet acknowledged by
> the broker) and resends them with PossResend=Y.
>
> That seemed great -- except that it turns out that my particular
> broker doesn't support orders with PossResend=Y.
>
> *Sigh*.
>
> So I changed it again: now, when my application starts up, it sends an
> OrderStatusRequest for the order, which should result in an
> ExecutionRpt giving the order's status; I figured that if my broker
> indicated they'd never heard of the order, I should re-send it.
>
> That seemed great -- except that it turns out that my broker rejects
> OrderStatusRequest unless it includes their OrderID (not ClOrdID), and
> you don't get their OrderID until you've received the acknowledgment
> to your order request.  And the orders I'm worried about are precisely
> the ones for which I don't have that information, because the power
> went out at the wrong time.
>
> I ran into the same problem (my broker demands an OrderID I don't yet
> have in the case I care about) when I tried to use OrderCancelRequest,
> and when I tried to use OrderCancelReplaceRequest.  I couldn't find
> anything else promising in the FIX spec, and am now officially out of
> ideas.
>
> So, O wise and experienced FIX folks, how would you solve this
> problem?  Is there a way to write my application so that it will
> robustly recover from the state I'm concerned about?  My broker
> supports FIX4.2, if it matters.  (Though not as completely as I would
> like, as you can see. ;-)