"gateServer::pvAttach() bad PV" when using Name Server

[anjohnson]

We've been chasing an issue with PVs not connecting through a gateway from a client (which actually happens to be another gateway but I now don't think that really matters) when the client uses a CA name-server to find the server.

We're still developing a working example, but what's happening is that the gateway is returning CA_PROTO_CREATE_CH_FAIL (26) through TCP for a channel names that end in .VAL but is succeeding for the same name without the .VAL. One important thing to note from our packet captures is that there are no UDP searches for these channel names being sent to the gateway, the name server already knows where the .VAL PV can be found from the other channel name.

Turning on debug in the gateway we see the "bad PV" error messages in the log for the .VAL connection attempts. However as soon as we try connecting to the .VAL channel from a client that is not behind the name-server, the gateway finds the channel, and now the name-server client can connect to it as well.

Here's the "bad PV" error, from gateServer.cc's gateServer::pvAttach() method:

	// See if we have a gateVcData
	if(vcFind(real_name,rc) < 0)
	{
		// We don't have it, create a new one
		rc=new gateVcData(this,real_name);

		if(rc->getStatus())
		{
			gateDebug1(5,"gateServer::pvAttach() bad PV %s\n",real_name);

The error implies that the gateVcData constructor is returning an object with a non-zero status, implying construction failed. Looking in gateVc.cc at that constructor I see this comment:

	// Important Note: The exist test should have been performed for this
	// PV already, which means that the gatePvData exists and is connected
	// at this point, so it should be present on the pv list

I believe our use of the name server invalidates the assumption described in the above note. It is causing clients to connect to the gateway over TCP that have not previously sent a UDP search request, which I guess that means the gateServer::pvExistTest() method has not been called for the name. It may have been called for the name without the .VAL but the name-server knows that both must be on the same CA server.

The notes for the caServer::pvAttach() method in casdef.h do say "The request is allowed to complete asynchronously" so it should be possible to support our use-case, but it looks like the current code isn't prepared to do so.

BTW I am currently reorganizing the new ca-nameserver git module which I only recently converted from CVS, to build stand-alone. I am also not finished with the investigation, although ideas and comments welcome...

[ralphlange]

Wow - your mention of the word 'fix' combined with the number of this issue closed it when I merged the PR.
Good to know...