If vsmserver has been stopped for more than session_update_delay (10 minutes), vsmserver will try to verify all sessions _at once_ on startup. That's bad because it will consume a lot of server resources at once, instead of spreading the load evenly over a session_update_delay interval.
If we were to introduce a random delay from 0 to session_update_delay until vsmserver starts checking the session, we should spread out the session checks evenly in the 10 minute intervals (given enough sessions).
Fixed in r30086.
Tester should make sure vsmserver doesn't choke on loading a session database that contains more than 1024 sessions which hasn't been verified in 10 minutes.
(In reply to comment #3)
> Fixed in r30086.
> Tester should make sure vsmserver doesn't choke on loading a session database
> that contains more than 1024 sessions which hasn't been verified in 10 minutes.
See also: bug 5458.
Tested using the associated script. Sessions were verified and removed fairly evenly over a ten minute period.