Examples of lt.baltic_amadeus.jqbridge.providers.ChannelHandler

Handles sending or receiving of messages through a virtual communication channel.

For the sake of simplicity the interface contains methods for sending and receiving of messages but each separate instance if ChannelHandler is only required to perform either sending or receiving of messages depending on which side of a virtual channel it is handling.

It is guaranteed that for sending side the receiving methods will not be called and vice versa. In case there are separate implementations of ChannelHandler for sending and receiving sides unimplemented methods should throw {@link UnsupportedOperationException}.

Independence and thread safety

Each ChannelHandler must act independently of other instances. That is:

it must be able to work in parallel in a separate thread of execution
it must be able to commit and roll back the message sending/receiving transaction independently of other channel handlers

It is guaranteed that each instance of ChannelHandler will be accessed by one thread at a time with the exception of stop() method. It may (and usually will) be called concurrently by another thread. All non-constructor methods except stop() will normally be accessed only by one thread throughout the lifetime of a ChannelHandler instance.

Sending

Message sending is performed using one single method {@link #sendMessage}. Operation is atomic and automatically committed - every message is independent of other messages and each send operation either succeeds or fails without additional confirmation.

Receiving

Message receiving is performed in two stages with transaction handling. In the first stage the message is downloaded from its communication port using {@link #receiveMessage} method. It is then processed and forwardedto another side of communication channel. As soon as the message sending succeeds or fails one of transaction handling methods are called.

If the message has been successfully forwarded then {@link #commit}method is called signifying that the message has been successfully received and can be removed from transmission queue. If the message forwarding failed for some reason (communication, processing or other reason) {@link #rollback}method is called signifying that the message must be returned to the transmission queue and its delivery must be reattempted.

Closing of channel

Sending endpoints are closed in one stage using {@link #close()} methodwhich may be called after a respective port has been closed. Receiving endpoints are closed in two stages. First, {@link #stop()}method is called which should close the receiving side of the channel and stop all channel instances (worker threads). stop() is called while the channel and respective ports are still operational. The second stage matches that of the sending endpoint.

When close() method is called the channel handler should release any resources allocated to this communication channel. If a transaction is still active during the closing of channel it must be rolled back automatically. @author Baltic Amadeus, JSC @author Antanas Kompanas