Deployment problems and a couple of possible solutions

Andy,

For some reason, I suddenly found my self unable to deploy anything.  The
problem seemed to always strike in #stripDevelopmentResourcesNotifying:,
failing due to
         ResourceListPresenter does not understand #onResourceRemoved:

which (according to the stripping log) had been trapped many times before
the offending line.  The modified method below _appears_ to result in a
stable executable.  What do you think?

Beyond this, I get into trouble trying to remove the class builder; the
walkback there points to #onClassRemoved: - is this perhaps more of the
same?

Have a good one,

Bill



!ImageStripper methodsFor!

stripDevelopmentResourcesNotifying: notifier
 "Private - Remove development classes resources. We can't actually remove
the
 classes themselves yet since some are required by the remainder of the
 stripping process. By removing the resources we give the  class/method
strip
 that follows the best chance of isolating redundant items."

 | resman |
 resman := SessionManager current resourceManager.

 #wksDangerous.  "This kept blowing up when the same thing appears
 to be safely ignored earlier????
 developmentClasses do: [:each | resman onClassRemoved: each]."
 [
  developmentClasses do: [:each | resman onClassRemoved: each].

 ] on:Error do:[ :e | ].

 self developmentResources do: [:ri | resman remove: ri].

 self finishedWith: #developmentResources ! !
!ImageStripper categoriesFor:
#stripDevelopmentResourcesNotifying:!operations!private! !

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

You wrote in message news:9143qe$2sjhb$[hidden email]...
>
> For some reason, I suddenly found my self unable to deploy anything.  The
> problem seemed to always strike in #stripDevelopmentResourcesNotifying:,
> failing due to
>          ResourceListPresenter does not understand #onResourceRemoved:
>
> which (according to the stripping log) had been trapped many times before
> the offending line.  The modified method below _appears_ to result in a
> stable executable.  What do you think?

The error is indicating that an instance of RLP still exists in your image,
perhaps a zombie. The stripper takes care to close all development views and
relies on them being GC'd. If they are not, then you may experience such
errors, although I have never seen this particular problem. I don't think it
would be a good idea to suppress such errors, as then you'll loose important
evidence as to the source of unexpected content in the resulting executable.

If anything can be done here to make this more robust, it is probably to
have RLP trap onViewClosed and remove the events it has registered against
the resource manager, but although that might remove the DNUs, you may still
end up with RLP in the deployed executable or other associated problems.

>
> Beyond this, I get into trouble trying to remove the class builder; the
> walkback there points to #onClassRemoved: - is this perhaps more of the
> same?

Perhaps. I would suggest investigating to see if you have development views
hanging around in the image for some reason. There may be further
information in the stripping log, perhaps error reports about failure to
remove classes in the development packages.

Regards

Blair

Blair,

> The error is indicating that an instance of RLP still exists in your
image,
> perhaps a zombie. The stripper takes care to close all development views
and
> relies on them being GC'd. If they are not, then you may experience such
> errors, although I have never seen this particular problem.

Sounds like a panic is in my near future.  I was wondering how it was that
deployments worked just an hour or so before the meltdown - thanks fior
you've explaining it.  I _thought_ that I exited w/o saving the image after
encountering some problems with older image strippers (STB conversion
problems during Lagoon startup), but, perhaps I created and saved some
zombies.


> I don't think it
> would be a good idea to suppress such errors, as then you'll loose
important
> evidence as to the source of unexpected content in the resulting
executable.

If possible, I'd prefer to see something more along the lines of how Lagoon
reports other references to the development system: the app deploys but with
a warning that there's more to do.  Perhaps the log could have a notice at
the bottom indicating whether or not Lagoon is happy, or the warning message
box could move to the end of the strip?


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair McGlashan <[hidden email]> wrote in message
news:914spk$2t47i$[hidden email]...
> The error is indicating that an instance of RLP still exists in your
image,
> perhaps a zombie. The stripper takes care to close all development views
and
...

