[Seaside] Very wierd IACache problems

Avi Bryant seaside@lists.squeakfoundation.org
Thu, 18 Jul 2002 11:08:11 -0700 (PDT)


On Wed, 17 Jul 2002, Tim Rowledge wrote:

> OK, that sounds reasonable, though it might be nice to make it an
> on-demand process of building them.

Well, it does - I'm just speculating that at some point you played with
the examples in this image, and the sessions were created then.

> Yeah, looks ugly. It appears to be several hundred at least (925 in
> fact!). The only thing I noticed that might have anything to do with it
> is that #remove: is a null method.

Well, remove: shouldn't really need to do anything - the way LRUCache
works is to keep a strongly referenced queue and a
weakly referenced table.  If it keeps the queue down to a reasonable size
it shouldn't ever have to explicitly remove stuff from the table; at
least, that was the theory.  Thinking about it now, I don't really see a
good reason not to just have a normal Dictionary for the table and have
#remove: explicitly remove stuff from it, since I'm not expecting these to
be referenced from anywhere else anyway.  My orginal thought was that I
didn't want to clear the cache until a garbage collect, just to give
sessions a little extra grace when memory was plentiful... but the
simpler approach may work better.  Which doesn't mean I won't have to go
chasing pointers, but it might make that easier.

You may also just want to use IAExpiringCache or something instead.

> Of possible interest is the fact that when it dies the URL in the
> browser url field is ..mumble../act with no reference to the session etc
> in there, unlike every other time I get to notice
> it.http://gurgeh:8080/seaside/basicDemo/view?session=3F4EA0567E9D4002&tx
> n=top&page=21 is more usual for example. The error brings with it a page
> claimingto redirect me to
> /seaside/basiceDemo/view?session=3E44990C7C893202&txn=current&page=curre
> nt but it doesn't go anywhere since I get the notifier in the image.

Is this just after a form submit?  That would explain the bare URL.
Could the POST somehow be getting mangled?

Something to try - in IAForm>>printHtmlTo:withCallbackKey, change
'method'->'POST' to 'method'->'GET', and see if that makes any difference.

Avi