[OpenAFS-devel] Re: idle dead timeout processing in clients

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBB3E0B974D8A64166D963FC2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/30/2011 4:13 PM, Simon Wilkinson wrote:
> 1) If you have an RPC with a small number of arguments (say CreateFile)=
 the client will end up in READER_WAIT as soon as it has transmitted the =
first packet. If that CreateFile requires a callback break which takes lo=
nger than
> the idle dead timeout, then the client will timeout the call with CALL_=
TIMEOUT. In the meantime, the server will complete the callback break, an=
d create the file. afs_Analyze will receive CALL_TIMEOUT and retry the op=
eration, the server will see that the file already exists, and return EEX=
IST. So, we have an operation that has actually succeeded returning an er=
ror.

The cache manager will not only return an error but be left with out of
date status information and the belief that it has a valid callback.  In
fact, it does have a valid callback but for DV+1 not DV because the file
server registered a new callback for DV+1 when the first CreateFile
succeeded.  Its this second bit that bothers me even more than the
extraneous error in this case.

Cheers

Jeffrey Altman


--------------enigBB3E0B974D8A64166D963FC2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJO1qL3AAoJENxm1CNJffh4ISgH/iVUn4NKh9BDFqZz8lItRa1b
QYlcV++fwvDZ78Lu+qodB0GtJMnWjbAGkxkZCu0aRNO3oPr80sV90NwEhwnZegew
MZxivTbQ7nB/WX2m5xcCJHOsYiZYfmn0GojDt6eg4v2N4g/EE0L2+vLUQi5+NxYW
J3k+tt0HycmoXlHDglLZiq5254Es6x1jBrjarPclywmtQjAaK4D0V9xqqA6c5kR3
dEBsx/ZzqqwkYieCD2p/VBtu76uWG1PBtdDLh1ZwS6KYNoMuJtCQ9n3/ng3wIACu
wXto0Cyh0KqghDclIsxB5XrHymu+YMJwQ4F+PUBgbJR715bXvW4jmZ0aL+R0OMQ=
=q1ZN
-----END PGP SIGNATURE-----

--------------enigBB3E0B974D8A64166D963FC2--