Hi, This email is resolution for this thread, on the off-chance someone sees it, and ever wonders what happened, while investigating their own issues.
The below scenario was not as it seemed, I made mistake while pulling the milliseconds from the timestamps, the INSERT of the service ticker DID happen between the login-test-1, creating the ticket, and login-test-2 trying to validate the ticket. A separate email is coming to cover our specific, real, fault. On 07/10/2011, at 10:15 AM, David Clarke wrote: > > On 07/10/2011, at 1:42 AM, Marvin Addison wrote: > >>> 11:42:18.547 - login-test-1 records service ticket creation >>> 11:42:18.642 - login-test-2 records an attempt to use the service ticket >>> 11:42:18.738 - mysql binary shows an INSERT for the ticket creation >> >> *head explodes* >> >> Service ticket creation is transactional by nature, yet the sequence >> above seems to indicate that the ticket is returned and validated >> prior to the end of the transaction started in the first step. >> Assuming your timestamps across these three systems are close enough >> such that the sequence above is in fact the real sequence of events, >> it would indicate some inexplicable transaction handling behavior by >> your database. I'm not a MySQL expert, but I'd expect transaction >> handling to behave as expected here, so that explanation is a long >> shot. I'd question clock synchronization long before I'd question >> your database doing something boneheaded. I can say the most common >> cause of the error you cited is that the client fails to validate the >> ticket before its expiration period, which is 10s by default (3.4.10 >> and recent versions anyway). > > > I guess I didn't make it explicit enough, but the DB timestamp, as to when > the insert occurs, is based upon the CREATION_TIME field within the insert, > not upon the date/time of the mysql server. As far as I can see, the > CREATION_TIME field is populated by login-test-1 itself. > > That means for timing comparisons, I'm only comparing login-test-1, to > login-test-2 (The mysql servers own timing is not relevant), and looking at > ntpstat comparisons suggests they are very close to each other. How close is > hard to say. > > The worst case yesterday, at the time of the specific instance investigated, > was that login-test-1, and login-test-2, might have been out of sync from > each other by as much as 1/10 second, probably with 1/100 second. 10sec > difference is right out. > > In prior instances of this fault, a refresh of the page, on the webservice > using CAS, allowed the session to go on and work fine, so it shouldn't be > ticket timeout. Yesterday I don't know if the page refresh was done. > > The thing I think I might be questioning, is whether the process of > generating a ticket, and storing it in the DB, is asynchronous or not. ======================================= David Clarke Java Team Information Technology Infrastructure Division of Information Building 3K The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8390 www.anu.edu.au CRICOS Provider #00120C =======================================
smime.p7s
Description: S/MIME cryptographic signature
