Programmatically save image, and also do it periodically

I need to urgently do both these saves:
  - do these on command (via Seaside app interface)
  - automatically on a timer

I've browsed a bit and found
    SmalltalkImage current snapshot:andQuit:

But this seems to require a confirmation. How do I bypass that?

I found STimer for timed block execution, but found no way to stop an
STimer.

Help appreciated,

Sophie

In the mailing list archives there was a long discussion of coding up  
a special unix VM that uses unix's virtual memory features to
fork the squeak process and do copy on write. This let the fork/
snapshot logic then save the image to disk, and let the copy of the  
process continue
running at the expense of abusing the virtual memory features of Unix.

This ensured you got a correct copy of your image written to disk, and  
that the write process did not hang up the image.  If you dig a bit  
more you'll
see you can call the save logic without the prompt, but what happens  
is a full GC happens, then the machine is written out to disk. This  
process takes many
milliseconds/seconds and can be a long time if the image is really  
large. Then if the image is busy you'll run into things like dropping  
socket open requests because
the VM does not respond to them promptly.

On Jan 8, 2008, at 10:18 AM, itsme213 wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

On Jan 8, 2008 10:18 AM, itsme213 <[hidden email]> wrote:

> I need to urgently do both these saves:
>   - do these on command (via Seaside app interface)
>   - automatically on a timer

Why is it urgent to save "automatically on a timer"? Is it because
you're using the image to hold key data that should really be kept in
a database?

Cheers!

--Tom Phoenix

itsme213 wrote: Hi, two suggestions...

1)

Pier has periodic image saving code which you could adapt in the class
PRImagePersistency.
OSProcess is able to fork the image and save it, so as not to interupt
the running image.

2)

Installer mantis fixBug: '5851 Refactor SmalltalkImage saveAs'.

This provides a minor refactoring to provide a confirmation free variant
 SmalltalkImage-#saveAs: <imageName>

This fix is part of the 'LevelPlayingField' image generation script, and
is needed by Launcher.

best regards

Keith

On Jan 8, 2008 10:18 AM, itsme213 <[hidden email]> wrote:

> I've browsed a bit and found
>     SmalltalkImage current snapshot:andQuit:
>
> But this seems to require a confirmation. How do I bypass that?

This works for me without a confirmation:

    SmalltalkImage current saveSession

...but it seems to call #snapshot:andQuit:, so I don't know what
confirmation you're seeing.

Hope this helps!

--Tom Phoenix

> Why is it urgent to save "automatically on a timer"? Is it because
> you're using the image to hold key data that should really be kept in
> a database?
>  
"should" ???

Surely there is no should with squeak!

Keith

Hi John,

John M McIntosh wrote:

> In the mailing list archives there was a long discussion of coding up a
> special unix VM that uses unix's virtual memory features to
> fork the squeak process and do copy on write. This let the fork/snapshot
> logic then save the image to disk, and let the copy of the process continue
> running at the expense of abusing the virtual memory features of Unix.

That sounds very interesting! An instant snapshot, that's what I am
waiting for web application servers which use image as a database. Do
you know if someone did some more steps to such snapshot?

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

On 1/8/08, Janko Mivšek <[hidden email]> wrote:

> That sounds very interesting! An instant snapshot, that's what I am
> waiting for web application servers which use image as a database. Do
> you know if someone did some more steps to such snapshot?

Yes, we've been using it ever since then.  The patches are pretty
rough and unix specific, though, so I've never sought to get them
included in the official VM.

Avi

Avi Bryant wrote:
> On 1/8/08, Janko Mivšek <[hidden email]> wrote:
>
>> That sounds very interesting! An instant snapshot, that's what I am
>> waiting for web application servers which use image as a database. Do
>> you know if someone did some more steps to such snapshot?
>
> Yes, we've been using it ever since then.  The patches are pretty
> rough and unix specific, though, so I've never sought to get them
> included in the official VM.

Do you think those patches are too dangerous to be included in general
VM (even if only on unixes)? Where do you see side effects?

But it can be said that you obviously tested them quite intensively and
quite for a while :)

Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

"Tom Phoenix" <[hidden email]> wrote in message
> Why is it urgent to save "automatically on a timer"?

Nope, because I have lost 4 hours of time in the last 24 recovering lost
work due to 3 Squeak freezes, pretty much stock 3.9 image :-(

Sophie

"Keith Hodges" <[hidden email]> wrote in message

> OSProcess is able to fork the image and save it, so as not to interupt
> the running image.

I think this is what I need. I tried to directly call from a Seaside anchor
to
    SmalltalkImage current saveAsNewVersion
and it froze Squeak. Solid. I don't know how to tell what is eating up
cycles, and how to interrupt or kill processes yet (took a look at
ProcessBrowser).

(btw - this is for a demo I need to do, not for saving my squeak devlopment
work :-)

I found OSProcess but don't know how to "fork an image", actually I'm almost
out of time for this "feature" :-) If you know it off the top of your head
please shoot me a hint.

