[Seaside-dev] registering WADocumentHandlers in WAApplication

Dale Henrichs dhenrich at vmware.com
Wed May 25 04:19:42 UTC 2011


I'm doing some load testing of SqueakSource3 in GemStone and I have discovered that fairly often (nearly every request), a WADocumentHandler for an empty string is stored into the cache of an application. The way that the WACache is setup, you get a unique key generated each time the empty string is stored, however, the object to key map entry (in keysByObject) for the empty string is stomped on ... I guess this doesn't affect Seaside in Pharo, but in GemStone this causes a commit conflict ... 

Here's a chunk of the stack:

2 WARegistry >> register: @15 line 3  [GsMethod OOP 558534657]
3 WARenderContext >> urlForDocument:mimeType:fileName: @10 line 9  [GsMethod OOP 521811457]
4 WAContentElement >> document:mimeType:fileName: @3 line 2  [GsMethod OOP 145453569]
5 WAContentElement >> document:mimeType: @2 line 2  [GsMethod OOP 145452801]
6 WAContentElement >> document: @3 line 2  [GsMethod OOP 145453825]
7 ComplexBlock in WAHtmlRoot >> writeStylesOn: @9 line 6  [GsMethod OOP 148753921]
8 ComplexBlock in Set >> do: @4 line 11  [GsMethod OOP 9659649]
9 ComplexBlock in KeyValueDictionary >> keysDo: @3 line 7  [GsMethod OOP 2280705]
10 KeyValueDictionary >> keysAndValuesDo: @25 line 21  [GsMethod OOP 2283265]
11 KeyValueDictionary >> keysDo: @4 line 6  [GsMethod OOP 2280705]
12 Set >> do: @5 line 11  [GsMethod OOP 9659649]
13 WAHtmlRoot >> writeStylesOn: @12 line 3  [GsMethod OOP 148753921]
14 WAHtmlRoot >> writeHeadOn: @6 line 6  [GsMethod OOP 148748545]
15 WAHtmlRoot >> openOn: @3 line 4  [GsMethod OOP 148756225]
16 WADocument >> open: @3 line 4  [GsMethod OOP 146206721]
17 WARenderPhaseContinuation >> processRendering: @25 line 28  [GsMethod OOP 180412673] 

When I'm hitting the system real hard, the commit conflicts can severely impact performance ... over an empty string:)

I am tempted to change the #store: algorithm in WACache to first do a lookup in the keysByObject map to see if there is an existing key and if so, reuse the key...

At this point in time, I haven't looked at the impact on the aging algorithms with respect to the WADocumentHandler nor have I looked at whether there really does need to be a unique WADocumentHandler or not ... Perhaps there's an official way to do this in which case, perhaps WARenderContext >> urlForDocument:mimeType:fileName: should be changed...

I'll do some experiments tomorrow to see if things break or not.

Either way, though I think that the current behavior is probably a bug ...

Dale


More information about the seaside-dev mailing list