Redirect events to a central server

Remoting SDK
1

Have two satellite servers. Let name this as

Server A
Server B

and one central server

Server C

  1. Theres any way to resend events to server C? To allow clients app connected to server c can get events generated on server A or Server B?

  2. Theres any way to send RO structs from Server A or Server B to Server C to allow clients connected to Server C read that structures?

  3. Another option. Any way to redirect service calls made in Server C, to Server A or Server B?

Bets regards.

2

If there is an easy way, I will love to hear it.

It will allow to create redundant servers and even a way to serialize those calls and stick them into queues and then replay those messages to other servers, so messages will never be lost.

That’s walking into messaging queues, which RO is still a bit behind.

3

Hi,

you can use several instances of Olympia (SessionManager+EventRepository), connected to the same DB server

see the Proxy Server sample

4

Evgeny,

Are you sure about having multiple instances of Olympia running? they will not collide in anyway? That will be great news for me, but I want to make sure we will not have some sort of lock or race condition.

For example, once an event sink is sent out do clients connected to different olympias, will they receive the messages?

Will they get duplicates? I internally have a master controller approach to message delivery where multiple controllers register themselves but only one is doing the part of delivering messages. If one fails, the other one jumps in. Dont know if Olympia is doing something like that, or if both olympias just run to db and whoever gets it first, delivers to everyone. If thats the case, we need to make sure that Olympia is not holding in memory subscriptions, it is synchronizing them with other Olympias or that it queries the db for them everytime.

7

Using Olympia servers is not an option. I have a lot of specifics code inside my server, but can please explain will that work? And why they need to be connected to same db?

There no chance to have the same behaviours on custom servers?

Will chem, btw, proxy servers don’t broadcast events ?

8

Sound very interesting to me. Can please explain in a little more detail that mechanism?

Best regards.

9

My mistake - Anton said that Olympia wasn’t designed for this scenario.

You can try to implement such feature with delphi DBSessionManager/DBEventRepository

10

if two your servers connect to different DB, clients connected to server1 will know nothing about clients connected to server2. so DB server that stores info about sessions and events should be the same.

you can implement it manually with DBSessionManager/DBEventRepository

in general, they can do it

12

Hi,

I use a lot of event sinks. Almost every action is notified / broadcasted to any listening service so it can act on it. Because we need redundancy of services, we need Olympia, is the only way to have two services and multiple clients connecting to each service on different computers receiving notifications.

As a good news, we have a lot of custom Delphi servers, so using Olympia as a way to propagate messages across multiple instances should not be an issue. Only problem with Olympia is the lack of redundancy, there is no Active/passive or Active/Active node scenario there so when it goes down. Everything goes down, until it is restarted, it usually recovers fast and it doesn’t go down as often so its fine.

On the other hand, I have a service that handles “Master Controller” scenarios. This scenario is the case where you have multiple services of the same kind running and requests can be made to any of them but only one should perform a specific action.

e.g. You have a service that once a session expires, removes the session. If you have redundancy in place for this service and have two of them running. Both will try to remove the session originating a race condition. But if internally you can have a way to check if you are the designated “master” controller, then internally in your code you can skip the code after.

It was implemented by making all services registering as controllers to a service “registry”. First one to do it, becomes the “Master Controller” (or Active controller). From this point on, this registration service will send out a heart beat to all registered controllers to make sure they are alive. Once they get the heart beat they reply asking to be controllers again, but only the
designated “master controller” will receive confirmation that he remains as controller. This heart beat also allows each service to update their status as “master controllers” or not.

If the official master controller doesnt report itself, after a few attempts the registar service will then pass the master controller crown to a different service and continue from there.

This works for multiple readers, single writer scenarios. Something like this could also make a redundant Olympia work, but I haven’t try it.

Using the DbRepository etc as a sample to implement your own Olympia is not that simple and it is 90% of what Olympia does.

I added on top of RO event sinks a topic, header and direct exchanges mechanism similar to other messaging queues, but RO shows some cracks on service crash scenarios and heavy threaded load. Recovery is though and usually involves restarting services which on a “micro” services scenario can not be done.

Replaying messages will be nice and thats where the “proxy scenario” where those calls can be persisted somewhere and “replayed” when a service recovers could be nice.

13

Thanks Esteban. Great work. I hope theres a easiest solution. My main concerns is have events and internal structures available. Testing proxy right now. Seems likes the LOGIC solution is trig that via. If don work I will use database (raising events and saving structures). Imperfect and no sense solution having RO but… need solve that soon.

Best regards