From: Andreas H. <haf...@in...> - 2010-09-30 13:40:08
|
----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://saros-build.imp.fu-berlin.de/reviews/r/98/#review220 ----------------------------------------------------------- I don't understand how that would change anything, isn't the goal to prevent the UI from blocking if there's a cache miss? ./src/de/fu_berlin/inf/dpp/ui/RosterView.java <http://saros-build.imp.fu-berlin.de/reviews/r/98/#comment236> I think the best way is to simply do nothing if there's a CacheMissException (default false is good). The RosterView is just a view, it's not supposed to actively poll data from the server, it should just display the info we have cached. If the cache is empty, then the RosterView simply has to wait until it isn't. It might be necessary to register some sort of listener so that we can update when new info arrives, I don't know how the invitee selection dialog does that. - Andreas On 2010-09-30 15:29:52.417942, Karl Beecher wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://saros-build.imp.fu-berlin.de/reviews/r/98/ > ----------------------------------------------------------- > > (Updated 2010-09-30 15:29:52.417942) > > > Review request for All Saros. > > > Summary > ------- > > It is possible that the RosterView blocks while it awaits the discovery manager for Saros support info. > > This patch checks the saros support cache, and only uses the blocking method if the info is not in the cache. > > It doesn't solve the problem 100%. A full solution would either be to remove Saros support from the Roster, or somehow go to the discovery manager without blocking the SWT-thread. > > > Diffs > ----- > > ./src/de/fu_berlin/inf/dpp/ui/RosterView.java 2548 > > Diff: http://saros-build.imp.fu-berlin.de/reviews/r/98/diff > > > Testing > ------- > > > Thanks, > > Karl > > |