Olympia Server

Overview

Olympia Server is an out-of-process state and event storage server. It can be used to create load-balanced server farms where multiple instances of the server application run on different machines across the company network, and yet share client session data, allowing client applications to seamlessly connect to any randomly available server.

One cornerstone of scalability is the ability of server applications to grow beyond a single server instance in order to accommodate for increased client traffic that exceeds what a single server machine can physically handle.

Designing applications with statelessness in mind and storing as little client-specific data in service instances as possible is a good starting point for building services that can scale up (i.e. accommodate increasing client load within a single server instance) and scale out (i.e. spread further increasing load out across multiple servers). But at the same time, many applications rely on at least a minimum of client state to be known, be it in the simplest case to merely authenticate users, or to provide more complex client-server interaction.

Remoting SDK's session management infrastructure has always made it easy to maintain client information while allowing service implementations to remain scalable, but most provided session managers were confined to a single server instance, or required manual setup of a shared database to store client state.

Olympia Server solves this problem by providing a dedicated and ready-made server application that can store shared session data and push events for a variety of separate Remoting SDK server applications. Simply installing an instance of Olympia Server on the server farm will allow all servers on the network to share client state and maintain a central repository for client events. Clients can communicate with any of the servers - be it through round-robin load balancing or more sophisticated load distribution mechanisms - and their session data will seamlessly be available.

Olympia Server uses database to store session and event data, so even on restart it won't lose user session data and event subscriptions.

Deployment

Shipping as pre-compiled server executable with all editions of Remoting SDK, Olympia Server can be deployed along with .NET and Delphi servers alike, and runs on Windows, as well as Linux and Mac OS X (requiring Mono to be installed).

A single Olympia Server instance can maintain shared state for many Remoting SDK servers, whether they are separate instances of the same server applications or different and unrelated servers.

Olympia can be run as a standard WinForms application, as a Windows service or as a daemon on Linux or Mac OS X hosts.

The Olympia Server deployment process is quite straightforward. All Olympia Server files are placed into a separate folder ...\RemObjects Software\RemObjects SDK (Common)\Olympia during installation of Remoting SDK. This folder contains all files required by Olympia Server to run.

Steps required to deploy Olympia Server to a different host are:

1. Copy Olympia Server files to the target host.

2. Adjust the Olympia.daConnections file as described in the section below.

Used data storage

Because Olympia Server is internally built upon Data Abstract for .NET, it can use the full power and flexibility of Data Abstract and its schemas to talk to any database; however, it comes pre-configured to use the internal SQLite based storage in order to run out-of-the-box with zero setup and configuration necessary.

Database creation scripts for MS SQL, SQLite.NET and Firebird are shipped with the Olympia Server. Please refer to this section to find out how to configure Olympia to use one of these database servers.

Olympia Server can also be configured to run in so-called In-Memory mode, where a virtual in-memory SQLite database is created. This mode is usually faster, as once it is active no disk operations are required to store data, however the major disadvantage is that all session and event data will be lost if/when Olympia Server is restarted.

Accessing Olympia Server

Remoting SDK provides session and event components that make it easy to use Olympia Server. See OlympiaServerSessionManager and OlympiaMessageQueue (in .NET) or TROOlympiaSessionManager and TROOlympiaEventRepository (in Delphi).

Olympia Server can be accessed via SuperTCP channel. By default, Olympia Server listens to port 8011 (the port number is configurable via the Olympia configuration file, see below).

To get application to work with the Olympia server, add a SuperTCP client channel to it, set its port to one that Olympia Server listens to and bind the Channel property of the OlympiaServerSessionManager (TROOlympiaSessionManager) to this channel. If the OlympiaMessageQueueManager (TROOlympiaEventRepository) is used, then make sure that its Channel property is also bound to the SuperTCP channel instance.

Database engine used by Olympia Server

By default, Olympia is configured to use SQLite.NET as the default database engine, but you can also use MS SQL, Firebird or PostgreSQL to store Olympia Server data.

To change the database engine used please follow steps below:

Step 1. Create a database using the SQL script below.

CREATE TABLE [EVENTDATA] (
    [EVENTID] char(36) NOT NULL
    , [ORIGIN] char(36) NOT NULL
    , [SENT] datetime NOT NULL
    , [DATA] image NULL
);

ALTER TABLE [EVENTDATA] ADD PRIMARY KEY ([EVENTID]);


CREATE TABLE [EVENTUSER] (
    [USERID] char(36) NOT NULL
    , [ACTIVE] [bit] NOT NULL
    , [LASTUSE] datetime NOT NULL
);

ALTER TABLE [EVENTUSER] ADD PRIMARY KEY ([USERID]);

CREATE INDEX [IX_ACTIVE_EVENTS_FILTER] ON [EVENTUSER] (
    [ACTIVE] ASC
    , [USERID] ASC
);


CREATE TABLE [EVENTUSERDATA] (
    [EVENTUSER] char(36) NOT NULL
    , [EVENTID] char(36) NOT NULL
);

ALTER TABLE [EVENTUSERDATA] ADD PRIMARY KEY ([EVENTUSER], [EVENTID]);


