Resource leak in Beacon tracking

[mdavidsaver]

The m_beaconHandlers map can grow without bound as new PVA servers come online.

pvAccessCPP/src/remoteClient/clientContextImpl.cpp

Lines 4525 to 4530 in b2f0aec

	/**
	* Beacon handler map.
	*/
	// TODO consider std::unordered_map
	typedef std::map<osiSockAddr, BeaconHandler::shared_pointer, comp_osiSock_lt> AddressBeaconHandlerMap;
	AddressBeaconHandlerMap m_beaconHandlers;

This map needs to be bounded in size and/or time. (like PVXS does...)

[mdavidsaver]

This may have manifest first with RTEMS because BeaconHandler::_mutex is a far more finite resource on that target.

https://epics.anl.gov/tech-talk/2022/msg00597.php

[mdavidsaver]

I remember noticing this before, and also remember fixing it. But apparently I'm getting confused with a similar leak in code tracking TCP connections. cf. f1defe4 fixed in 6.1.0

[kasemir]

What if the client simply ignores beacons? For existing but idle connections, there's already the periodic 'echo' mechanism. For disconnected channels, the search settles to once every ~30 seconds. Detecting beacons from new servers could reduce time to re-connect from those 30 seconds, but after a long disconnect another 30 seconds aren't too bad. So the beacons aren't absolutely necessary, and can in fact cause downtime, as we experienced with CA when clients woke up because of ill-timed beacons, resulting in a lot of search traffic, epics-base/jca#53 .

[mdavidsaver]

What if the client simply ignores beacons?

As I understand things, the only ill effect should be slower reconnects. I usually describe Beacons as an optimization.