What is the recommended practice for WebSockets in a load balanced environment?

For example, load balancers receive and disperse web traffic to N number of IRIS application servers.  The Application servers are in front of an IRIS mirror set.

Client "A" connects (subscribes) to IRIS application server "1" because the load balancer pointed it there.  Client "B" connects to a different application server "2" because that is where the load balancer told it to go.

Both clients are in the same application and want to hear the messages.

Application server "1" publishes a message and Client "A" hears it but Client "B" never hears the message because Application server "2" is not publishing it, only "Application Server "1", since clients are connected to a specific application server.

What is the recommended setup to ensure that when any IRIS instance issues an outgoing web socket message all clients connected to any IRIS application servers receive it?

This is less about a community wide coding guideline and more about the validity and helpfulness of a code smell being added within CachéQuality.

In the OP the examples are basic but provide code that executes and just fine even though the code/syntax could be much better.

The code smell that Dainel is speaking of would identify areas where this, less than ideal, syntax is used so it can either be prevented or worked on as tech debt.

If the above code existed and there was a business need to enable support for delimited identifiers there would be problems.

This rule may break into multiple rules, one to identity the use of double quotes in embedded SQL, one for the use in SQL Statements.  Then also as Eduard suggested, a rule for parametrization as a whole.


As a customer of CacheQuality/Lite Solutions I have been working with @Daniel Tamajon and staff.  They have been very responsive to all inquiries and responded incredibly fast any time I brought a bug or request to their attention.  The plugin for VSCode works very well and has been helping me to identify code smells as I am developing, prior to checking in for full SonarQube scanning.

I highly recommend everyone give it a shot, it works seamlessly with the VSCode extension.

Just my 2 cents.

The %INLIST predicate is meant to be used against properties of type %List.  Your property is defined as a %String that happens to contain a delimited string of values.

SQLCODE should have contained  an error code when you attempt to fetch the cursor (-400).

To do what your trying to do you could either use the %CONTAINS predicate IE: "...AND routeList %CONTAINS (RouteName)"

Or you could convert the string to a list.  This would convert your delimited string property to a %List, allowing %INLIST to function correctly.


Best solution would probably be to convert the property to %List if possible or even another table.

Hope that helps!