Monday, May 19, 2014

Clustering Support in Domino WebSockets now available

***websocket project has been broken out into its own project, on openntf***

Hi All,
I just released version webshell-xpages-ext-lib 1.0.8 (parent project for websockets).  The latest release focuses on support for websockets in a clustered environment and increases the message size.  Please see my prior blog post for info. on the approach that was taken, and let me know if you exp. any problems bugs via github's issue tracker.  The documentation has been updated with the latest info. on how to setup for clustering.

As of release 1.0.8 for websocket: 
-Fixed configuration problems causing http server to hang (websocket server will not load unless configured correctly, better error messages if not configured) 
-Added @Profiled annotation to all runnables to measure performance via xpages toolbox 
-Added support for Domino server clusters (all users / apps across clusters can now dispatch messages to each other) 
-Altered the data structure of the fmSocketMessage document to allow larger messages via RTF append, or direct json attachments 
-Added some new notes.ini parameters for clustering and broadcasting (see webscket-setup.pdf) 
-Updated all the existing sample LotusScript agents to use the new data structure 
-Added two new sample agents “JSON File” & “JSON RichText” to serve as examples on how to use the new document data structure
below demo is still valid:


Wednesday, May 14, 2014

Bug Fixes & Supporting Server Clusters in Domino WebSockets

***websocket project has been broken out into its own project, on openntf***

Hi All,
Currently working on some bug fixes to make configuring the Domino WebSockets a bit friendlier.  Seems if the notes.ini settings weren't setup properly it could hang up your http server on restart, or the plugin will not work altogether.  Instead the admin / developer should see a nice error message stating the problem with the notes.ini settings.  In addition to the fixes for the config, I'm in the process of adding support for server clusters.  The below list summarizes the approach I am taking in supporting Domino server clusters:

1)  As part of the IUser/User object I added a host attribute and also persist that value to their fmUser document

2)  The thread that processes the queues will only process documents that match its current host.

3)  A new thread is monitoring the user status and updating / adding users to the ConcurrentHashMap that stores the Ids in memory on all servers in the cluster

4)  Upon receiving a websocket message directly from the client (i.e. in the chat example), the WebSocket server checks to see if the target user is on the same server, if yes, send them direct, if no, drop the message in the websocket.nsf queue to be picked up on the target user's host server via cluster data replication.

5) Each server in the cluster monitors one other in the cluster via a notes.ini parameter WEBSOCKET_CLUSTERMATE_MONITOR.  If the target clustermate goes down after N seconds configured in WEBSOCKET_CLUSTERMATE_EXPIRATION notes.ini param, the current server will alter the status of the online users to offline.

6)  Broadcast websocket messages had to be handled differently in a cluster, so I altered the behavior to just create one copy / online user and create a direct message.  In a cluster one server in the clustered environment must be listed as the broadcast server, or no broadcasts will go out.  If the server designated as the broadcast cluster goes down... one of the other servers will have to be manually setup to take over (sucks... will re-think this).

Below is a sample from my local dev machine configured with a clustermate on my dev centos box.

#start websocket settings


#debug/test settings


#security settings,

#network encryption settings


#clustered server settings


(note:  this has only been run / tested on my clustered dev environment)

First pass of the above should be up on github and openntf sometime this week.