Thanks - Sophie

On Jan 8, 2008 1:04 PM, itsme213 <[hidden email]> wrote:

> Nope, because I have lost 4 hours of time in the last 24
> recovering lost work due to 3 Squeak freezes, pretty much
> stock 3.9 image :-(

Why does your image freeze so often? Do you know about using
Command-period (or Alt-period) to interrupt a long-running process?

Cheers!

--Tom Phoenix

"Tom Phoenix" <[hidden email]> wrote in message

> Why does your image freeze so often? Do you know about using
> Command-period (or Alt-period) to interrupt a long-running process?

I don't know, some were from bugs in my code called from the browser, others
seemed like very strange mouse glitches. I got some "event buffer overflow"
display on the bottom of the window; and Alt-. did nothing. It's been mostly
good, but when it's bad it can hurt, specially for someone not familiar with
the nuances of manual recovery.

Auto-save, here I come ... :-)

Tom Phoenix wrote: A stock 3.9 image will not have any fixes for the semaphore issues...

Can anyone tell me the current best practice set of fixes for this, and
which images these apply to.

I can then post them to a level playing field script at
http://installer.pbwiki.com/AntiFreeze

Keith

On 8-Jan-08, at 2:26 PM, itsme213 wrote:
Beware of the dangers herein. If you make some dangerous change and it  
auto-saves ... you've now got a live image with the dangerous state  
and a saved image with the dangerous state.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Die dulci fruere = Have a nice day

On Tue, Jan 08, 2008 at 03:13:38PM -0600, itsme213 wrote:
> "Keith Hodges" <[hidden email]> wrote in message
>
> > OSProcess is able to fork the image and save it, so as not to interupt
> > the running image.
>
> I found OSProcess but don't know how to "fork an image", actually I'm almost
> out of time for this "feature" :-) If you know it off the top of your head
> please shoot me a hint.

Sophie,

Assuming that you are running a Unix VM and that you have loaded the
OSProcess package, you can use "UnixProcess saveImageInBackground" or
"UnixProcess saveImageInBackgroundNicely".

Here is an explanation from the underlying #saveImageInBackground:nice: method

saveImageInBackground: savedImageName nice: niceFlag
        "When Squeak is used as a server it is sometimes desirable to periodically
        save image snapshots. This method forks a headless Squeak to perform a
        snapshot without impacting the server Squeak. Very little additional memory
        is required to do this because Unix copy-on-write memory management allows
        the two Squeak images to share object memory while the save is performed.
        The saved image is given a time stamped name, and the image name of
        the main server Squeak remains unchanged. If niceFlag is true, the
        background OS process runs at lowered scheduling priority."

HTH,
Dave

We have a squeaksource image running, and if the image crashes we lose
any new projects and/or users registered since the last save. Thus a
periodic, automatic/programmatic save would be ideal.

Regards,
John

www.pinesoft.co.uk

Tom Phoenix wrote:

Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

El 1/9/08 7:32 AM, "John Thornborrow" <[hidden email]> escribió:

> We have a squeaksource image running, and if the image crashes we lose
> any new projects and/or users registered since the last save. Thus a
> periodic, automatic/programmatic save would be ideal.
>
> Regards,
> John

I put Scheduler of John Pierce in FunSqueak.
All you need is do this in a Workspace
| scheduler |
scheduler := TaskScheduler new.

scheduler start.
scheduler
do: [{SmalltalkImage current snapshot: true andQuit: false]
 every: 60 minutes.

Off course, Scheduler also works in several Squeak images

Edgar

itsme213 wrote:
> I don't know, some were from bugs in my code called from the browser, others
> seemed like very strange mouse glitches. I got some "event buffer overflow"
> display on the bottom of the window; and Alt-. did nothing. It's been mostly
> good, but when it's bad it can hurt, specially for someone not familiar with
> the nuances of manual recovery.

Is it just Squeak? If other applications are also ill-behaved (e.g.
gcc), you could have bad memory.

Tony

"tim Rowledge" <[hidden email]> wrote

>> Auto-save, here I come ... :-)
> Beware of the dangers herein. If you make some dangerous change and it
> auto-saves ... you've now got a live image with the dangerous state  and a
> saved image with the dangerous state.

Ah, thank you for the warning! Perhaps I will use Save as New Version, (and
set the timer a bit longer :-)

Sophie