registering WADocumentHandlers in WAApplication

> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> From: "Julian Fitzell" <[hidden email]>
> To: "Seaside - developer list" <[hidden email]>
> Sent: Wednesday, May 25, 2011 1:49:22 AM
> Subject: Re: [Seaside-dev] registering WADocumentHandlers in WAApplication
>
> 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 <[hidden email]> 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
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> >
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> 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

> Julian,
>
> There are two dictionaries in the cache, one for lookup by key (returns object) and another for lookup by object (returns key) and it's the object lookup that is causing the trouble.
>
> Reusing the key makes the most sense...
>
> Of course I was wondering not only about why an empty document is being generated/stored but why are documents going into the application cache ... I would have thought that the document would have been stored in the session cache .... yes there are two different places that the cache is used ...
>
> The one that is giving me trouble is the application cache and the bulk of entries in the cache are sessions, so the documents appear to be anomalous.
>
> Dale
>
> ----- Original Message -----
>> From: "Julian Fitzell" <[hidden email]>
>> To: "Seaside - developer list" <[hidden email]>
>> Sent: Wednesday, May 25, 2011 1:49:22 AM
>> Subject: Re: [Seaside-dev] registering WADocumentHandlers in WAApplication
>>
>> 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 <[hidden email]> 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
>> > [hidden email]
>> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>> >
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>