Wednesday, May 14, 2014

Bug Fixes & Supporting Server Clusters in Domino WebSockets

***websocket project has been broken out into its own project, xockets.io 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

WEBSOCKET_PORT=8889

#debug/test settings

WEBSOCKET_DEBUG=false
WEBSOCKET_TEST_MODE=false

#security settings

WEBSOCKET_FILTER=com.tc.websocket.filter,com.tc.websocket.filter.AllowedCharsFilter
WEBSOCKET_ALLOW_ANONYMOUS=false

#network encryption settings

WEBSOCKET_ENCRYPT=false
WEBSOCKET_KEYSTORE_PATH=C:\websocket-certs\keystore.jks
WEBSOCKET_KEY_PASSWORD=keypassword
WEBSOCKET_KEYSTORE_PASSWORD=storepassword
WEBSOCKET_KEYSTORE_TYPE=JKS

#clustered server settings

WEBSOCKET_CLUSTERED=true
WEBSOCKET_BROADCAST_SERVER=CN=mambler-mac-win/O=marksdev
WEBSOCKET_CLUSTERMATE_MONITOR=CN=centosdev/O=marksdev
WEBSOCKET_CLUSTERMATE_EXPIRATION=15



(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.



thanks



-Mark

1 comment:

Anonymous said...

Nice work - just the kind of stuff we need in Domino, XPages et al. The RT web is going to explode (currently is). This is needed to stay current.

It's a bit quiet around XPages at the moment, I wich IBM blogged more frequently on how they see the XPages and platform evolve, and what they are currently working on. We need those frequent teasers!