Gemstone and Magritte caching and classHistory
Locked
 
|
Hi,
I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. I've a model component which define's it's own class side descriptionContainer:
MyModel class descriptionContainer ^ super descriptionContainer componentClass: IZUIProjectEditor;
yourself. However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems:
IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" The solution I found was to flush the Magritte description cache:
MADescriptionBuilder default flush Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? From the Gemstone side should I worry that:
IZUIProjectEditor classHistory size = 6 How do I go about chasing down other references to old classes within Gemstone? Nick |
Re: Gemstone and Magritte caching and classHistory
|
Hi,
On 28.09.2010, at 19:43, Nick Ager wrote: > Hi, > > I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. > > I've a model component which define's it's own class side descriptionContainer: > > MyModel class descriptionContainer > ^ super descriptionContainer > componentClass: IZUIProjectEditor; > yourself. > > However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: > > IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" > > The solution I found was to flush the Magritte description cache: > > MADescriptionBuilder default flush > > > Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? > > From the Gemstone side should I worry that: > IZUIProjectEditor classHistory size = 6 > > How do I go about chasing down other references to old classes within Gemstone? > I don't know yet but I'll investigate this. Norbert |
|
|
Hi,
We do the following on every release. Still running 2.8 though. MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition cachedDefinitions keys). MCMethodDefinition shutDown. MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. System commitTransaction. HTH On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <[hidden email]> wrote: > Hi, > > On 28.09.2010, at 19:43, Nick Ager wrote: > >> Hi, >> >> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >> >> I've a model component which define's it's own class side descriptionContainer: >> >> MyModel class descriptionContainer >> ^ super descriptionContainer >> componentClass: IZUIProjectEditor; >> yourself. >> >> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >> >> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >> >> The solution I found was to flush the Magritte description cache: >> >> MADescriptionBuilder default flush >> >> >> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >> > This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. > >> From the Gemstone side should I worry that: >> IZUIProjectEditor classHistory size = 6 >> >> How do I go about chasing down other references to old classes within Gemstone? >> > I don't know yet but I'll investigate this. > > Norbert > > > |
|
|
Thanks Otto that's really helpful info
On 29 September 2010 09:54, Otto Behrens <[hidden email]> wrote:
|
Re: Gemstone and Magritte caching and classHistory
|
|
In reply to this post by otto
Hi Otto,
can you explain what particular problem you are solving with this? Norbert On 29.09.2010, at 10:54, Otto Behrens wrote: > Hi, > > We do the following on every release. Still running 2.8 though. > > MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition > cachedDefinitions keys). > MCMethodDefinition shutDown. > MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. > System commitTransaction. > > HTH > > On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <[hidden email]> wrote: >> Hi, >> >> On 28.09.2010, at 19:43, Nick Ager wrote: >> >>> Hi, >>> >>> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >>> >>> I've a model component which define's it's own class side descriptionContainer: >>> >>> MyModel class descriptionContainer >>> ^ super descriptionContainer >>> componentClass: IZUIProjectEditor; >>> yourself. >>> >>> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >>> >>> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >>> >>> The solution I found was to flush the Magritte description cache: >>> >>> MADescriptionBuilder default flush >>> >>> >>> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >>> >> This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. >> >>> From the Gemstone side should I worry that: >>> IZUIProjectEditor classHistory size = 6 >>> >>> How do I go about chasing down other references to old classes within Gemstone? >>> >> I don't know yet but I'll investigate this. >> >> Norbert >> >> >> |
|
|
> can you explain what particular problem you are solving with this?
This was some time ago, as I remember we found MCMethodDefinitions around that did not migrate when upgrading to another version. So, actually this could be obsolete, sorry. In principle, we like to avoid caches like these. Actually, we've been more aggressive when upgrading MC / Seaside by looking for class variables / class instance variables and nuking them. Got very odd behavior with old / new versions hanging around at the same time. When we deploy, we switch auto commit & auto migrate off. Then load all the in. Flush caches that cause pain. Garbage collect. And then do something like this for all classes that have more than one version: newVersion previousVersions do: [ :oldVersion | self migrateOldVersion: oldVersion to: newVersion] If you're interested in more code, let me know. |
Re: Gemstone and Magritte caching and classHistory
|
|
Hi,
On 29.09.2010, at 12:39, Otto Behrens wrote: >> can you explain what particular problem you are solving with this? > > This was some time ago, as I remember we found MCMethodDefinitions > around that did not migrate when upgrading to another version. So, > actually this could be obsolete, sorry. In principle, we like to avoid > caches like these. Actually, we've been more aggressive when upgrading > MC / Seaside by looking for class variables / class instance variables > and nuking them. Got very odd behavior with old / new versions hanging > around at the same time. > > When we deploy, we switch auto commit & auto migrate off. Then load > all the in. Flush caches that cause pain. Garbage collect. And then do > something like this for all classes that have more than one version: > > newVersion previousVersions do: [ :oldVersion | > self > migrateOldVersion: oldVersion > to: newVersion] > > If you're interested in more code, let me know. I'm very interested in this. How do you solve the problem if a class is referenced from somewhere? That is to me the hardest part. Ok, now I try to avoid using class references at all. Norbert |
Re: Gemstone and Magritte caching and classHistory
|
|
We hit lots of problems where we stored a reference to a class for things to be displayed... then changed the class and had it referring to the wrong version. Storing a symbol for the class and getting it at runtime is a much less painful option overall.
On Wed, Sep 29, 2010 at 8:53 AM, Norbert Hartl <[hidden email]> wrote: Hi, |
|
|
In reply to this post by NorbertHartl
> I'm very interested in this. How do you solve the problem if a class is referenced from somewhere? That is to me the hardest part. Ok, now I try to avoid using class references at all.
Although not having unnecessary static references to classes is perhaps a good thing, referencing a class should not be much trouble anymore (from the perspective of compiling a new version). Someone did good work to automatically carry class variable and class instance variable values from the old version to the new one (if there is a mapping). Referring to a class in a method will reference the new class version if one is compiled because the static reference is actually stored in the CompiledMethod as an Association (in the SymbolDictionary where the class was resolved when the method compiled; when the class moves to another symbol dictionary, this may become troublesome; but we compile it all into UserGlobals anyway). On another project, we basically remove all methods and recompile the lot after updating the class definitions. I still feel more comfortable with this somehow. I think it is faster this way too. HTH |
|
|
In reply to this post by NorbertHartl
> I'm very interested in this. How do you solve the problem if a class is referenced from somewhere? That is to me the hardest part. Ok, now I try to avoid using class references at all.
If you are talking about objects referenced from class / class inst vars, I agree. There was a post a while back on managing all "Root sets" through a "Root Set" object explicitly (was it Sean Allen?). I think this is a good idea, although we've opted to crawl the hierarchy and clean out class / class inst vars. We used SystemRepository findReferencePathToObject: quite a bit to trace where objects are referenced. |
Re: Gemstone and Magritte caching and classHistory
|
|
On 29.09.2010, at 16:00, Otto Behrens wrote: >> I'm very interested in this. How do you solve the problem if a class is referenced from somewhere? That is to me the hardest part. Ok, now I try to avoid using class references at all. > > If you are talking about objects referenced from class / class inst > vars, I agree. There was a post a while back on managing all "Root > sets" through a "Root Set" object explicitly (was it Sean Allen?). I > think this is a good idea, although we've opted to crawl the hierarchy > and clean out class / class inst vars. > I think James brought this up. After that I changed my instances handling through such a root object. I did it because sometimes I need to serialize my stuff with Sixx. Now I just need to serialize the root object and the pulls my complete model graph. > We used SystemRepository findReferencePathToObject: quite a bit to > trace where objects are referenced. Oh nice, didn't know that. Sometimes you need this. I remember in a project back then using squeak I couldn't survive without PointerFinder. thanks, Norbert |
Re: Gemstone and Magritte caching and classHistory
|
|
In reply to this post by otto
Otto Behrens wrote:
> Hi, > > We do the following on every release. Still running 2.8 though. > > MCMethodDefinition cachedDefinitions removeKeys: (MCMethodDefinition > cachedDefinitions keys). > MCMethodDefinition shutDown. > MCFileBasedRepository fastAllSubInstancesDo: [:ea | ea flushCache]. > System commitTransaction. > > HTH I have been thinking about making these caches into session-based caches rather persistent caches ... weak collections are used in Pharo (which we don't have in GemStone) so persistent caches _are_ overkill.. Dale > > On Tue, Sep 28, 2010 at 8:59 PM, Norbert Hartl <[hidden email]> wrote: >> Hi, >> >> On 28.09.2010, at 19:43, Nick Ager wrote: >> >>> Hi, >>> >>> I hit a confusing bug caused by an interaction between Magritte cached descriptions and Gemstone's classHistory. >>> >>> I've a model component which define's it's own class side descriptionContainer: >>> >>> MyModel class descriptionContainer >>> ^ super descriptionContainer >>> componentClass: IZUIProjectEditor; >>> yourself. >>> >>> However although I'd been changing code in IZUIProjectEditor, Magritte was holding onto an old version of my class causing unexpected problems: >>> >>> IZUIProjectEditor classHistory last asOop = IZProject description componentClass asOop "false" >>> >>> The solution I found was to flush the Magritte description cache: >>> >>> MADescriptionBuilder default flush >>> >>> >>> Has anyone else had problems with updating code in Gemstone and Magritte cached descriptions? >>> >> This is a two-fold problem. One is that Magritte caches descriptions. So you might have to reset the magritte cache if you change a description. If you update code than you run into a gemstone specific issues. If you use a class name inside of code than you are pinpointing that piece of code to a certain class object. Updating code creates another class object that is now lookupable from the environment (Smalltalk). The compiled methods stay the same and pointing to the old class object. >> >>> From the Gemstone side should I worry that: >>> IZUIProjectEditor classHistory size = 6 >>> >>> How do I go about chasing down other references to old classes within Gemstone? >>> >> I don't know yet but I'll investigate this. >> >> Norbert >> >> >> |
Re: Gemstone and Magritte caching and classHistory
|
|
In reply to this post by otto
Otto Behrens wrote:
>> I'm very interested in this. How do you solve the problem if a class is referenced from somewhere? That is to me the hardest part. Ok, now I try to avoid using class references at all. > > Although not having unnecessary static references to classes is > perhaps a good thing, referencing a class should not be much trouble > anymore (from the perspective of compiling a new version). Someone did > good work to automatically carry class variable and class instance > variable values from the old version to the new one (if there is a > mapping). > > Referring to a class in a method will reference the new class version > if one is compiled because the static reference is actually stored in > the CompiledMethod as an Association (in the SymbolDictionary where > the class was resolved when the method compiled; when the class moves > to another symbol dictionary, this may become troublesome; but we > compile it all into UserGlobals anyway). > > On another project, we basically remove all methods and recompile the > lot after updating the class definitions. I still feel more > comfortable with this somehow. I think it is faster this way too. > > HTH The problem that I think Sean is referring to is when a class reference is stored in a class variable ... those references aren't migrated when a new class version is created ... so either storing the association (that holds the class) or using a symbol and doing a lookup (like Sean suggests) are better solutions ... Of course Seaside stores class references in variables for the component class and I have been threatening to address that problem, but haven't done that yet ... Dale |
Re: Gemstone and Magritte caching and classHistory
|
|
On Wed, Sep 29, 2010 at 12:58 PM, Dale Henrichs <[hidden email]> wrote:
Yeah that is basically what I was addressing... we had areas of the application that were Seaside components that were mostly all static html with a touch of dynamic. Each of these pages was stored as a class which was referenced as part of the entire site. Problem... if we updated the content and the shape of the class changed, the code that moved you from page to page was holding a reference to the old class. It was a dur moment for us where we realized we really should have been using symbols ( which I now do when presented with similar issues ).
|
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |