[Seaside-dev] registering WADocumentHandlers in WAApplication

[Dale Henrichs]

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" <jfitzell at gmail.com>
> To: "Seaside - developer list" <seaside-dev at lists.squeakfoundation.org>
> 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 <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
> >
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>