[OpenAFS-devel] Discarding tokens -- is this good?

[Jeffrey Altman]

Robert Banz wrote:
>> Only an RXKADEXPIRED or RXKADBADTICKET should do that.
> 
> Thanks for the better explanation of the error codes.
> 
> According to the code in the client, all three of these states lead to
> the same result -- getting UTokensBad set in user->states, with the only
> difference in handling being that VICETOKENDEAD & RXKADEXPIRED printing
> the "...expired" error message, and  any other RXK error gets it's error
> code printed.  Check out afs/afs_analyze.c...
> 
> The intended behavior that you describe above makes sense, however, the
> current way the error handling is coded doesn't follow.  My only "fear"
> in fixing this a lack of understanding of some of the ramifications. 
> While it looks relatively simple to ask for a retry of the call, and
> initiate a new RX connection, there doesn't seem to currently be a way
> to put a limit on how many times something would be retried.  I think
> that would require adding a counter to vrequest to track how many times
> this request may have been retried as I don't think it should be
> unbounded -- at some point it should end up throwing an IO error back up
> the stack...  Or are there already limits in-place for this?
> 
> Thoughts?

The retry limit would be determined by the HARDDEADTIMEOUT.

If you force the use of a new rx connection then the next error cannot
be VICETOKENDEAD.  If the token is expired, then the next error would
be RXKADEXPIRED and the token should in fact be destroyed.

Send a bug report to openafs-bugs@openafs.org.

Jeffrey Altman