proper way to save image while serving?

hi -

When using the (squeak) image as a database, what is the proper way to
save that image on a periodic basis? Doing it the naive way
(#snapshot: true andQuit: false, called from a #stepAt: method) leads
to my image locking up or crashing on a regular basis (at least I
think that this is the cause of the crashes/lockups).

I thought I saw code which rather saves a new version of the whole
image each time, but I can't find it now. Would that solve the issue?

thanks,
Michal

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I thought I saw code which rather saves a new version of the whole
> image each time, but I can't find it now. Would that solve the issue?

There are certainly other examples out there, but Pier does that. Have
a look at the class PRImagePersistency.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

thanks Lukas -

Looking into it, I see that in Jan 2008 you wrote on the pier list:

   I saw that you have PRImagePersistency set in your image. This will
   sooner or later result in corrupted sources and changes, if you
   manually change code or load packages in the image. You have been
   warned!

and then:

   saving the image while code is compiled can screw up your changes

Does this mean that I need to disable the auto-saving everytime I load
a new monticello version into the running server? (a rather frequent
event!)

thanks,
Michal
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Wed, Apr 08, 2009 at 11:58:07PM +0200, Michal wrote:
>
> When using the (squeak) image as a database, what is the proper way to
> save that image on a periodic basis? Doing it the naive way
> (#snapshot: true andQuit: false, called from a #stepAt: method) leads
> to my image locking up or crashing on a regular basis (at least I
> think that this is the cause of the crashes/lockups).
>
> I thought I saw code which rather saves a new version of the whole
> image each time, but I can't find it now. Would that solve the issue?

Michal,

If you are using a Unix (OS X or Linux) platform, and have OSProcess in
your image, then try this:

        UnixProcess saveImageInBackgroundNicely

This will fork a background Squeak to do the image save without locking
up your main server image. You'll need to take care that you have enough
disk space of course, but otherwise this approach will do the save with
no impact at all on your server image.

Dave
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Thu, Apr 09, 2009 at 12:04:58PM +0200, Michal wrote:
Michal,

No, I do not. I am not actually running any Seaside server. Definitely
you should test carefully.

I would suggest that you plan for these possible failure modes:

- Out of disk space. Probably your backup process should check in advance
to verify that sufficient space is available(*), but you may also want
to test the effect of trying to do the save with no space available,
just to understand the effect of this kind of failure.

- Backup process fails to complete, and the image never exits. If for any
reason the backup procedure fails to run to completion, such that the
background Squeak process does not exit, you would see an accumulation
of background Squeak processes that will eventually consume too many
system resources(**).

- Memory usage. The background Squeak process consumes a very small amount
of memory due (processes share address space after a Unix fork, until
memory is actually modified). However this may not be the case if your
server image is very active and doing garbage collection. Test this and
watch for system memory usage issues when you put this into your production
system.

(*)  Here is one way to check free disk space, assuming you have OSProcess
and CommandShell loaded. This example is on a Linux system, and I'm checking
free block count on the file system that Squeak is using:

  freeBlocks :=
    (ProxyPipeline command: 'df . | tail -1 | cut -c41-50 ')
       upToEndOfFile withBlanksTrimmed asInteger

(**) The number of running background processes started by OSProcess is:

  (OSProcess thisOSProcess allMyChildren select: [:p | p isRunning]) size

Dave

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside