[Seaside] Re: multiple piers on the same image with apache

Yanni Chiu yanni at rogers.com
Wed Nov 9 03:29:24 UTC 2011

On 08/11/11 8:00 PM, mail list wrote:
> Lukas wrote:
> You need to make sure that the persistence mechanisms between the
> instances do not mess with each other.
> SCOTT- I had set up different pier kernals for each instance.

Having different pier kernels does not address the issue that Lukas 

If you're using image persistency (i.e. image save, done in a forked 
process), then there is only one image saved for all kernels. Each pier 
kernel will be initiating (IIRC) a check of the transaction log, to 
determine if an image save is needed. I think there are concurrency 
checks and other code, to ensure that a pier kernel is saved in a 
consistent state; however, I'm not sure whether this logic would be 
sufficient when another pier kernel initiates an image save.

If you're using image segment persistence, then the above issues don't 
apply. But, I'm pretty sure image segment persistence does not work out 
of the box, and the image segment code has been (will be?) removed from 
Pharo - so that's a bad path.

I use Fuel persistence. See: http://ss3.gemstone.com/ss/pierfuel.html

> SCOTT- This was different piers on different ports in the same image. eg
> in the apache config for domain1.com <http://domain1.com> i would point
> to localhost:8080/pier1 and for domain2.com <http://domain2.com> it
> would ponts to localhost:8081/pier2. Both 8081 and 8080 were on the same
> image but different piers

I don't understand why you need to have separate ports (8080 and 8081), 
as well as separate paths (pier1 and pier2). It seems to me that 
choosing one or the other would be sufficient.

> I will continue to explore the issue and feedback if i can get it to
> run. I just wanted one image serving the piers since it would be less
> maintenance and less resources on myserver.

Is keeping multiple images up-to-date your maintenance concern? If you 
go with the Fuel persistence, then you can use the same image for all 
kernels, by reading in the kernel at startup. Fuel has a design goal to 
be fast for reading (i.e. de-serializing).

The resource calculation will depend on the size and number of pier 
kernel(s) you're running vs. the size of the basic Pier image. Suppose 
the basic Pier image is 20MB, and you're running 5 kernels that are each 
200MB. Then it's 5*220MB = 1100MB vs 5*200MB + 20MB = 1020MB. Yes, it's 
always going to be more memory, but it works now (without your having to 
code it). It might be better to spend the time shrinking the size of the 
basic Pier image.

> On seasidehosting.st for example, many hundred Pier images run in
> parallel on different ports ...
> SCOTT- Thisis my current configuration. One image for one domain.

How many images? Size of each? Are users seriously impacted by losing 
access to their kernel, due to problems in another kernel causing a 


More information about the seaside mailing list