Since the client is 1.6.5, a newer client will alter the error message but not the behavior. If the file server concludes that the connection has stalled (been idle) for too long, it will terminate it with a VNOSERVICE abort code.
If the VNOSERVICE is reproducible when performing an "unlink" operation on a lock file, that might indicate some other problem. * Is the lock file one that would be in use by other cache managers? * How contended would the directory containing the lock file be? VNOSERVICE errors should not be result of a failure of the file server to send callback messages to cache managers other than the one requesting the change. I'm suspicious of a VNOSERVICE reliably being returned on an unlink operation because the RPC issues the request in a single packet and sends the result in a single packet. The idle detection code is supposed to be engaged if a call is started and all of the data required to perform the call fails to arrive. If this behavior can be reliably reproduced it would be useful to examine a tcpdump of the rx traffic on the file server that is issuing the VNOSERVICE abort. Jeffrey Altman On 7/12/2014 12:57 PM, Renata Maria Dart wrote: > Hi Jeff, the client is 1.6.5. > > Renata > > On Fri, 11 Jul 2014, Jeffrey Altman wrote: > >> Since 1.6.5 a change was made to the client to translate the VNOSERVICE >> error to ETIMEDOUT. That doesn't change any behavior but it results in >> a more reasonable error message being reported. (VNOSERVICE has the >> same numeric value as ENOBUFS.) >> >> In 1.6.2 a change was made to the client to treat a VNOSERVICE error as >> a condition which permits a retry of the operation. However as the >> e-mail thread you quoted from indicates, doing so is not always safe. >> >> What version is the client? >> >> Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
