Files

Joseph Doherty a326a8cbde fix(lmxproxy): make MxAccess client name unique per instance

Multiple instances registering with the same name may cause MxAccess to
conflict on callback routing. ClientName is now configurable via
appsettings.json, defaulting to a GUID-suffixed name if not set.
Instances A and B use "LmxProxy-A" and "LmxProxy-B" respectively.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-03-22 23:18:09 -04:00

3.0 KiB

Raw Blame History

LmxProxy v2 — Instance Configuration

Two instances of the LmxProxy v2 Host service are deployed on windev (10.100.0.48), both connecting to the same AVEVA System Platform via MxAccess COM.

Instances

	Instance A	Instance B
Service Name	`ZB.MOM.WW.LmxProxy.Host.V2`	`ZB.MOM.WW.LmxProxy.Host.V2B`
Display Name	SCADA Bridge LMX Proxy V2	SCADA Bridge LMX Proxy V2B
MxAccess Client Name	`LmxProxy-A`	`LmxProxy-B`
Publish Directory	`C:\publish-v2\`	`C:\publish-v2b\`
gRPC Port	50100	50101
HTTP Status Port	8081	8082
Log File Prefix	`lmxproxy-v2-`	`lmxproxy-v2b-`
Log Directory	`C:\publish-v2\logs\`	`C:\publish-v2b\logs\`
Health Probe Tag	`DevPlatform.Scheduler.ScanTime`	`DevPlatform.Scheduler.ScanTime`
API Keys File	`C:\publish-v2\apikeys.json`	`C:\publish-v2b\apikeys.json`
Auto-Start	Yes	Yes

Shared API Keys

Both instances use the same API keys (copied from instance A during setup).

Role	Key
ReadWrite	`c4559c7c6acc60a997135c1381162e3c30f4572ece78dd933c1a626e6fd933b4`
ReadOnly	`a77d090d4adcfeaac1a50379ec5f971ff282c998599fd8ccf410090c9f290150`

Service Management

# Instance A
sc start ZB.MOM.WW.LmxProxy.Host.V2
sc stop ZB.MOM.WW.LmxProxy.Host.V2
sc query ZB.MOM.WW.LmxProxy.Host.V2

# Instance B
sc start ZB.MOM.WW.LmxProxy.Host.V2B
sc stop ZB.MOM.WW.LmxProxy.Host.V2B
sc query ZB.MOM.WW.LmxProxy.Host.V2B

Health Endpoints

# Instance A
curl http://10.100.0.48:8081/api/health
curl http://10.100.0.48:8081/api/status

# Instance B
curl http://10.100.0.48:8082/api/health
curl http://10.100.0.48:8082/api/status

Client Connection

// Instance A
var clientA = new LmxProxyClientBuilder()
    .WithHost("10.100.0.48")
    .WithPort(50100)
    .WithApiKey("c4559c7c6acc60a997135c1381162e3c30f4572ece78dd933c1a626e6fd933b4")
    .Build();

// Instance B
var clientB = new LmxProxyClientBuilder()
    .WithHost("10.100.0.48")
    .WithPort(50101)
    .WithApiKey("c4559c7c6acc60a997135c1381162e3c30f4572ece78dd933c1a626e6fd933b4")
    .Build();

Updating Instances

After code changes, both instances need to be republished separately:

# Stop both
sc stop ZB.MOM.WW.LmxProxy.Host.V2
sc stop ZB.MOM.WW.LmxProxy.Host.V2B

# Publish
dotnet publish src/ZB.MOM.WW.LmxProxy.Host -c Release -r win-x86 --self-contained false -o C:\publish-v2
dotnet publish src/ZB.MOM.WW.LmxProxy.Host -c Release -r win-x86 --self-contained false -o C:\publish-v2b

# Restore instance-specific config (publish overwrites appsettings.json)
# Instance B needs port 50101/8082 and log prefix lmxproxy-v2b-

# Start both
sc start ZB.MOM.WW.LmxProxy.Host.V2
sc start ZB.MOM.WW.LmxProxy.Host.V2B

Note: dotnet publish overwrites appsettings.json in the output directory with the source copy (which has default ports 50051/8080). After publishing, verify the instance-specific config is correct before starting the service.

3.0 KiB Raw Blame History