[Seaside] Server Identification in Session Keys

Sven Van Caekenberghe sven at beta9.be
Wed Aug 18 09:06:11 UTC 2010


Philippe,

On 18 Aug 2010, at 10:24, Philippe Marschall wrote:

> 2010/8/18 Sven Van Caekenberghe <sven at beta9.be>:
>> 
>> On 18 Aug 2010, at 07:20, Philippe Marschall wrote:
>> 
>>> Seaside-Cluster [1] does this. You need to replace WAApplication with
>>> WAClusteredApplication and then configure the route on the
>>> application.
>>> 
>>> The easiest way to do this is using:
>>> 
>>> WAAdmin makeAllClusteredWith: yourRoute
>>> 
>>> [1] http://www.squeaksource.com/ajp.html
>>> 
>>> Cheers
>>> Philippe
>> 
>> Incredible, Philippe: this is exactly what I was looking for. Thanks!
>> Is this still compatible with Seaside 3.0 ?
> 
> I hope so. I wrote it for an older version of Seaside 3.0. Please
> report any problems.

Well, I manually checked all methods and the overrides should still work as far as I can see.

There is one Undefined class, WASessionConfiguration:

WAAdmin class>>register: aComponentClass asClusteredApplicationAt: aString
	"Use this to programatically register a component as an application."
	"WARenderLoopConfiguration is added by default because most users will use WASession and the Render Loop."
	| application |
	application := self register: WAClusteredApplication at: aString.
	application configuration
		removeParent: WASessionConfiguration instance; "make the chain slightly cleaner"
		addParent: WARenderLoopConfiguration instance;
		addParent: self applicationDefaults.
	application preferenceAt: #rootClass put: aComponentClass.
	^ application

But I guess the #removeParent: isn't really needed, is it ?

I will be actually testing this tomorrow, I hope.

>> It is not a lot of code, I think/hope I can figure it out myself.
>> Any chance of an article/bog post/email thread elaborating on this ?
> 
> I'll see what I can do.

It would be nice if something already existed, you don't have to write something new. This involves a lot of unix level hacking as well which is not always very standardized.

>> From the other packages in that repository I can see that you implemented several ways of tackling the same problem.
> 
> No, there are three different issues solved by each package:
> - Seaside-Cluster adds the jvmRoute to the session id to make
> mod_proxy_balancer work Seaside. It's fairly simple and should
> actually work.
> - AJP is an AJP protocol implementation to make mod_proxy_ajp [1] work
> with Seaside. This is alternative protocol to HTTP/FastCGI/SCGI to
> connect Seaside to a frontend server. It seems to work but needs more
> testing before putting into production.
> - ModCluster is a mod_cluster [2] client implementation. Right now it
> can only listen to Apache broadcasts and cannot yet register itself to
> Apache.
> 
> [1] http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html
> [2] http://jboss.org/mod_cluster

Is any of this running in (public) production somewhere ?

Sven



More information about the seaside mailing list