Logging in from Caché on one server to Caché on another server

Question

Question

Adrian Bourner · Jul 23, 2020

Until this week, my customer had Ensemble writing HL7 messages to my TCP listener, working fine on ageing physical servers (Windows Server 2003, Caché 2009). They had four app servers (app1, app2, app3 and app4) with an overarching DNS simply called "app". Ensemble was connecting to "app:port", and it somehow found whichever of the four app servers my background listener was running on, and the interface worked fine for 10+ years.

They have now moved to shiny new virtual servers (Windows Server 2016, Caché 2018) and now have only two app servers(appv1 and appv1), with an overarching DNS of "appv". However, Ensemble no longer consistently finds the appv server that my listener is running on, so we have had to change the Ensemble connection to always connect to "appv2:port", and the users have to ensure that the listener is also running on appv2. Not ideal, and certainly reduces any resilience capability.

People who are far more knowledgeable about networking than I am have concluded that they don't understand how it used to work, let alone why it no longer does.

Therefore I now need to get my listener running on both servers simultaneously.

For a while I had hopes of using the "joblocation" parameter on the JOB command (a new parameter to me), but it turns out that that only works across ECP, which isn't available at this site.

I'm now thinking that I will need to initiate a login from whichever appv server my background control process is running on (it's random, as it inherits from the interactive user, who lands on whichever server their load-balancer points them to) to the other appv server and JOB the listener on there.

Finally, to my question - how, just using Caché Object Script, do I initiate a login from Caché on appv1 to Caché on appv2, or vice-versa, and then run a specific COS .int routine when it gets there?

I've done similar things, but only swapping namespace on the same app server, never to the same namespace on another app server i.e. S T1=$ZU(5,namespace). And yes, I know this is old, and no longer supported, but my functionality that used it is also deprecated.

Forgive any howlers in this - I am simply a long-in-the-tooth green-screen Mumpster!

Discussion (4)1

Log in or sign up to continue

Robert Cemper · Jul 23, 2020

You might be inspired by this:

https://community.intersystems.com/post/simple-remote-server-control

In principle, a job is hanging around waiting for orders. Like a cab waiting for a drive.

1 0

Robert Cemper · Jul 24, 2020

just tried. the link leads you to :
https://openexchange.intersystems.com/package/Simple-remote-server-control
there is the link to GitHub

1 0

score 0 · Answer 1 · 2020-07-24T04:23:25-04:00

That does indeed sound promising, but the link to the example code is broken - do you have any other sources for that, please?

score 0 · Answer 2 · 2020-07-24T02:17:21-04:00

Looks like you solving the issue wrong way.

If you have multiple servers that can listen for connections, and allowed to do so, and you just need one external address that would use any of them for the clients. I would recommend using HAProxy, it's a load balancer tool, which may work for HTTP, and for plain TCP as well. In this case, clients will use HAProxy's address and port, and it will establish a connection to one of the backends. It may check if the backend is available, use backup backends if all primary backends died, and many other features. I'm using this in one of the projects for years, for HTTP with thousands of concurrent users, and 10 backends.