Nick Ager wrote:
> Hi,
>
> While working on the background service task code, I was frequently
> modifying the class - adding and removing instance and class variables.
> Initially I confused myself not understanding why I was seeing
> exceptions on code that should be fine and then finding the code I'd
> changed wasn't being executed. I've seen this come up a few times on the
> list before so I started digging around with classHistory. I found that
> even though I thought I'd removed all references to previous versions of
> classes, modified classes would still have a classHistory size > 1. I
> then discovered the "remove class history" option in the browser. When I
> use this option is there a danger that if I'm missed some references to
> the original class that I'm damaging the integrity of my image? I'm
> still a little unsure about which strategies to adopt when migrating
> classes in a live site. Any thoughts or references to
> documentation gratefully received.
>
> Thanks
>
> Nick
Nick,
You shouldn't remove any class histories until you are sure that all of
the instances have been migrated to the latest version (otherwise, it's
a bit more difficult to do the migration when it comes time). It doesn't
look like the remove class history menu item does this check...
In general, when auto migration is enabled, all of the instances in the
repository are kept up-to-date, and the class history can be removed
with impunity...
While doing development on the service task vm, I noticed some "odd"
things and it's likely that you are seeing some similar effects (rather
than unmigrated instances):
1. There is no abort at the start of service task execution
(intentional), so you could very easily be dealing with an instance
of a class that had been migrated, but the migrated instance wasn't
yet visible, because no abort had been performed.
2. You're working with a compiled block. If you make changes to the
code in the block itself, the code won't be executed until you've
installed the new task in the list and the service vm does an
abort. The service vm executes every 200ms, so the service task
could easily have fired running the old block, sending the old
messages before your new changes have a chance to be seen by the
service vm.
If you do have unmigrated instances of classes, then I would be
interested in tracking that down, because automigration is supposed to
work:)
Dale
Locked
