1> HttpRequestCycle.callComponentListener() This one call an interface methods of components. If this changes
the component structure somehow. Then after this call in the page.render() should use that specific set of components
that the page did have after the call to callComonentListener. But if a second request does exactly the same thing and
again the page is modified. Then the page.render suddenly has different components. Strange things can happen then
for example a component is in render fase but doesn't have a Page parent object anymore.
2> It is possible that 2 request uses the exact same MarkupStream component of a container/panel.
first request makes a MarkupStream (instance1) then a second request makes also a MarkupStream (instance2)
then instance1 is replaced by instance2 and if then the first request takes the markupstream (see Container.findMarkupStream())
but it uses the instance2 markupstream then. Not the one he made himself! And then the second request also uses
that markupstream. But then all strange things can happen because a markupstream has a state (Current MarkupElement)
So in the end. We don't have to synchronize on the session i think. But we should synchronize on the page object.
But that is a problem because callComponentListener is currently also responseable for lookup the page which we would render.
So where we now have synchronize(session) we must have synchronize(page)
But because of that all the code from callComponentListener that handles the lookup of the page we want should go up
something like this:
protected void handleRender()
{
Page page = getCurrentPage(); if(page != null)
synchronized (page)
{
if (callComponentListener() || bookmarkablePage() || homePage())
{and then callComponentListener should only do the interface stuff. But this is very tricky to do
Because callComponentListener test for things like stale (and that is what getCurrentPage should do now)
But then callComponentListener should know it was a state page in getCurrentPage so it doesn't have to do the interface calling stuf.
If anybody has a good impl for this please let me know.
Eelco Hillenius wrote:
Yes, Juergen you are right that this is the case. However, this doesn't only happen when just 'replacing' a component, but will happen everywhere where you invalidate a model (and remove all components) and re-add the components.
Eelco
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
------------------------------------------------------- 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