I have had trouble with zombie views in deployed applications.  Not the kind
of trouble Bill had, but rather simply seeing the size of my deployed
applications increase in strange ways.  I now habbitually do a panic before
I  deploy.  However that can be a little inconvienient since I loose all my
browsers and workspaces.  Would it make sense to do an "inteligent" panic
after the pre-strip image save that could check to see if there was really a
window open or not?  That way it could kill zombies while leaving any real
windows open.  Maybe I am over looking something, but it might be a handy
feature.  My experiance is in D3, but I assume it applies to D4 as well
unless there is already a pre-deployment zombie killer.

Chris

Christopher

You wrote in message news:916fqa$2to9p$[hidden email]...
>...
> I have had trouble with zombie views in deployed applications.  Not the
kind
> of trouble Bill had, but rather simply seeing the size of my deployed
> applications increase in strange ways.  I now habbitually do a panic
before
> I  deploy.  However that can be a little inconvienient since I loose all
my
> browsers and workspaces.  Would it make sense to do an "inteligent" panic
> after the pre-strip image save that could check to see if there was really
a
> window open or not?  That way it could kill zombies while leaving any real
> windows open.  Maybe I am over looking something, but it might be a handy
> feature.  My experiance is in D3, but I assume it applies to D4 as well
> unless there is already a pre-deployment zombie killer.

There is - D4's ImageStripper is significantly more robust in this respect.
I'd be surprised if doing a "panic" made any significant difference, since
more similar actions are already taken by the D4 stripper. When zombies
cause D4 deployment problems it is likely to be because of other sources of
references than invisible views that are still registered in the handle
table (which is really the only type killed off by a "panic"). Those
references will have to be tracked down - dead processes that are hanging
around for some reason are one possible cause, and these can be located
using the ProcessMonitor.

Regards

Blair

By the way, why is the image saved before deploying? I never save the image
and instead I keep all my work in packages that I install whenever I start
Dolphin. Therefore, it is slightly inconvenient that the image is saved
automatically. Not that it matters a lot, but if it is only a feature and
not an essential part of the deployment process, perhaps it could become an
option in some future version of Dolphin?

Thanks a lot for 4.0 which is a great product!

Mikael
[hidden email]

Blair,

> The error is indicating that an instance of RLP still exists in your
image,
> perhaps a zombie. The stripper takes care to close all development views
and
> relies on them being GC'd. If they are not, then you may experience such
> errors, although I have never seen this particular problem. I don't think
it
> would be a good idea to suppress such errors, as then you'll loose
important
> evidence as to the source of unexpected content in the resulting
executable.
>
> If anything can be done here to make this more robust, it is probably to
> have RLP trap onViewClosed and remove the events it has registered against
> the resource manager, but although that might remove the DNUs, you may
still
> end up with RLP in the deployed executable or other associated problems.

Your focus on the RLP was the key.  The problem turned out to be caused by a
(now obsolete) feature of SuiteBuilder.  I added a make shift redundant
package stripping system and closed development views prior to invoking it.
For 4.0, I removed the package stripping because Lagoon does a (much) nicer
job of it, but, didn't think to remove the view closing.  The result was
that the views were closed, but, not completely excised using Lagoon's more
complete approach to that problem.  With the view closing left to Lagoon,
all appears to be well so far - thanks!

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair McGlashan <[hidden email]> wrote in message
news:917mn0$39fm8$[hidden email]...
> There is - D4's ImageStripper is significantly more robust in this
respect.
> I'd be surprised if doing a "panic" made any significant difference, since
...

Excellent!  I look forward to using the new lagoon deployment system.  I
just got Dolphin 4 installed in the office.  I also think the pre-strip
scripts in D4 will be very usefull as well.

Chris

Mikael Svane wrote:

> By the way, why is the image saved before deploying? I never save the
image
> and instead I keep all my work in packages that I install whenever I start
> Dolphin. Therefore, it is slightly inconvenient that the image is saved
> automatically. Not that it matters a lot, but if it is only a feature and
> not an essential part of the deployment process, perhaps it could become
an
> option in some future version of Dolphin?

I'd like to see something like this too.  I use a dedicated, minimal and
clean, image for deployment -- I just load the packages I want into it and
deploy.  It's not a big deal (as Mikael says) but it'd be nice if I didn't
have to restore it from backup after every deployment.

    -- chris