Imported from previous forum
Hi All,
We are working on certification for a client and we have an issue with the way possdup flag is being handled. When we send a resend request to our client, the client plays back all the orders as expected. However, we resend acks on orders that we have already processed with a PossResend Flag set to “Y”.
The protocol specification seems to be silent about how it should be handled i.e. if the orders have already been processed should an ack be resent or the message just be dropped.
The fact that we requested a resend request implies that our fix session does not believe that these messages were ever recieved. The fix session passes it on the application which then sends an ack back.
Is this acceptable behaviour from our fix engine?
Regards,
Ramesh
[ original email was from John Prewett - jprewett@lavatrading.com ]
There are two questions in your posting:
- How should we respond?
- Should this be happening at all?
I’m going to answer this in reverse order.
-
Should this be happening at all?
No. Something is going wrong with your FIX engine or its interface to your application, or both. If you have already received and processed a message with a certain MsgSeqNum and the FIX engine gives it to you again (same MsgSeqNum), something is going very badly wrong.
The application should only be processing incoming messages with an ever-increasing MsgSeqNum.
The situation you describe should not be happening. -
How do we respond?
Due to the fact that the situation should not be happening, I would terminate the FIX session, alert your support staff and delegate the problems away from your automated system to humans.
Good luck.
Sounds nasty.
JohnP
[ original email was from Nicholas Tuttle - nicholas.tuttle@na.linedata.com ]
I semi-disagree.
If POSSDUPFLAG=Y is included on the message, then the message SHOULD carry the same seq num as the original message. The first part of the question makes sense:
Resend request is sent > orders are resent with PossDupFlag=Y (presumably with the same seq nums as originally, though this wasn’t specified).
Technically speaking, re-acking with PossRESEND=Y should be ok so long as the resent acks carry NEW seq nums. However, best practice would be to only ack the order messages which truly weren’t originally received (ie, your side should know if they’ve already sent an ack and should avoid PossResend if possible). I say this because, in my experience, PossResend isn’t typically handled as gracefully as PossDupFlag.
With PossDupFlag=Y your engine can say “ok, have I received this seq num before this session? If yes - ignore. If no - process message”
With PossResend the FIX engine has to say “ok, how do I determine if I’ve received this before?” and have more complicated logic in place; ie, look for dupe ClOrdID or ExecID.
There are two questions in your posting:
- How should we respond?
- Should this be happening at all?
I’m going to answer this in reverse order.
Should this be happening at all? No. Something is going wrong with
your FIX engine or its interface to your application, or both. If
you have already received and processed a message with a certain
MsgSeqNum and the FIX engine gives it to you again (same MsgSeqNum),
something is going very badly wrong. The application should only be
processing incoming messages with an ever-increasing MsgSeqNum. The
situation you describe should not be happening.How do we respond? Due to the fact that the situation should not
be happening, I would terminate the FIX session, alert your
support staff and delegate the problems away from your automated
system to humans.Good luck. Sounds nasty.
JohnP
[ original email was from Dennis Wiatzka - dennis.wiatzka@omxgroup.com ]
Hi Ramesh,
Your scenario implies that your system already generated Execution Reports for the order messages in question. In such a scenario, you can assume that the previously generated Execution Reports were received and processed by the remote client.
You should only need to resend Execution Reports if the client requests retransmission.
Your scenario seems a little unusual, though, because on the one hand you state that the messages were missed, but on the other hand you state that the messages had been handled.
Therefore this implies (in your scenario) your application had a failure which included the failure to store the inbound messages and, upon restart, your application thinks there is a message gap when there was none.
Cheers,
Dennis
Hi All,
We are working on certification for a client and we have an issue with
the way possdup flag is being handled. When we send a resend request to
our client, the client plays back all the orders as expected. However,
we resend acks on orders that we have already processed with a
PossResend Flag set to “Y”.The protocol specification seems to be silent about how it should be
handled i.e. if the orders have already been processed should an ack be
resent or the message just be dropped.The fact that we requested a resend request implies that our fix session
does not believe that these messages were ever recieved. The fix session
passes it on the application which then sends an ack back. Is this
acceptable behaviour from our fix engine?Regards, Ramesh
Hi,
Thank you all for your responses. I see the contradiction in the test. The issue is that the sequence numbers are being manually changed to test the resend logic. I understand the complications involved in resending executions on orders already processed. I wanted to know if there was a standard way to handle this.
Regards,
Ramesh
Hi Ramesh,
Your scenario implies that your system already generated Execution
Reports for the order messages in question. In such a scenario, you can
assume that the previously generated Execution Reports were received and
processed by the remote client.You should only need to resend Execution Reports if the client requests
retransmission.Your scenario seems a little unusual, though, because on the one hand
you state that the messages were missed, but on the other hand you state
that the messages had been handled.Therefore this implies (in your scenario) your application had a
failure which included the failure to store the inbound messages and,
upon restart, your application thinks there is a message gap when
there was none.Cheers,
Dennis
Hi All,
We are working on certification for a client and we have an issue with
the way possdup flag is being handled. When we send a resend request
to our client, the client plays back all the orders as expected.
However, we resend acks on orders that we have already processed with
a PossResend Flag set to “Y”.The protocol specification seems to be silent about how it should be
handled i.e. if the orders have already been processed should an ack
be resent or the message just be dropped.The fact that we requested a resend request implies that our fix
session does not believe that these messages were ever recieved. The
fix session passes it on the application which then sends an ack back.
Is this acceptable behaviour from our fix engine?Regards, Ramesh
I hit post before I finished what I wanted to say:
The issue is that the resend request is purely a session layer protocol. So the resend may happen on restart if there is corruption of the persistence at the session layer. As one of the reponders pointed out. In such a situation should the application layer just ignore the message if it had already been processed. I think one of the other responders answered this question as well. Since we were the one’s that sent the resend request we should possibly drop it, However the application layer does not know who originated the resend request, all it knows is that the message was a result of a resend.
Thanks again for all the responses.
Ramesh
Hi,
Thank you all for your responses. I see the contradiction in the test.
The issue is that the sequence numbers are being manually changed to
test the resend logic. I understand the complications involved in
resending executions on orders already processed. I wanted to know if
there was a standard way to handle this.Regards, Ramesh
Hi Ramesh,
Your scenario implies that your system already generated Execution
Reports for the order messages in question. In such a scenario, you
can assume that the previously generated Execution Reports were
received and processed by the remote client.You should only need to resend Execution Reports if the client
requests retransmission.Your scenario seems a little unusual, though, because on the one hand
you state that the messages were missed, but on the other hand you
state that the messages had been handled.Therefore this implies (in your scenario) your application had a
failure which included the failure to store the inbound messages and,
upon restart, your application thinks there is a message gap when
there was none.Cheers,
Dennis
Hi All,
We are working on certification for a client and we have an issue
with the way possdup flag is being handled. When we send a resend
request to our client, the client plays back all the orders as
expected. However, we resend acks on orders that we have already
processed with a PossResend Flag set to “Y”.The protocol specification seems to be silent about how it should be
handled i.e. if the orders have already been processed should an ack
be resent or the message just be dropped.The fact that we requested a resend request implies that our fix
session does not believe that these messages were ever recieved. The
fix session passes it on the application which then sends an ack
back. Is this acceptable behaviour from our fix engine?Regards, Ramesh