My co-worker commented on the jira. We have now a workaround for this problem but we'd need someone to confirm if it is a good or bad idea.
We replaced line 751 from wicket-ajax.js: from "this.url = url;" to " this.url = Wicket.replaceAll(url,"&", "&");" Does anyone know if there are any caveats in doing this? And if there are any, are there any alternative ways to fix this? - Mikko -----Original Message----- From: Mikko Pukki [mailto:[email protected]] Sent: 8. joulukuuta 2008 15:50 To: [email protected] Subject: RE: AjaxSelfUpdatingBehavior problem with HttpSessionStore Created JIRA issue WICKET-1971 and attached quickstart to it. https://issues.apache.org/jira/browse/WICKET-1971 -----Original Message----- From: Mikko Pukki [mailto:[email protected]] Sent: 4. joulukuuta 2008 22:49 To: [email protected] Subject: RE: AjaxSelfUpdatingBehavior problem with HttpSessionStore Hi, Sorry, I forgot to mention that the wicket version we are using, is 1.3.5 - Mikko ________________________________________ Lähettäjä: Mikko Pukki [[email protected]] Lähetetty: 4. joulukuuta 2008 22:29 Vastaanottaja: [email protected] Aihe: AjaxSelfUpdatingBehavior problem with HttpSessionStore Hi everybody, Recently we discovered that SecondLevelCacheSessionStore was giving us a huge performance hit in some of our applications, so we decided to the old HttpSessionStore. Performance increase was significant and the impact on memory usage was relatively small, so we decided to stick with it. But we also discovered a problem when using AjaxSelfUpdatingbehavior combined with ajax buttons (when ajax button forwards to another page (let's call is PageB) by setResponsePage method). When a user hits a button and immediately after that an ajax request is fired by the AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button. This is what happens when this behavior occurs: 1) User pressed an ajax button 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button 3) User ends up on PageB 4) now pressing ajax buttons on a new page has no effect WebRequestCycleProcessor's resolve method goes now to line 114: if (pageId != access.getId()) { // the page is no longer the active page // - ignore this request processRequest = false; } Wicket Ajax Debug prints something like this: INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413 INFO: Invoking pre-call handler(s)... INFO: Received ajax response (31 characters) INFO: <ajax-response></ajax-response> ERROR: Error while parsing response: Could not find root <ajax-response> element INFO: Invoking post-call handler(s)... We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's accept method is called with instance of PageB as entry parameter. But instantly after that a request that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user is really on PageB. I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real life application it shows up very frequently. Should I open a JIRA issue on this and attatch my quickstart application to it? Regards, Mikko --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
