In our 7.4 and 7.4.1 images we see thousands of instances (I've seen
~1500-7000 in our automatically built images) of Store.MiniRepositoryManager, they are held on to by a valueholder's dependents: Store.DbRegistry connectedProfileHolder dependents I'm not sure what induces this, it could even be that our build code does something wrong... Do other people here see more than one dependent? TIA, Reinout ------- |
Nope, I've just got one (7.4.1, built with an automatic process). It
looks like the only place that adds the MiniRepositoryHolder to the dependents is when one gets created, and the only place that creates one is this: VisualLauncherToolDock>>miniRepositoryManager <component: 20 class: #{Store.MiniRepositoryManager} spec: #windowSpec> ^self newTool: Store.MiniRepositoryManager Since that method is rather badly named, sounding like an accessor when really it is a creator, you wouldn't by any chance be sending that lots in your build code ("aToolDock miniRepositoryManager")? Steve > -----Original Message----- > From: Reinout Heeck [mailto:[hidden email]] > Sent: 04 August 2006 15:56 > To: 'VWNC' > Subject: [Bug?] MiniRepositoryManager has thousands of instances > > In our 7.4 and 7.4.1 images we see thousands of instances (I've seen > ~1500-7000 in our automatically built images) of > Store.MiniRepositoryManager, they are held on to by a valueholder's > dependents: > > Store.DbRegistry connectedProfileHolder dependents > > > I'm not sure what induces this, it could even be that our build code > does something wrong... > > > Do other people here see more than one dependent? > > TIA, > > Reinout > ------- |
Thanks Steven,
it turns out it was not #miniRepositoryManager (no senders in our image) but the only other reference to MiniRepositoryManager (VisualLauncher>>storeProfilesMenu) which instantiates a MiniRepositorymanager 3-7 times when the 'Store' menu is opened in the launcher. MiniRepositoryManager>>initialize super initialize. "Hack to enable loading." DbRegistry ifNil: [^self]. DbRegistry connectedProfileHolder onChangeSend: #connectedProfileChanged to: self. self connectedProfileChanged Moving the 'Hack' from #initialize to #preBuildWith: seems to solve the problem: -just instantiating the MiniRepositoryManager to obtain its menu of profiles will no longer add the dependency -opening an interface implies that #release will be called on the MiniRepositoryManager later. So simply hovering over the 'Store' menu should bump your number of dependents (it seems by 3 when opening and closing the menu or 7 when hovering over it): Store.DbRegistry connectedProfileHolder dependents Cheers, Reinout ------- Steven Kelly wrote: > Nope, I've just got one (7.4.1, built with an automatic process). It > looks like the only place that adds the MiniRepositoryHolder to the > dependents is when one gets created, and the only place that creates one > is this: > > VisualLauncherToolDock>>miniRepositoryManager > > <component: 20 class: #{Store.MiniRepositoryManager} spec: > #windowSpec> > ^self newTool: Store.MiniRepositoryManager > > Since that method is rather badly named, sounding like an accessor when > really it is a creator, you wouldn't by any chance be sending that lots > in your build code ("aToolDock miniRepositoryManager")? > > Steve > >> -----Original Message----- >> From: Reinout Heeck [mailto:[hidden email]] >> Sent: 04 August 2006 15:56 >> To: 'VWNC' >> Subject: [Bug?] MiniRepositoryManager has thousands of instances >> >> In our 7.4 and 7.4.1 images we see thousands of instances (I've seen >> ~1500-7000 in our automatically built images) of >> Store.MiniRepositoryManager, they are held on to by a valueholder's >> dependents: >> >> Store.DbRegistry connectedProfileHolder dependents >> >> >> I'm not sure what induces this, it could even be that our build code >> does something wrong... >> >> >> Do other people here see more than one dependent? >> >> TIA, >> >> Reinout >> ------- >> > > > |
Free forum by Nabble | Edit this page |