Excessive logs for handleSearchResponse

[jacomago]

Reduce level for logs

org.epics.pva.client.PVAClient.handleSearchResponse More than one channel with name 'DTL-030:PBI-BPM-002:SM-ConvStatus' detected,

As this is quite common in the archiver making a log for every PV connection.

[kasemir]

Do you understand why you get these messages?

With Channel Access, the corresponding messages might be benign because a client can get multiple responses from the same server. For example, a server on the same host can reply via both 127.0.0.1 and the actual IP address of the host.

With PVA, we check the GUID of the server:

phoebus/core/pva/src/main/java/org/epics/pva/client/PVAClient.java

Lines 255 to 265 in 770f350

	// Check GUID for unexpected reply from another(!) server.
	final PVAChannel check = channels_by_id.get(channel_id);
	if (check == null)
	logger.log(Level.WARNING, "Received search reply for unknown channel ID " + channel_id + " from " + server + " " + guid);
	else
	{
	final ClientTCPHandler tcp = check.tcp.get();
	// Warn about duplicate PVs on network
	if (tcp != null && !tcp.getGuid().equals(guid))
	logger.log(Level.WARNING, "More than one channel with name '" + check.getName() + "' detected, connected to " + tcp.getRemoteAddress() + " " + tcp.getGuid() + ", ignored " + server + " " + guid);
	}

The message should thus indicate that you indeed have the same PV served more than once, by servers with different GUIs. That could be a pretty big problem. Are you using PVA gateways? Maybe you have accidentally created loops, exposing the same PV via more than one gateway?

[jacomago]

We have some IOCs (a hundred maybe) running both QSRV 1 and QSRV 2. So we get duplicate responses because of that. Every time they restart (due to an upgrade or anything) it floods the logs with these messages.

[kasemir]

running both QSRV 1 and QSRV 2

.. and those serve the same PVs?! Based on pure luck, a client gets connected to one or the other QSRV. How does that work with put-callbacks aka put-with-completion?
You might want to fix that.
Run with only one QSRV.
Or find a way to have each QSRV serve its own set of PVs.
Figure out why you are in this situation in the first place.
Maybe QSRV2 is what you need for the most part, but some older code needs to serve PVs via the older API, and it can do that just fine without starting the older SQRV1. So QSRV2 servers all the records, QSRV1 serves some non-record PVs.

[jacomago]

Sure, that is definitely something we intend to fix (probably in the next six months). But regardless I think core-pva is a very low level library and should have generally have very quiet logs by default.

I can of course exclude logs by package, but that seems overkill when I think this particular warning can be an info. We aren't 'not connecting' or losing data transfer, so I think the log level can be lower.

[kasemir]

Having duplicate PVs on the network is a severe problem. It can lead to frantic phone calls at midnight and machine downtime. Since the beginning of EPICS, the CA clients issue messages for that, often erroneously because it's really the same server via different IPs (localhost, actual host, ...), but that's been considered minor compared to the alternative of missing duplicated channels. With PVA we're one step ahead because we check the server GUID, which eliminated the nuisance messages and we only see PVs that are truly provided by multiple servers.
You're shooting the messenger here when it's really your IOC setup that needs to be fixed.