Image shutdown/startup on demand

Hi all,

Currently I have a couple images running only couple applications  
each. We have plans in the near future to have more apps running on  
the same computer. The current plan it to have them all run in the  
same image.

I understand that some people run each application in a separate  
image. This image will start up when needed and shut down after is  
has been used. I can see the advantages of doing it this way  
especially if you are using the image for persistence.

How are people doing this? Apache, Apache+PHP/Perl/Ruby, Squeak?  
Ideally I would like to see it done in Squeak with a Seaside front-
end.  How are you keeping the Images up to date?

What are some of the disadvantages of doing it this way. Some of the  
obvious ones I see are keeping all this images up to date and you  
could actually use more of the machines memory if lots of the images  
are up and running at the same time.

It would be nice if front end allowed you to set up prototype images,  
maintain images, and show the status of the images. Are there any  
prebuilt solutions out there that do this (preferably free and  
running on Squeak)? If not how much interest is there in something  
like this. It looks like this might be a path I want to pursue.

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

William Harford wrote:
> This image will start up when needed and shut down after is  has been
> used. I can see the advantages of doing it this way  especially if you
> are using the image for persistence.
>
> How are people doing this? Apache, Apache+PHP/Perl/Ruby, Squeak?  
> Ideally I would like to see it done in Squeak with a Seaside front-
> end.

There's Avi's approach outlined here:

http://lists.squeakfoundation.org/pipermail/seaside/2006-August/008769.html

> What are some of the disadvantages of doing it this way. Some of the  
> obvious ones I see are keeping all this images up to date and you  could
> actually use more of the machines memory if lots of the images  are up
> and running at the same time.

What do you mean by "keeping all the images up to date"?
I thought you had in mind one image per application (or more
than one application), for all users of that application.
Are you thinking of one image per user?

> It would be nice if front end allowed you to set up prototype images,  
> maintain images, and show the status of the images. Are there any  
> prebuilt solutions out there that do this (preferably free and  running
> on Squeak)? If not how much interest is there in something  like this.
> It looks like this might be a path I want to pursue.

It's probably an important piece of infrastructure to have,
once people deploy more than a single image or application,
increase their user base, or upgrade application versions.
It's not yet a priority for me, but I've been keeping it in mind.
I wouldn't mind trying out some ideas.

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

On Sep 19, 2006, at 2:28 PM, Yanni Chiu wrote:

Ah it seams Avi has the luxury of not dealing with external resources  
(like db connections) in a session.

I was thinking more along the lines of when all the sessions have  
expired clear all caches, save this image, and quit. An approach that  
would be better suited for images the require external resources.

It would be nice if this, mythical not yet made, application could  
handle both situations.

>
> What do you mean by "keeping all the images up to date"?
> I thought you had in mind one image per application (or more
> than one application), for all users of that application.
> Are you thinking of one image per user?

I mean code changes, bug fixes, and other things that you might want  
pushed out to all similar images.

Great! Are you going to be at the Tomb Raiders Club meeting tonight?  
I would love to share/get some ideas.

How would Comanche perform as a proxy?

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

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

William Harford wrote:
> Great! Are you going to be at the Tomb Raiders Club meeting tonight?  I
> would love to share/get some ideas.

Yep, planning to be there.

> How would Comanche perform as a proxy?

AFAIK, Comanche is mainly an HTTP server. Not sure whether
it can do proxying out of the box.

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

On Sep 19, 2006, at 3:18 PM, Yanni Chiu wrote:

>
> AFAIK, Comanche is mainly an HTTP server. Not sure whether
> it can do proxying out of the box.

Proxy is a misleading word is this content. I did not mean an HTTP  
proxy I meant a HTTP server that can foward HTTP requests on to  
something else with out the knowledge of the web browser. My concern  
is the performance of Comanche while performing this task and how it  
might to compare to Apache doing the same task.

My thought was to centralize the incoming requests into one image.  
That image would then be responsible for starting up an image,  
forwarding a request, shutting down an image, load balancing, and  
maintaining and checking status of the images. Doing it in Squeak  
would keep it cross platform and would also follow the spirit of  
eating your own dog food.

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

Dear William,
 
>>
>> What do you mean by "keeping all the images up to date"?
>> I thought you had in mind one image per application (or more
>> than one application), for all users of that application.
>> Are you thinking of one image per user?
>
> I mean code changes, bug fixes, and other things that you might want
> pushed out to all similar images.
>
My current approach to handling this is to put all the data for the app
in a database. I am using magma. In this case updating code changes and
bug fixes is just a case of updating the one image, and all users/apps
deployed servers share the same image. To extend this scheme''s
usefulness it might be an idea to put the seaside/config configurations
in the database as well so that they too can be set at runtime. This is
not something that I have tried yet.

Another more challenging but altogether possible approach might be to
put the code-base in the magma repository, and have that shared among
several images. Committing a change to a class, or the whole codebase,
into the repository can then be automatically replicated across the
servers instantly (or at a suitable juncture i.e. as soon as they go
quiet, expire sessions etc.)

how about it?

Keith








       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside