El jue, 27-08-2009 a las 21:55 -0400, Schwab,Wilhelm K escribió: > Sig, > > I must disagree, because there is more to what I am saying than simply to > skip cleanup (I am saying to do it in two parts, each at the correct time and > only at the correct time). Further, the current behavior has nothing to do > with shutdown - it is done pre and post snapshot. Dolphin has it right; we > should borrow the idea. > > Bill
Well, I suppose that there is a compelling reason to have it. Just one more scenario that I think that will be common, not that there won't be others that really need a solution like you describe: In a big web app, for example, you'll deploy a lot of PharoCore images (or better yet, PharoKernel as the one Pavel announced today) that manage each of them a lot of sessions of the users. The important data to save each time is outside the image, maybe on magma, a rdbs or in the file system, for files uploaded to the webapp. In case an error show up, I should have to modify all the images and save them all. Better is to patch the PharoCore template image and to restart them all to get a consistent fix on all the images at almost the same time. If I were to do it by hand, and saving each image, this will mean maybe hours to finish. In a case like this, it is more practical to restart the server with a minimal programed and announced maintenance window. But, as Stef likes to say: code, code, code! I have never used Dolphin. You have more experience with it and maybe you could port the code or implement a brand new based on that ideas and contribute it to Pharo. I will be glad to test it, of course. Cheers > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Igor > Stasenko > Sent: Thursday, August 27, 2009 8:26 PM > To: [email protected] > Subject: Re: [Pharo-project] Startup/shutdown > > As a compromise, i suggest to introduce 2 different shutdown modes: > - with cleanup > - without cleanup > > and then reflect it in UI, or > in system preferences. > Case closed :) > > 2009/8/28 Schwab,Wilhelm K <[email protected]>: > > I am not so sure it will not be a big deal. With an open system, there is > > no reason not to use development tools to make changes on production > > machines, and saving the image would be part of that process; every > > occurance would clobber all sockets, all web users, all database > > connections, etc. It's something that just feels wrong in capital letters, > > and we are trying to fix things. > > > > It definitely smells bad from a scientific computation perspective where > > external connections and saving the image are very common. > > > > Bill > > > > > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of > > Miguel Enrique Cobá Martinez > > Sent: Thursday, August 27, 2009 7:57 PM > > To: [email protected] > > Subject: Re: [Pharo-project] Startup/shutdown > > > > El jue, 27-08-2009 a las 20:23 -0400, Schwab,Wilhelm K escribió: > >> Hello all, > >> > >> I am doing some more porting and hitting some trouble spots - no real > >> surprise that they exist. However, I am struck by a strong belief that > >> Dolphin has a lot of things right, and startup and shutdown is very high > >> on that list. > >> > >> No offense to Nicolas, who has been quite helpful, let's consider a > >> somewhat extrmeme example. Suppose a server is using an ORB to do SSL > >> protected communications with various servers and clients, some Seaside > >> work, and has a few database connections open. Are we content with having > >> to close and reopen all of that just to save the image? I submit that > >> this is a flawed design. Worst case, the vm knows when it loads an image > >> and could tell the image that it happened. From there, a lot of extra > >> work could be dumped. > >> > >> Nicolas is quite right that step (2) below must be done carefully, but it > >> has been handled nicely in Dolphin by registering potential offenders in > >> the startup triggers and doing the cleanup at that time. External > >> resources are released on a shutdown trigger, but not image save. This > >> will strike again with native windows, as the current approach would (stop > >> me if this is a fallacy) have everything released and reopened on image > >> save, which would be very inefficient. > >> > >> I have code that expects a class called SessionManager, and I am seriously > >> thinking of creating it. It would trigger events for starup and shutdown, > >> help with logging, etc. Can it be donw without hacking the vm? > >> > > > > Just a question, what is the big deal with this, as you most often save on > > a development environment and not in a production environment. And as the > > number of saves on a production environment are seldom, it isn't a problem > > I think. > > In the dev enviroment you are pointing to dev services and you have few > > open conections/whatever so that is not a big deal either. > > > > > >> Bill > >> > >> > >> > >> =========================================================== > >> > >> [Pharo-project] Save and quit vs. Save - a clue to performance??? > >> Nicolas Cellier nicolas.cellier.aka.nice at gmail.com Thu Jul 16 > >> 22:48:34 CEST 2009 > >> > >> * Previous message: [Pharo-project] Save and quit vs. Save - a clue to > >> performance??? > >> * Next message: [Pharo-project] Save and quit vs. Save - a clue to > >> performance??? > >> * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > >> > >> Current policy is to cleanup before saving, and reconnect after > >> saving as if a fresh startup occured As you seem to suggest, a > >> possible alternative without using fork would be to: > >> 1) distinguish whether this is a newly restarted image (primSnapshot > >> returning true or false...) > >> 2) perform all the clean-ups at startup if newly restarted image > >> 3) rely on the process exit() to perform required resource clean-up > >> in case we quit (or let a self aboutToQuit do some) > >> > >> Step 2) would deserve great care, any unprotected access to an > >> uninitialized pointer of the old image would crash or trash memory... > >> > >> Nicolas > >> > >> 2009/7/16 Schwab,Wilhelm K <bschwab at anest.ufl.edu>: > >> > Nicolas, > >> > > >> > One thing I forgot to mention: thread safety??? IIRC, Dolphin triggers > >> > startup events, and all external resources clear pointers then (though > >> > they will release on shutdown, not image saving) to force a lazy > >> > connection. > >> > > >> > I see why, absent help from the vm, the image does not know when it > >> > starts and stops. What I do not get is why the vm does not tell it. If > >> > it did, I _think_ we could clean all of this up. Sometimes the truth > >> > hurts though, so please find any faults in my logic (or lack thereof). > >> > > >> > Bill > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > > Miguel Cobá > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
