New to LIghtStreamer - deployment in a load balanced app server environment

Team,

I am at the owner/architect of a newly launching startup.

I have a web app in a load balanced with (sticky sessions) and clustered session scenario.

I want to pub/sub from LightStreamer and may use other items for chat.

HOwever, I am not clear on a few things.

Load Balancing, I

I will have clients on 1-n application servers posting events and listening for events (messages).

The lightStreamer servers do not communicate with each other per my understanding.

How would an adapter publish data to al lightStreamer instances behind a load balancer/?

Also, how could two clients receive events unless they are connected to the same, lightstreamer server.

I suppose the adapter , could write events to all servers and if there is a timeout, the message could be removed

from a server in which the client is not connected.

Please advise

thanks

Hi,

for a better understanding of the general interaction between client, server and adapter, you can refer to the sequence diagrams shown at pages 17-18 of the "General Concepts" document.

As you can see, once the first client subscribes for a specific item, the Lightstreamer sever activates such subscription on the adapter, which in turn starts to send back asynchronous events that will be used by the server to generate updates for the client.

Successive subscription requests for the same item (and the same schema) coming from other clients connected to the same Lightstreamer server instance will be served without asking anything to the adapter: the server simply will notify all the clients with events pumped by the adapter.

In a clustered environment, the load balancer routes the incoming subscription requests from all the clients to different Lightstreamer servers. That means that a specific Lightstreamer server instance can notify only the clients "attached" to it.

To satisfy your requirement, you need to implement the necessary application logic in order to keep in sync different instances of the adapters to the the same item (representing your chat room), for example centralizing all the messages to some external broker or backend system.

You can get some inspiration analysing the source code of Basic Chat Demo example, more specifically looking inside the Java adapter code. Consider, however, that the example has been designed to allow the JavaScript clients to "talk with each other" only if connected to the same Lightstreamer server instance.

I also would remember that clustering feature is not available in the Moderato edition.

Regards,
Gianluca

Team,

I reviewed this however it seems that in the pub/sub use case, all events and clients must be on the same server instance.

My use case is that I have clients connecting from different application servers and they will publish events to a centralized highly available data store.

I would like to have my clients receive notifications without being connected to the same light streamer server instance.

This seems possible with the response that you type above ( I have yet to review in detail the sequence diagram) . A client connection could trigger a dataAdapter event to send notifications from the centralized data store that it is only concerned about.

Please advise

thanks

Hi Chris,

yes, a client connection could trigger a Data Adapter to put and get data from a centralized data store, that should act as a "broker" for each Data Adapter deployed into each single Lightstreamer instance, in order to properly dispatch the messages even to clients not bound to a specific server.

Regards,
Gianluca

Quote:

---

Originally Posted by gianluca.finocchiaro

Hi Chris,

yes, a client connection could trigger a Data Adapter to put and get data from a centralized data store, that should act as a "broker" for each Data Adapter deployed into each single Lightstreamer instance, in order to properly dispatch the messages even to clients not bound to a specific server.

Regards,
Gianluca

---

Ok, will look more detailed into this. One concern thought is that each client would be subscribing to their own private items and how to manage this within DataAdapter instances.

I looked at the chat example adapters (referenced earlier in the thread)- this is not trivial- especially with the introduction of AdapterSets.

I supposed one could periodically get all the subscription items per lightstreamer instance and then generate the necessary data and publish this to each client

Hi Chris,

May ask you to describe, at a higher level if you prefer, the message flows you would like to arrange in your scenario? In a previous post you talked about "private item", which is not exactly the case managed by our Chat Demo, where a single public item "chat_room" is used to notify all clients about incoming chat messages.

Regards,
Gianluca

Quote:

---

Originally Posted by gianluca.finocchiaro

Hi Chris,

May ask you to describe, at a higher level if you prefer, the message flows you would like to arrange in your scenario? In a previous post you talked about "private item", which is not exactly the case managed by our Chat Demo, where a single public item "chat_room" is used to notify all clients about incoming chat messages.

Regards,
Gianluca

---

team,

I aim to have each site user to be able to subscribe to a to "channel" that would broadcast (push) any event to them
that they would have a particular interest in.

for example, if 20 users are logged in the web app, then 20 client connections to lightstreamer instances . All events would be stored in a shared data store.

Each adapter(s) within the lightstreamer instances should be able to handle connected clients and get any data (if exists) and route it to the clients.

each "channel" is private to each logged in user. That is User A, would not be able to see any messages for User B.

In pursuit of a solution...

#1. I suppose there are api methods that would retrieve a list of connected clients

#2. the adapter could use this list of client( and associated meta data) to generate data and send to those connected clients

Ok, there are multiple ways in which the data flow can be mapped in terms of items.
In our simple chat implementation, we mapped items to chat rooms, so that different users could subscribe to different chat rooms and receive different data.
On the other hand, you can map a different item to each user, then feed each item with the data that pertains only to that user, depending on the chat rooms she is following.
For hints on the suggested way to work with user specific items, you may see the example in the getItems javadoc.

There is no direct interface to receive a list of connected clients.
What you can do is to implement the notifyNewSession and notifySessionClose methods in your Metadata Adapter to keep track of all the client sessions.
When a client is connected, you should also assume that it will subscribe to the corresponding user-specific item;
if the user name is userA, we may call it "data_for_userA".
The client may send chat messages through the sendMessage method supplied by the client API and this will trigger the notifyUserMessage callback in the Metadata Adapter.
The client may also specify the requested chat rooms through the sendMessage method.

With these premises, the application can route each message to the pertaining clients by feeding the dedicated "data_for_*" items in the Data Adapter.
The above is needed regardless that there is one or multiple Server instances. In the latter case, however, the messages targeted to a user userB should be routed to the Server instance to which userB's client is connected (hence, whose Data Adapter has received the subscription request for the "data_for_userB" item). Unfortunately, this routing, as already pointed out by Gianluca, is not assisted by Lightstreamer.