Imported from previous forum
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
The CBOE has a requirement to report the application queue depth (different than the current LastSeqNum processed).
This queue depth is the number of application events that are waiting to be reported as of a given transaction. For instance, if an Execution Report is being sent, if there is a queue of execution events waiting to be reported, this value would be included in the ApplicationQueueDepth field.
The queue depth applies to any reporting type (quotes, market data, orders, etc.).
The need for this field is to report to both parties any application queuing to permit market participants to modify applications, make trading decisions, etc.
Two custom fields were requested for this for versions of FIX earlier than 4.4:
6699 ApplicationQueueDepth Custom header field that provides the number of application level events that are queued for processing behind this current message. For instance, the ApplicationQueueDepth > 0 on an Execution Report - indicates that there are still ApplicationQueueDepth # of reports that have to be generated and transmitted. This information is provided to help counterparties manage throughput and backlog issues.
6700 ApplicationQueueResolution Optional customer header field that indicates the action taken to resolve the Application queue depth (backlog).
0- No action taken
1- Queue flushed
2- Overlay last
3- End session
In regards to tag 6699:
I don’t see a need for a “generic”, header-based queue depth. It is meaningless on requests, and meaningful only on responses.
Two reasons come to mind for having an ApplicationQueueDepth:
-
To tell the client that there are N messages of a certain type (FillReport, MD, Ack, etc) waiting. This happens to be more difficult for the server-side, but allows the client-side to automatically throttle, or unsubscribe, faster-growing but less critical message types.
-
To tell the client that there are N messages in TOTAL waiting. This is easier for the server, but may or may not be meaningful to the client, since it has no idea of how to automatically reduce the queue by unsubscribing or other actions (besides being "faster" at consuming)
In regards to 6700, I also don’t see a need for it to be in the header. In fact, it is only useful on responses, and obviously has to be specified somehow on requests. But telling the engine how to handle its queued requests is only meaningful in case of 1).
So, I propose
6700 – ApplicationQueueActionRequest (on requests)
0 Normal Processing
1 Flush Queue
2 Overlay Last
3 End subcription (only used for messages that can be safely unsubscribed (MarketData, etc)
And
6701 – ApplicationQueueActionResponse (on responses)
0 No Action Taken
1 Queue Flushed
2 Overlaid Last
3 Subscription Ended
I see #2 and #3 as being the most common for MarketData, and #0 most common in Orders, etc.
> The CBOE has a requirement to report the application queue depth (different than the current LastSeqNum processed).
>
> This queue depth is the number of application events that are waiting to be reported as of a given transaction. For instance, if an Execution Report is being sent, if there is a queue of execution events waiting to be reported, this value would be included in the ApplicationQueueDepth field.
>
> The queue depth applies to any reporting type (quotes, market data, orders, etc.).
>
> The need for this field is to report to both parties any application queuing to permit market participants to modify applications, make trading decisions, etc.
>
> Two custom fields were requested for this for versions of FIX earlier than 4.4:
>
> 6699 ApplicationQueueDepth Custom header field that provides the number of application level events that are queued for processing behind this current message. For instance, the ApplicationQueueDepth > 0 on an Execution Report - indicates that there are still ApplicationQueueDepth # of reports that have to be generated and transmitted. This information is provided to help counterparties manage throughput and backlog issues.
>
>
> 6700 ApplicationQueueResolution Optional customer header field that indicates the action taken to resolve the Application queue depth (backlog).
> 0- No action taken
> 1- Queue flushed
> 2- Overlay last
> 3- End session
>
>
>
[ original email was from Kevin Houstoun - kevin.houstoun@ssmb.com ]
This has been assigned ID [PC20030310_3] and is under consideration by the technical committee.
> In regards to tag 6699:
>
> I don’t see a need for a “generic”, header-based queue depth. It is meaningless on requests, and meaningful only on responses.
>
> Two reasons come to mind for having an ApplicationQueueDepth:
>
> 1) To tell the client that there are N messages of a certain type (FillReport, MD, Ack, etc) waiting. This happens to be more difficult for the server-side, but allows the client-side to automatically throttle, or unsubscribe, faster-growing but less critical message types.
>
> 2) To tell the client that there are N messages in TOTAL waiting. This is easier for the server, but may or may not be meaningful to the client, since it has no idea of how to automatically reduce the queue by unsubscribing or other actions (besides being “faster” at consuming)
>
> In regards to 6700, I also don’t see a need for it to be in the header. In fact, it is only useful on responses, and obviously has to be specified somehow on requests. But telling the engine how to handle its queued requests is only meaningful in case of 1).
>
> So, I propose
> 6700 – ApplicationQueueActionRequest (on requests)
>
> 0 Normal Processing
> 1 Flush Queue
> 2 Overlay Last
> 3 End subcription (only used for messages that can be safely unsubscribed (MarketData, etc)
>
> And
> 6701 – ApplicationQueueActionResponse (on responses)
>
> 0 No Action Taken
> 1 Queue Flushed
> 2 Overlaid Last
> 3 Subscription Ended
>
> I see #2 and #3 as being the most common for MarketData, and #0 most common in Orders, etc.
>
>
> > The CBOE has a requirement to report the application queue depth (different than the current LastSeqNum processed).
> >
> > This queue depth is the number of application events that are waiting to be reported as of a given transaction. For instance, if an Execution Report is being sent, if there is a queue of execution events waiting to be reported, this value would be included in the ApplicationQueueDepth field.
> >
> > The queue depth applies to any reporting type (quotes, market data, orders, etc.).
> >
> > The need for this field is to report to both parties any application queuing to permit market participants to modify applications, make trading decisions, etc.
> >
> > Two custom fields were requested for this for versions of FIX earlier than 4.4:
> >
> > 6699 ApplicationQueueDepth Custom header field that provides the number of application level events that are queued for processing behind this current message. For instance, the ApplicationQueueDepth > 0 on an Execution Report - indicates that there are still ApplicationQueueDepth # of reports that have to be generated and transmitted. This information is provided to help counterparties manage throughput and backlog issues.
> >
> >
> > 6700 ApplicationQueueResolution Optional customer header field that indicates the action taken to resolve the Application queue depth (backlog).
> > 0- No action taken
> > 1- Queue flushed
> > 2- Overlay last
> > 3- End session
> >
> >
> >
>