[Seaside] About Seaside 3.0
philippe.marschall at gmail.com
Sun Jul 13 20:44:02 UTC 2008
2008/7/13 stephane ducasse <stephane.ducasse at free.fr>:
> I understand what you mean by reliability (running 20 servers and killing
> the ones not running)
No, I mean the following:
For each request Seaside forks a special "restricted process" which
has the following properties
- it is not allowed to allocate more than 2 MB of heap memory
- it is not allowed to use up more than 10 secs of CPU time (not
counting IO wait and GC)
- it is lightweight like normal Smalltalk processes
In addation on a image level there are the following properties:
- instances of WASession are not allowed to take up more than 100 MB total
- we are not allowed to have more than 10'000 live instances of WASession
- we are not allowed to have more than 20 concurrent Seaside requests
-> we don't have more then 20 restricted processes
Of course all numbers are subject to tweaking.
> but pay attention, squeak vms is not = to smalltalk vms.
Yes, gems are indeed very different and provide also other nice
features like session replication.
>> No, that's very reassuring.
>>> Where is the problem? Is it Seaside,
>>> or dialect-specific?
>> Smalltalk images do a lot of things as a consequence there are very
>> lot of things that can go wrong. Smalltalk images were never
>> engineered for reliability. One rouge thread can take down the whole
>> image. Contrast that to Apache which was engineered for reliability.
>> An Apache module can segmentation fault and Apache keeps running.
>> Compare that to the Squeak image where the UI event thread can
>> interact in very interesting ways with the GC.
>>> I am accustomed to my Smalltalk images running
>>> strong when the OS is starting to crumble around them.
>> Good for you.
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside