[Seaside-dev] registering WADocumentHandlers in WAApplication

[Julian Fitzell]

Am I misunderstanding? If it's a new WADocument instance, it should
have a different key...

I guess our cache behaviour is somewhat undefined in the case of
storing the same object twice? I don't feel strongly about reusing the
key or giving a new one ( I guess the former is more useful?) as long
as the two indexes are in sync (i.e. the object doesn't appear twice
in objectsByKey).

Why is there an empty document being generated at all?

Julian

On 5/25/11, Dale Henrichs <dhenrich at vmware.com> wrote:
> 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
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>