[Seaside] Backtracking/filestream questions

Julian Fitzell julian at beta4.com
Mon Mar 15 08:43:54 CET 2004


Colin Curtin wrote:

>>I'm having trouble following you.  What does "used up all the 
>>namelookups" mean?  What specifically do you mean by "allowed this app 
>>to use backtracking"?  And how are they related?
> 
> 
> I apologize. There's a 'resolverMutex' in
> NetNameResolver>>#nameForAddress:timeout: which locks up all available
> semaphores for name resolution since (presumably) my Seaside session is not
> letting go of them. I assume that this is because of my #initialize which
> reads:
> 
> initialize
>     self session registerObjectForBacktracking: self.
> 
> and thus Seaside will keep a session open until timeout. Which brings up another

I don't think this is right.  The session is certainly being kept around 
but when is the semaphore supposed to be getting signalled?  The stack 
should unwind far enough to make sure any critical sections you enter 
and any ensure blocks you go into get exited properly (though note that 
if you hit an error and have the walkback page turned on, the stack 
doesn't get unwound because the page is holding onto the process until 
you ask to debug it).  Presumably the semaphore gets signalled before 
#nameForAddress:timeout: returns?

As a general note to all, I've made several few fixes for some 
concurrency problems we started to see under heavy load testing at work. 
  I'll be merging them back into the trunk soon.

> question, if I could: Where might this timeout mechanism be? And how could I
> mess with it? Is it part of WASession?

You can configure the session timeout with the config application 
(usually registered at /seaside/config when you install).  WARegistry 
holds onto a bunch of sessions; WASession's #isActive method checks the 
config value and compares it to the most recent access to the session.


-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)



More information about the Seaside mailing list