CREATE TABLE [SESSION] (
    [ID] char(36) NOT NULL
    , [APPLICATIONID] char(36) NOT NULL
    , [LASTACCESSED] datetime NOT NULL
    , [DATA] image NOT NULL
    , [CREATED] datetime NOT NULL
    , [EXPIRED] int NOT NULL DEFAULT 0
);

ALTER TABLE [SESSION] ADD PRIMARY KEY ([ID]);


CREATE TABLE [EVENTSUBSCRIPTIONS] (
    [USERID] [char](36) NOT NULL
    , [SUBSCRIPTIONID] [varchar](128) NOT NULL
);

ALTER TABLE [EVENTSUBSCRIPTIONS] ADD PRIMARY KEY ([USERID], [SUBSCRIPTIONID]);

CREATE INDEX [IX_EVENT_SUBSCRIBERS] ON [EVENTSUBSCRIPTIONS] (
    [SUBSCRIPTIONID] ASC
    , [USERID] ASC
);

Step 2. Create or modify the Olympia.daConnections file using Schema Editor, some XML editor or even Notepad. Set the default property to True for one of the predefined connections and modify its connection string - it should point to the database created during the step 1.

Default contents of Olympia.daConnections file:

<?xml version="1.0" encoding="UTF-8"?>
<Connections>
  <PoolingEnabled>True</PoolingEnabled>
  <PoolingBehavior>Wait</PoolingBehavior>
  <MaxPoolSize>10</MaxPoolSize>
  <WaitIntervalSeconds>1</WaitIntervalSeconds>
  <PoolTimeoutSeconds>60</PoolTimeoutSeconds>
  <Definitions>
    <Definition>
      <Description />
      <ConnectionString>MSSQL.NET?Server=localhost;Database=Olympia;Integrated Security=SSPI</ConnectionString>
      <ConnectionType>MSSQL</ConnectionType>
      <Default>False</Default>
      <Name>Olympia.MSSQL.NET</Name>
    </Definition>
    <Definition>
      <Description />
      <ConnectionString>SQLite.NET?Server=localhost;Database=%OLYMPIA%\Olympia.sqb;Synchronous=Off;DateTimeKind=Utc</ConnectionString>
      <ConnectionType>SQLite</ConnectionType>
      <Default>True</Default>
      <Name>Olympia.SQLite.NET</Name>
    </Definition>
    <Definition>
      <Description />
      <ConnectionString>FB4.NET?Server=localhost;Database=%OLYMPIA%\OLYMPIA.GDB;UserID=sysdba;Password=masterkey;</ConnectionString>
      <ConnectionType>Interbase</ConnectionType>
      <Default>False</Default>
      <Name>Olympia.FB.NET</Name>
    </Definition>
    <Definition>
      <Description />
      <ConnectionString>NPGSQL.NET?Server=localhost;Database=olympia;User ID=postgres;Password=masterkey;</ConnectionString>
      <ConnectionType>PostgreSQL</ConnectionType>
      <Default>False</Default>
      <Name>Olympia.NPGSQL.NET</Name>
    </Definition>
  </Definitions>
</Connections>

Delete all other connection definitions as they aren't needed anymore.

Step 3. Put the modified Olympia.daConnections file next to ROOlympiaServer.exe

Step 4. Tweak the MaxOlympiaPoolSize setting in the Olympia.json configuration file (see below).

Olympia Server configuration file

Advanced Olympia Server settings like port used by it or session/events timeout can be configured via the server configuration file.

Starting with early builds of Remoting SDK v10 the Olympia Server configuration file format has been changed from the monstrous .xml file format to a more lightweight JSON. The default contents of the Olympia.json configuration file is

{
  "ServiceName": "ROOlympiaServer",
  "Port": 8011,
  "EventTimeout": 1800,
  "SessionTimeout": 1800,
  "PoolSize": 1,
  "InMemoryMode": false 
}

The following parameters can be set via are suppo

Option	Default Value	Description
ServiceName	ROOlympiaServer	Name of the Windows Service running Olympia Server
Port	8011	Port used by Olympia Server to provide its services
EventTimeout	1800	Event timeout (in seconds). After this timeout undelivered events data will be considered as expired and will be purged from the storage
SessionTimeout	1800	Session timeout (in seconds). After this timeout unused sessions will be considered as expired and will be purged from the storage
PoolSize	1	Database connection pool size. This value should be tweaked if the database engine used by Olympia Server has been changed. Concrete value depends on database server settings, network throughput, Olympia Server load etc.
InMemoryMode	false	This parameter allows to enable so-called "Olympia In-Memory Mode". In this mode a virtual in-memory SQLite database is created. This mode is usually faster, as once it is active no disk operations are required to store data. However be used in production with caution, because all session and event data will be lost if/when Olympia Server instance is restarted. In general this mode should only be used during application development and testing

Olympia Server startup parameters

Parameter	Description
-im /im --inmemorymode /inmemorymode	Starts the server instance in the In-Memory mode
-i /i --install /install	Installs Olympia Server as a Windows Service
-u /u --uninstall /uninstall	Uninstalls Windows Service used by Olympia Server
-c /c --commandline /commandline	Starts Olympia Server in command line mode