[Seaside] Server Identification in Session Keys
renggli at gmail.com
Tue Aug 17 21:07:43 UTC 2010
On Tuesday, August 17, 2010, Sven Van Caekenberghe <sven at beta9.be> wrote:
> Thanks for the quick response, Lukas!
> On 17 Aug 2010, at 17:32, Lukas Renggli wrote:
>> On 17 August 2010 17:28, Sven Van Caekenberghe <sven at beta9.be> wrote:
>>> I am trying to configure Apache 2's mod_proxy_balancer with sticky sessions towards multiple Seaside 3 instances.
>>> What I need, apart from starting multiple VM's with the same image running on different ports (I am working on one machine), is that each VM adds a server identification to the session key (_s), so that the balancer can route everything in the same session to the same instance.
>>> How can this be done ?
>> The simplest thing is to use the port number as the identifier.
>>> As far as I understand, it is WAApplication (WARegistry>>#handleFiltered:) that hands out session ID's in the _s parameter (#keyField), but I cannot immediately find where the session ID's are generated (is it WACache>>#store using WAKeyGenerator ?) and how I could interfere in a clean way.
>>> Has anyone done this before ?
>> Sure, that's standard practice. Override #updateUrl: either in your
>> custom session class or in the root component.
> Well, I got this now:
> updateUrl: anUrl
> | port |
> super updateUrl: anUrl.
> port := self requestContext request host copyAfterLast: $:.
> anUrl addField: '_x' value: self session key, '.', port
> Is that a good way to get at the port ? I guess, when the port is not 80 and HTTP 1.1 is used.
Ask the server adaptor, it should know the port.
> Where does Seaside itself figure out the port when it is not hardcoded ?
> I have to find out if Apache mod_proxy_balancer needs only a host id, of a full session id plus host id like I did above.
> In the latter case, the overlap with _s is a bit much, I'll see.
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside