Session

What is a Session?

A session represents a channel of communication with the AMQP broker.

Each session runs in its own thread - meaning that messages received by different sessions are processed in different threads. Each thread is owned by the component used to communicate with the feed (rabbit channel). The long-running operations should not be invoked on those threads because this would block receiving new messages on that session. More than one session can be created on each feed instance. The session itself cannot be opened or closed (started or stopped). It opens/closes when the associated feed object is opened/closed.

When building a session, a message interest specifying the session scope must be provided. Message interest specifies which messages will be received by the associated session.

Only certain combinations of message interest / session combinations are permitted. The permitted combinations are as follows:

• If only single session is configured - it can be associated with any message interest.

• If multiple sessions are desired to be configured than the following combinations are allowed:

  • High priority and Low priority message interests at a time, or

  • Live messages, Prematch messages and Virtual sports interests altogether, or any subset of these.

How to create a session?

The code snippets (in Java and .NET) to create a session are as follows.

Creating session (Java)

OddsFeedSession session = oddsFeed.getSessionBuilder()
                .setListener(new MyMessageListener())
                .setMessageInterest(MessageInterest.AllMessages)
                .build();

Creating session (.Net)

SDK always creates just one connection to rabbit server (uses that connection for one unique channel for system messages - alive and snapshot_complete) and 1-3 channels for user messages depending on user configuration of sessions. Each session has one unique underlying channel.

Session ensures that feed messages are dispatched to the user code in the same order as they are put on the rabbit queue.

Once the messages are dispatched to the user code, you need to ensure that feed messages for the same sport event ID are processed in the same order as they were received and the feed messages for different event IDs should be processed in parallel.

Best Practices

The customer should extract only time critical data like odds from the message in this thread, and hand over the message to a different thread to do further API calls for translations. This is the action which usually helps the most with the message processing speeds and reduction of down times.