Page Comparison

...

Configure handling 'stale' messages

FIXEdge/J provides the an ability to remove 'stale' orders from the Store and Forward queue. The period after which an order becomes outdated can be defined for each session. In addition, there is an option to exclude some message from the set of 'stale' messages.

For example, Client A may want to define all messages that are older than 30 sec at the sending time as 'stale'. At the same time, Client A wants Order Cancel Request (MsgType = F) messages to be always processed to the Exchange.

...

• storeAndForward.stalePeriod property defines a period (in seconds) that which is used to check if the message has become becomes 'stale' and should not be sent. If the property is set, all queued messages will be checked when a destination becomes available. In addition, if the difference between TransactTime (Tag = 60) and sending time is more that the defined the period, the messages will not be sent to into the destination. 
• storeAndForward.staleProcessingExcludedTypes property specifies the for which types of messages that the stale message checking and removal should removing is not be applied to.

sessionType=acceptor
senderCompID=FIXEdgeJCompID
targetCompID=ClientA
groups=Group_A
storeAndForward.enabled=true
storeAndForward.stalePeriod=30
storeAndForward.staleProcessingExcludedTypes=F

...

By default, the Store and Forward queue is persisted on the disk in the 'logs' directory.

In addition, there is a possibility to configure the messages in the memory using the storeAndForwardEndpoint.queueType parameter.

...

• storeAndForwardEndpoint.queueType = IN_MEMORY - In this mode, all messages provided are saved in memory. If the system is down (gracefully or non-gracefully), all the messages will be lost.
• storeAndForwardEndpoint.queueType = PERSISTENT - In this mode, all messages provided are saved on the disk and they will be restored and sent in case of shutdown (gracefully or non-gracefully).
• storeAndForwardEndpoint.queueType = REPLICATED - In this mode, all messages will be stored/replicated with the Persistent API functionality.

...

By default, FIXEdge/J processes messages in an the asynchronous mode.

In the case when synchronous processing is needed, there is a parameter that allows processing a message in this mode - storeAndForwardEndpoint.maxTimeForSyncSendingInUsec.

Please note, that this parameter will be applied only if storeAndForwardEndpoint.enabled= is true.

sessionType=acceptor
senderCompID=FIXEdgeJCompID
targetCompID=ClientB
groups=Group_A
storeAndForwardEndpoint.enabled=true
storeAndForwardEndpoint.maxTimeForSyncSendingInUsec = 60000000

It This parameter is also possible to use this parameter be used with slow consumer sessions. Reducing the value of the parameter allows starting you to start sending in the synchronous mode. If the a message wasn't processed in the defined period (in microseconds), FIXEdge/J will switch to the asynchronous mode.

sessionType=acceptor
senderCompID=FIXEdgeJCompID
targetCompID=ClientB
groups=Group_A
storeAndForwardEndpoint.enabled=true
storeAndForwardEndpoint.maxTimeForSyncSendingInUsec = 100

...

It is possible to manage the store and forward the queue to iterate through messages, remove , or add messagessome of them.

Methods

for (Iterator<MessageEvent> iterator = queue.iterator(); iterator.hasNext(); ) {
    MessageEvent nextEvent = iterator.next();
    if (<some condition>) {
        iterator.remove();
    }
}

MessageEvent first = queue.peek();
queue.remove(first);

Example of a rule for removing queued orders by cancel request

...