com.teraspaces.qwfix
Interface FIXSessionMessageListener

public interface FIXSessionMessageListener

The listener interface for receiving FIXSession message events. The class that is interested in processing a FIXSessionMessage event implements this interface, and the object created with that class is registered with a component using the component's addFIXSessionMessageListener method. When the FIXSessionMessage event occurs, that object's appropriate method is invoked.

Method Summary

void	applicationMessageReceived(FIXMessage message) Occurs when an application message or a "SessionReject" message is received but has not been sent to application yet.
void	applicationMessageSending(FIXMessage message) Called when an application message sending.
void	logonMessageReceived(FIXMessage message) Called when a log on message is received.
void	logonMessageSending(FIXMessage message) Called when a log on message is sending.
void	messageSent(FIXMessage message) Called after an message is sent.

Method Detail

applicationMessageSending

void applicationMessageSending(FIXMessage message)

Called when an application message sending.

Application can further modify the message in this handler.

This event is only triggered when an application message or a "SessionReject" message is being sent. Administrative FIX messages such as "LongOn", "LogOut", "HeartBeat", "TestRequest" or "SequenceReset" won't trigger this event.

This event only occurs after a "new" message (administrative or application message) is sent. Messages resent in response to a ResendReq FIX message will not trigger this event.

The message will be first sent to the outgoing queue after this event is processed. Note the actual time when the message will be actually sent to the peer over network depends on the system load and network conditions.

It's recommended that FIXSessionRejectException is the only exception thrown out by event handlers.

Parameters:

message - the message

applicationMessageReceived

void applicationMessageReceived(FIXMessage message)

Occurs when an application message or a "SessionReject" message is received but has not been sent to application yet.

Received message is read only and can not be changed. However, an FIXSessionRejectException can be thrown out, which will result in a session level reject.

By hooking up this event, application can peroform further vaildation of the FIX message. Application can also reject the message before it reaches the business logic code by raising a FIXSessionRejectException.

This event is only triggered when an application message or a "SessionReject" message is received. Administrative FIX messages such as "LongOn", "LogOut", "HeartBeat", "TestRequest", "SequenceReset" or "Reject" won't trigger this event. The only exception is "SessionReject" message.

After this event is triggered, the message will be put into the incoming message queue. The actual time when the message will be processed by application logic depends on the system load.

Parameters:

message - the message

messageSent

void messageSent(FIXMessage message)

Called after an message is sent.

Once the message is sent, is becomes read only. No further modification is allowed.

This event is triggered after the message is successfully sent to the recipient over the network. Note it's still possible that the message is still in the memory buffer of the hardware network interface card. It's not guaranteed that the receipient will receive the message because the TCP protocol is not guaranteed. Nevertheless, FIX protocol has recovery feature if the network is down.

This event is triggered by all types of FIX messages, including administrative messages.

This event only occurs after a "new" message (administrative or application message) is sent. Messages resent in response to a ResendReq FIX message will not trigger this event.

This event is different than applicationMessageSending event in that the applicationMessageSending event happens when the message is going to be put into the outgoing message queue. The message in the outgoing queue will not be assigned a real FIX MsgSeqNum until this event is triggered.

The handlers to this event should not throw out any exception either. Any exception catched will result in a warning message in system log and will be ignored.

This event is defined doesn't mean one has to use it. I personally can't find any reason to use it.

Parameters:

message - the message

logonMessageSending

void logonMessageSending(FIXMessage message)

Called when a log on message is sending.

Application can further modify the message in this handler.

Parameters:

message - the message

logonMessageReceived

void logonMessageReceived(FIXMessage message)

Called when a log on message is received.

Received message is read only and can not be changed. However, an exception can be thrown our, which will result in an logout, because this is a log on message handler.

Parameters:

message - the message