I am running a single instance of terracotta server 3.7.5 with two java clients.
I have few questions related to this configuration.
1) If Teracotta Server goes down I want to receive an exception in clients. Is it possible ?
2) If Teraacotta server comes back up I want these clinet to reconnect to server.
I have came across this URL http://terracotta.org/documentation/4.0/terracotta-server-array/high-availability
I am not sure if these configs are vaild for open source 3.7.5
Regards,
Amber
Yes, this is possible.
1) If Teracotta Server goes down I want to receive an exception in clients. Is it possible ?
A: You can use Nonstop Caching caching for this .
http://terracotta.org/documentation/3.7.4/enterprise-ehcache/reference-guide#nonstop
Use
2) If Terracotta server comes back up I want these clinet to reconnect to server.
A: You can use Rejoin for this along with NonStop.
http://terracotta.org/documentation/3.7.4/enterprise-ehcache/reference-guide#71266
Related
I am trying to setup load balanced environment having 2 application server instances. I am unable to make spring web socket relay messages to all instances. Let's take a example to describe my problem better:
Server 1 : Responsible for job executions and 35% user load.
Server 2 : 100% user load.
Both are connected to same database schema so job request can come for any server instance but will get executed on Server 1.
Now, I have used spring web socket plugin for my GRAILS application and I push messages to browser using
brokerMessagingTemplate.convertAndSend(user.notificationChannel, ((notification.toMap(user) as JSON)).toString())
It was working fine on single server setup. But on multi-server setup,
notifications are only received on Server 1 as that is the one calling the code block, if reverse the scenario, then vice-versa result is observed.
How can I push same notification to all server instances, so that user always gets the notification no matter what server instance he is on?
I initially thought of utilising a common queue like RabitMQ but that will add to system requirements and will get disapproved by client.
NOTE: Third party service solutions won't work in my case as applications are on intranet and don't have internet access.
websockets by default point to a hostname/ip address - whilst you could setup a dns record / hostname that points to multiple different ip's / servers. This itself would break communication flow of the websockets if it sent handshake to one and the message to another.
The most simplest approach would be to think of some db table that is shared across both and as each instance comes up/alive it records its local ip / socket port to a db table - each instance can then read this table and work out at any point which are the hosts to transmit a socket message to - (this table would need to managed somehow - upon a brand new bootup ) it would be empty and would popuplate as instances came up - something again to manage when a host is taken down shutdown.
Each instance would then be running an ws internal client. When a message is sent the ws client would be triggered attempting to find all alive websocket servers "from the db" to each using the ws client it would attempt to connect and send the message on. Each would then get the message and either broadcast to all connected users or if it is from user x meant for user x then like per chat plugin it would relay it only to user x if found on server y and so on.
this then keeps it all inline with 1 technology controlling the entire process websocket server that has its own client which relay to the end multiple instance ws socket server
Wanted to build a chat like application(i.e bidirectional message passing to multiple connected clients). Looked at the Faye gem but it opens a new port apart from port 80.
The big problem is that if the client is behind firewall all access to other ports except 80 are restricted and not all the hosting sites provide the support.
The ActionController::Live component does not have any mechanism to register the clients so that the message can not be passed to the registered clients on a specific event occurance.
Looking for a solution where the alive clients are stored in a collection(array or somthing like that) and when any of the alive client sends a message then the collection can be iterated and the messages can be written on it. All of these must happen only through port 80.
Good question - having implemented something similar, let me explain how it works:
Connections
A "live" web application is not really "live" at all - it's just got a persistent request; meaning it still works exactly the same as a "normal" Rails app, except clients don't close the connection (hence why you're interested in opening another port)
The way you handle the request is where the magic happens. This is as much to do with the client-side, as it is with Rails (server-side)
Clients
When you connect to a "chat" application, your browser is opening a live connection with the server. This will typically be done with either server sent events (Ajax long polling), or web sockets
The way this works is to open the connection using the normal Rails ActionDispatch middleware, and then allow you to connect
If you've played with ActionController::Live functionality, you'll find that it's not a typical controller-action. It's actually a separate technology (like resque or Redis) which you call from another controller action. This gives room to do cool things with
Server
The way you'd handle something like this is to separate the "live" functionality and the "normal" Rails app. It's one of the current down-falls of Rails - in that it's probably better to implement something like nodeJS with socket.io to handle the live data (with an endpoint like chat.yourapp.com), whilst using Rails to handle authentication & authorization
From a server perspective, its job is to handle incoming & outgoing requests -- not to handle persistent connections. So I guess you may want to look at ways you could "outsource" the websocket connectivity. Admittedly, my experience is slightly thin in this area, so you may do well searching the net
Solutions
We've had a lot of success using a third-party system called Pusher
This is a web socket system which allows you to open a persistent connection as a client, and integrates with Rails in a similar way to Redis (you can push to it)
This means you can host the "chat" application with Rails (http://yourapp.com/chat), send the messages to your Rails app (http://yourapp.com/chat/send), and handle the incoming chats from pusher (or similar)
Maybe you want to use my open source comet web server (https://github.com/TorstenRobitzki/Sioux). There is a ruby web chat example. I use this to implement an interactive role playing map with rails (http://dungeonpilot.com).
I am making an application where I want to have a sign-in within the ruby client app which is supposed to connects to a Ruby on Rails server. This is similar to what you do in applications such as Dropbox. The user somehow provides their username and password, and the ruby program should connect to the server establishing a session. After the initial sign-in I need to transfer data between the client and server (potentially a lot). I have looked at web-sockets for this, however I can't find a way to set this up properly.
The Rails server uses Devise for authentification, and I would prefer to keep it that way if possible.
I have not been able to figure out how I can set up this connection. Any hints for where I should start looking?
If you want to have a 'persisten' connection between your client and server, I suggest you use something like 0MQ socket which a kind of 'super-socket 'library with bindings for ruby. On the server side, you would 'bind' to an IP/port, on the client side you would 'connect' and then you could use a connection type of REQ/REP (Request/Response). If, at any time the client disconnects, this doesn't 'blow' the binding on the server side. If the server side disconnects, this doesn't blow up the client side (it just block on waiting for the answer unless you define a timeout).
There are other options also for non-blocking operation between the client and the server.
Situation: Two web servers, and a browser client. The client has an open websockets connection with Server A. Server A decides that this client should really be serviced by Server B.
I would like to know if there is any established technique for performing this hand-over?
It would be great if this could happen as invisibly as possible for my client side code - but I haven't come across any feature which would allow this.
Best I have come up with so far is Server A sending a 'you should really deal with Server X' message, client closing the WS session and then sending some http request which will get routed to the correct server, and upgraded to WS. I can see the presense of load balancers making this complicatied though.
Any thoughts?
From a programming point of view, the socket connection is treated as an open file handle, and that's what you are trying to pass along. For that, I would check out the question "Portable way to pass file descriptor between different processes" for a handful of methods.
But if you are not writing your own web server, and are looking for an off-the-shelf method for Apache, etc, this probably won't help you much.
I'm in search of a RELIABLE websocket server for ROR 3.Now we're using socky. It is unreliable. We like it because it has flash fallback, so it suppose to work on older browsers...but again - it is unreliable.
Do you know any good websocket server for ROR with fallback (i.e. supporting all browsers)
alternatives are:
socket.io (raw Websocket for NodeJS)
juggernaut (Complete Bayeux Protocol for NodeJS/Rails)
faye (Complete Bayeux Protocol for NodeJS/Rails) with a Ruby-Server
A tip: don't use ruby as websocket server, go for NodeJS - we handle thousands of messages every hour without any issue.
We used the most simple setup possible to make it work - and it works ;)
Our Setup:
Rails 3.0.9
Redis
NodeJS
Socket.IO
How we set it up:
Rails --PUB--> REDIS --SUB--> NodeJS --WEBSOCKET (SOCKET.IO)--> Client
Article Redis PubSub - How does it work?
Another tip: Avoid authentication if possible
Here's our case:
We have something like a project management tool with a virtual filesystem. Let's say you're viewing a folder while someone else of your team uploads a new file. Now we have to inform you that your view is out of the date - we send a message like:
folder_id | last_change_timestamp
to the channel folders:#{folder_id}
now the client (which listens to folders:#{folder_id} receives that messages and sees "whoops my view is out of date" and shows a message "Your view is outdated, please click >here< to refresh".
The good thing is that we don't need any authentication because:
if you have no access to the project you would have to guess the folder_id to subscribe to the channel
even if you manage to subscribe to the channel the only information you get is that something has changed - not more not less ;)