I think all our examples are *way* too simple. If you really
wanted to simulate this race condition, write up a Wicket component
that invokes Sleep(5000) in its render() and hit that many times
quickly. That should simulate hitting a server under heavy load.Gili On Wed, 5 Jan 2005 17:22:48 +0100, Juergen Donnerstag wrote: >Johan, > >I tried to reproduce it with the "old" core, especially as I didn't >experience any such problems so far. Not even with a stress test tool >which siimulates plenty of clients working simultaneously. But if I >understand you correct, that is not the use case, because it doesn't >simulate a client refreshing the current multiple times short >sequence. Thus I did what you suggested. I pushed the f5 key for 30 >seconds (not releasing it for that time) and saw the requests arriving >at the server and being handled by Wicket. But still no exception. And >I choose one of the displaytag examples with plenty of planels, >border, ListViews etc. I tried several of the other examples. Still no >error.except a SocketException: Connection reset by peer. But on the >client side, everything was fine. > >I recall from mem that Jon predicted such errors, if we allow for >replaceing parents. Are you sure, the cause of the problem is not with >replacing/removing the parent? > >The reason why I'm asking. Are we 100% sure that synchronizing the >render process on the session object does not unneccessarily block >requests? > >Juergen > >On Wed, 05 Jan 2005 15:31:24 +0100, Johan Compagner <[EMAIL PROTECTED]> wrote: >> I just checked in a fix that Wicket only handles one request per session >> at once. >> >> There where a lot of problems when we don't do that. Strange markup >> errors, Or components >> that where didn't have a page anymore (removed from the parent) while >> they where rendering! >> >> This all happens when you for example pressed f5 (refrehs) in the >> browser a few times quick after each other. >> Because then on the serverside the same page or components where >> handled/rendered at the same time. Then >> they would use the markupstream for a container panel at the sametime. >> This ofcourse is wrong because >> thread1 could be in place X and thread2 at place Y. >> >> I couldn't think about a better solution then to synch over the session >> in the HttRequestCycle.handleRender() method. >> because callComponentListener() and page.render() needs to be synched at >> runned as a atomic operation. >> >> johan >> >> ------------------------------------------------------- >> The SF.Net email is sponsored by: Beat the post-holiday blues >> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >> _______________________________________________ >> Wicket-develop mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wicket-develop >> > > >------------------------------------------------------- >The SF.Net email is sponsored by: Beat the post-holiday blues >Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >_______________________________________________ >Wicket-develop mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
