RE: VM images and working in the VM image

Then I restart the server, and it loads with the new code (the 
packages I mentioned in my last message).  The patches I load are 
just a simple way of updating a running image in place.

I don't save runtime images; I simply patch them in place, and set 
them up so that they start up in a completely reproducible way.

I've never had a server crash during an update, btw...

At 11:03 PM 5/12/2007, you wrote:

>Assume the server crashes for some reason: what happens to those patches?
>Does "loading the patch" imply that the on-disk image is modified?
>
>Ted Neward
>Java, .NET, XML Services
>Consulting, Teaching, Speaking, Writing
>http://www.tedneward.com
>
> > -----Original Message-----
> > From: [email protected] [mailto:strongtalk-
> > [email protected]] On Behalf Of James Robertson
> > Sent: Saturday, May 12, 2007 7:52 PM
> > To: [email protected]
> > Subject: RE: VM images and working in the VM image
> >
> >
> > I'm talking about Cincom Smalltalk (VisualWorks specifically, but
> > most of what I said applies to Squeak as well).  When I change class
> > definitions, existing objects change shape as well - even as methods
> > are running.  I've not worried about that, because it's not been an issue.
> >
> > As to how I persist those changes, I do things like this:
> >
> > 1) Export the changes code from my test server as a Smalltalk file-out
> >
> > 2) Export the new versions of all the packages changed
> >
> > 3) Upload the patch and the new packages to the server
> >
> > 4) Put the new packages into the directory used when the image
> > starts, and put the patch into the patch directory
> >
> > 5) Kick the server (via a web console) to load the patch (and then delete
> > it)
> >
> > I patch in place, and also make sure to have all the most current
> > startup packages in place in case the server needs a restart.
> >
> > I would also argue that most of the "high end" Java app servers you
> > speak of could be done quite easily in Smalltalk.  We have plenty of
> > customers with complex applications.
> >
> >
> > >(*) No argument on the dynamic nature of the image vs. the static nature
> > of
> > >the Java app server (though, in theory, the app server doesn't need to go
> > >down just to change code, either--all that is handled through
> > ClassLoaders
> > >in the JVM, which are far more dynamic than you might expect). This may
> > be
> > >more complicated than what we can approach in this email, but... When you
> > >change the shape of objects in memory, though, how does the ST image
> > handle
> > >that? Do existing objects receive the change? And what happens if methods
> > >are invoked in the middle of the reload?
> > >
> > >(BTW, you and I, I think we've had this discussion on the usefulness of
> > the
> > >ST image before, over blogs--I'm not arguing against the idea, just
> > trying
> > >to understand it better.)
> > >
> > >(*) You're referring to your Cincomm Smalltalk flavor, correct?
> > VisualWorks?
> > >Not Strongtalk?
> > >
> > >(*) How do you persist those changes to the image so that if the machine
> > >crashes, the image doesn't lose all those changes? Do you periodically
> > have
> > >to flush the image to disk? And is that transactional somehow?
> > >
> > >(*) Hopefully you'll also allow me to assert that running a blog engine
> > >isn't exactly the high-scale requirement environment that some of the
> > Java
> > >(and .NET) app servers are asked to handle. :-) What I'd *really* love,
> > >though, in order to move this particular point out of the realm of the
> > >abstract, is to know *exactly* what the runtime footprint of your "app
> > >server image" takes up, so as to hopefully compare/contrast it against
> > the
> > >runtime footprint of a Java app server stack. (I'd much rather argue
> > facts
> > >than assertions, and numbers against "belief".)
> > >
> > >Heck, for that matter, I'm not trying to "argue" at all. Just learn. :-)
> > >
> > >Ted Neward
> > >Java, .NET, XML Services
> > >Consulting, Teaching, Speaking, Writing
> > >http://www.tedneward.com
> > >
> > > > -----Original Message-----
> > > > From: [email protected] [mailto:strongtalk-
> > > > [email protected]] On Behalf Of James Robertson
> > > > Sent: Saturday, May 12, 2007 7:19 PM
> > > > To: [email protected]
> > > > Subject: RE: VM images and working in the VM image
> > > >
> > > >
> > > > Oh?  My blog: http://www.cincomsmalltalk.com/blog
> > > >
> > > > runs on an image, as do all the others hosted there:
> > > >
> > > > http://www.cincomsmalltalk.com/userblogs
> > > >
> > > > Any arbitrary application server for Java you pick is going to chew
> > > > resources as well; claiming that the image is some kind of resource
> > > > hog is just silly.  Running a Smalltalk image w/o the GUI is fairly
> > > > easy to do (at least using the flavor I use) - and having the
> > > > compiler present allows me to add patches (including ones that change
> > > > the shape of objects in memory) as the image runs - I don't have to
> > > > play the "take it down, update, bring it up" game.
> > > >
> > > > To build my runtime I start with a base image, and start with a
> > > > command line like this:
> > > >
> > > > visual baseImage.im -filein startupScript.st - nogui
> > > >
> > > > Where startupScript.st has Smalltalk code that loads in the
> > > > components I need to run, and configures the system for runtime.
> > > >
> > > > >Case in point: ST's notion of the IDE-in-the-image is pretty lame
> > when
> > > > >looking to deploy an image within a "headless" environment. Is there
> > > > another
> > > > >approach when trying to build a server? Surely when running Seaside,
> > for
> > > > >example, I don't want or need the overhead of the IDE hanging
> > around....
> > > > It
> > > > >might be useful in certain scenarios, but most of the time, it's just
> > > > going
> > > > >to be useless overhead....
> > > > >
> > > > >I recognize that it's probably impossible to summarize the ST
> > philosophy
> > > > >down into a single email of reasonable proportions, and of course
> > it's up
> > > > to
> > > > >Richard to go read more about the ST philosophy if he wants to "get"
> > ST
> > > > in
> > > > >any reasonable sense. But it's not too much to ask, I don't think, to
> > > > answer
> > > > >in single-sentence form the specific issues being raised--plus, that
> > way,
> > > > >it's in the archives for others to discover later when they come to
> > ST
> > > > with
> > > > >their own questions.
> > > > >
> > > > >Ted Neward
> > > > >Java, .NET, XML Services
> > > > >Consulting, Teaching, Speaking, Writing
> > > > >http://www.tedneward.com
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email protected] [mailto:strongtalk-
> > > > > > [email protected]] On Behalf Of tim Rowledge
> > > > > > Sent: Saturday, May 12, 2007 2:50 PM
> > > > > > To: [email protected]
> > > > > > Subject: Re: VM images and working in the VM image
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 12-May-07, at 2:24 PM, Richard wrote:
> > > > > >
> > > > > > >
> > > > > > > Coming from a background of C++, Ruby and Java I'm used the idea
> > > > that
> > > > > > > you program in an IDE and then you output a Jar
> > > > > > That imply isn't the way Smalltalk works Richard. It sounds as if
> > you
> > > > > > would gain a lot by reading up on how Smalltalk works and how it
> > is
> > > > > > very different to old ways of doing things.
> > > > > >
> > > > > > Try  Smalltalk Central (http://www.smalltalk-central.com/
> > > > > > showDocument.ssp?section=Articles&name=Documentation), http://
> > > > > > www.iam.unibe.ch/~ducasse/FreeBooks.html etc.
> > > > > >
> > > > > > Basically we just don't do dead code. As one wag put it "source
> > code
> > > > > > in files? How quaint."
> > > > > >
> > > > > >
> > > > > > tim
> > > > > > --
> > > > > > tim Rowledge; [email protected]; http://www.rowledge.org/tim
> > > > > > There can never be a computer language in which you cannot write a
> > > > > > bad program.
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > No virus found in this incoming message.
> > > > > > Checked by AVG Free Edition.
> > > > > > Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date:
> > > > 5/11/2007
> > > > > > 7:34 PM
> > > > > >
> > > > >
> > > > >No virus found in this outgoing message.
> > > > >Checked by AVG Free Edition.
> > > > >Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date:
> > 5/11/2007
> > > > >7:34 PM
> > > > >
> > > > >
> > > > >
> > > > >
> > > > <Talk Small and Carry a Big Class Library>
> > > > James Robertson, Product Manager, Cincom Smalltalk
> > > > http://www.cincomsmalltalk.com/blog/blogView
> > > >
> > > >
> > > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG Free Edition.
> > > > Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date:
> > 5/11/2007
> > > > 7:34 PM
> > > >
> > >
> > >No virus found in this outgoing message.
> > >Checked by AVG Free Edition.
> > >Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date: 5/11/2007
> > >7:34 PM
> > >
> > >
> > >
> > >
> > <Talk Small and Carry a Big Class Library>
> > James Robertson, Product Manager, Cincom Smalltalk
> > http://www.cincomsmalltalk.com/blog/blogView
> >
> >
> > >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date: 5/11/2007
> > 7:34 PM
> >
>
>No virus found in this outgoing message.
>Checked by AVG Free Edition.
>Version: 7.5.467 / Virus Database: 269.6.8/800 - Release Date: 5/11/2007
>7:34 PM
>
>
>
>
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---