On Nov 12, 2006, at 10:48 AM, Jeffrey Altman wrote:
Robert Banz wrote:
if ((acode == VICETOKENDEAD) || (acode == RXKADEXPIRED))
Leads to the same message, I've added an extra bit to the
"...expired"
error message to tell me *which* of these is the case -- but I'm
pretty
sure that from the client's perspective it's tokens shouldn't be
expiring for quite awhile.
VICETOKENDEAD does not mean that the client's tokens are expired.
It means that the token's associated with the RX connection are
expired.
The file server sends this error when the last call received by the
file server was so long ago that the tokens associated with the
connection are no longer good. Its meant to trigger the use of a new
RX connection. It should not trigger the destruction of the tokens
held by the client.
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?
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
