Well, at the end, the decision process is like the Osiris judgement, you have to put pros and cons in a balance: performance, scalability, easy use, flexibility, etc.

From my experience working with Java,  hibernate is not the decisive criteria by itself. I think that the problem is that the architect usually does not know well enough the potential of IRIS and decide to take the easy way.

You can check it from System Monitor Log of each Mirror member. You can see an example of the log:

05/22/23-07:22:26 [SYSTEM MONITOR] System Monitor started in %SYS
05/22/23-07:26:07 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Backup
05/22/23-07:33:01 [SYSTEM MONITOR] System Monitor started in %SYS
05/22/23-07:33:01 [SYSTEM MONITOR] Mirror state: Member type = Failover, Status = Synchronizing
05/22/23-07:33:31 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Backup
05/22/23-07:35:55 [SYSTEM MONITOR] System Monitor started in %SYS
05/22/23-07:35:56 [SYSTEM MONITOR] Mirror state: Member type = Failover, Status = Transition
05/22/23-07:36:26 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Waiting
05/22/23-07:36:26 1 alerts posted in messages.log
05/22/23-07:40:26 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Backup
05/22/23-07:58:15 [SYSTEM MONITOR] System Monitor started in %SYS
05/22/23-07:58:15 [SYSTEM MONITOR] Mirror state: Member type = Failover, Status = Waiting
05/22/23-08:06:43 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Backup
05/22/23-08:10:37 [SYSTEM MONITOR] System Monitor started in %SYS
05/22/23-08:10:37 [SYSTEM MONITOR] Mirror state: Member type = Failover, Status = Waiting
05/22/23-08:34:40 1 alerts posted in messages.log
05/22/23-08:35:10 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Backup
05/22/23-10:50:25 [SYSTEM MONITOR] System Monitor started in %SYS
05/22/23-10:50:25 [SYSTEM MONITOR] Mirror state: Member type = Failover, Status = Waiting
05/22/23-11:00:15 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Backup
05/26/23-11:03:06 [SYSTEM MONITOR] System Monitor started in %SYS
05/26/23-11:03:07 [SYSTEM MONITOR] Mirror state: Member type = Failover, Status = Transition
05/26/23-11:03:37 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Backup
05/26/23-11:05:08 [SYSTEM MONITOR] Mirror status changed. Member type = Failover, Status = Primary
05/26/23-11:05:10 1 alerts posted in messages.log

Hi Richard! sorry for the delay, I didn't see your message.

Well, for my experience with the websocket the Read timeout is not a problem when is defined as an empty value, if there is a connection error or the websocket is open your objectscript code will usually receive an inmediate response. In this case Read is working just as a "ping". In my example the client is not writting anything.

About the licenses I will paste an answer from other post of the community:

"This does not hold a license, basically the CSP gateway holds the data in it's pool, and at any time, a process can open the WebSocket via OpenServer and Read/Write the socket. Inside read is a call to ReadAsync if SharedConnection = 1."

https://community.intersystems.com/post/asynchronous-websockets-quick-tu...