1829 2008-09-14 18:08 New venue cache needs faster timeout 2010-03-30 17:35:32 1 1 1 Unclassified Virtual Venues Client Software Client UI 3.2 beta 1 PC All RESOLVED FIXED P2 normal 3.2 1 c.willing@uq.edu.au turam@mcs.anl.gov c.willing@uq.edu.au 2008-09-14 18:08:36 The ANL vv3 server is hardcoded as the server whose venues are cached when the VenueClient first starts up. If that server is down and there is no existing venue cache e.g. first time user, then there is an inordinate delay while the caching mechanism tries unsuccessfully to contact the venue server. This delay makes it appear that the VenueClient has frozen, although waiting ~5 minutes till the connection attempt times out restores normal usage. The venue caching mechanism needs some faster sort of timeout - just like that used for polling bridge servers. c.willing@uq.edu.au 2008-09-14 18:16:16 I just looked at the vene cache code some more and see that the ANL vv3 server is not actually hard coded in normal usage (looks like that is for a test case or something). However the ANL server is set as the default for a new user so the problem still stands - a faster timeout is needed. turam@mcs.anl.gov 2010-03-30 17:35:32 The venue cache will no longer be updated synchronously (i.e. on the main thread) at startup. It will be updated in the background instead. Background updates were happening before, but the change is that if the cache does not exist, the cache is now updated sooner than it would have been.