Re: "You backtracked too far" error after closing AjaxModalDialog and clicking on a link on the page
Re: "You backtracked too far" error after closing AjaxModalDialog and clicking on a link on the page
- Subject: Re: "You backtracked too far" error after closing AjaxModalDialog and clicking on a link on the page
- From: "Ricardo J. Parada" <email@hidden>
- Date: Fri, 15 Jul 2011 10:44:31 -0400
Here is an even simpler app:
Attachment:
PageCacheTest.zip
Description: Zip archive
On Jul 15, 2011, at 10:23 AM, Ricardo J. Parada wrote:
>
>
> It seems other people have ran into this same problem. It would be great if we can figure out what's going on.
> So far I just know how to reproduce in 5 easy steps which is very important. But I still don't understand why it happens. :-/
>
>
>
>
> On Jul 15, 2011, at 10:11 AM, Ricardo J. Parada wrote:
>
>>
>> I have some good news. I have a little test app with a simple Main component that reproduces the problem in 5 easy steps.
>>
>> Who is interested in trying it out? :-) You just import into Eclipse and follow the 5 easy steps on the Main component.
>>
>> <PageCacheTest.zip>
>>
>>
>>
>>
>>
>> On Jul 14, 2011, at 1:09 PM, Chuck Hill wrote:
>>
>>> I have, sort of, understood this code in the past. It is tricky, you really have to pay attention. IIRC what it has is a two level cache for (potentially) every page in the regular cache.
>>>
>>>
>>> Chuck
>>>
>>>
>>> On 2011-07-14, at 9:39 AM, Ricardo J. Parada wrote:
>>>
>>>>
>>>>
>>>> Oh... for reference that code in ERXAjaxSession.java looks like this:
>>>>
>>>> public void savePage(WOComponent page) {
>>>> ...
>>>>
>>>> // Remove the oldest entry if we're about to add a new one and that would put us over the cache size ...
>>>> // We do a CACHE_SIZE*2 here because for every page, we have to potentially store its previous contextid to prevent
>>>> // race conditions, so there technically can be 2x cache size many pages in the cache.
>>>> boolean removedCacheEntry = cleanPageReplacementCacheIfNecessary(pageCacheKey);
>>>> 208: if (!removedCacheEntry && pageReplacementCache.size() >= ERXAjaxSession.MAX_PAGE_REPLACEMENT_CACHE_SIZE * 2) {
>>>> Iterator entryIterator = pageReplacementCache.entrySet().iterator();
>>>> Map.Entry oldestEntry = (Map.Entry) entryIterator.next();
>>>> entryIterator.remove();
>>>> if (logger.isDebugEnabled()) logger.debug(pageCacheKey + "pageReplacementCache too large, removing oldest entry = " + ((TransactionRecord)oldestEntry.getValue()).key());
>>>> }
>>>>
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Jul 14, 2011, at 12:33 PM, Ricardo J. Parada wrote:
>>>>
>>>>> I don't understand the code in ERXAjaxSession.java:208-213 very well but I can see that the size of the page replacement cache referred to by that code is growing with every AJAX request until it is >= two times the size specified by er.extensions.maxPageReplacementCacheSize. From there on it removes entries from there.
>>>>>
>>>>> At this point if I close the dialog (AMD) and then click on the link on the page I get the "You backtracked too far" error.
>>>>>
>>>>> Anybody understands that code? :-)
>>>>>
>>>>> I'm gonna compare with my test Wonder app which all it has is the AMD and link on the page to test this and try to find out why I don't get the error there.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Jul 14, 2011, at 12:11 PM, Ricardo J. Parada wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> I don't get the error if I set er.extensions.maxPageReplacementCacheSize=50 in my Properties.dev file.
>>>>>>
>>>>>> So now I'm focusing on ERXAjaxSession.java:208-213 to see if that code to try to figure out if that code has anything to do with the problem I have when I reduce the cache size.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jul 13, 2011, at 10:36 PM, Alexis Tual wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> have you tried to raise the er.extensions.maxPageReplacementCacheSize (default is 30) ? It should delay the page restauration error, not fixing the real issue... and if you have few users and enough memory, it might be the cheapest way to get it done.
>>>>>>> Anyway, I filled a jira for this a year ago http://issues.objectstyle.org/jira/browse/WONDER-545 (Don't try the attached patch though, it's worse :))
>>>>>>>
>>>>>>> Still in Quebec, back to Poutine free area soon
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> Le 12 juil. 2011 à 19:29, Ricardo J. Parada a écrit :
>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 12, 2011, at 5:53 PM, Chuck Hill wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 12, 2011, at 2:45 PM, Ricardo J. Parada wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 12, 2011, at 4:52 PM, Chuck Hill wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Ricardo,
>>>>>>>>>>>
>>>>>>>>>>> On Jul 12, 2011, at 1:35 PM, Ricardo J. Parada wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Does anybody have an idea what could be causing this problem? The user clicks on an AjaxModalDialogOpener which opens the dialog. Then the user does a whole bunch of stuff in the dialog that involves many clicks
>>>>>>>>>>>
>>>>>>>>>>> Does it still happen if they don't make so many clicks?
>>>>>>>>>>
>>>>>>>>>> If they make a few clicks then it works okay.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> then finally clicks a DONE link to close the dialog.
>>>>>>>>>>>
>>>>>>>>>>> Are all of these links and clicks Ajax actions?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, they are clicking on links generated by AjaxSubmitButton components to be exact. :-)
>>>>>>>>>
>>>>>>>>> And you are certain that there are no /wo/ or /wa/ requests mixed in here?
>>>>>>>>
>>>>>>>> I set this property in my Properties.dev:
>>>>>>>>
>>>>>>>> log4j.logger.er.extensions.ERXApplication.RequestHandling=DEBUG
>>>>>>>>
>>>>>>>> and then I looked at all the uri's of the requests coming in. They have /ajax/ in there and when the dialog first comes up I see a few /_wr_/ and I guess the browser caches those since I don't see requests for those anymore on subsequent requests after the dialog is displayed.
>>>>>>>>
>>>>>>>> All the requests for the "many clicks" I mentioned have /ajax/ in them. I don't see any /wo/ requests mixed in.
>>>>>>>>
>>>>>>>> Also I set a breakpoint in ERXAjaxSession.java at the only place it calls super.savePage() where I assume the current page would be saved but I never hit the breakpoint. I would think that regular component requests would be generating new context IDs and therefore saving the page in the cache for those context IDs. But I don't see the page getting saved. :-/
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> The dialog has a closeUpdateContainerID bound with the id of an ajax update container to refresh, which it does refresh upon closing the dialog. But then the user clicks on a link on the page that is outside the refreshed AjaxUpdateContainer and the app displays the error "You backtracked too far. The application backtracking limit of 30 has been exceeded."
>>>>>>>>>>>
>>>>>>>>>>> Ajax links or regular component actions links? I do what seems to be the same thing (except maybe the "does a whole bunch of stuff in the dialog") and have not had any problems.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> They are regular component action links. The context ID for which the page is being restored is 22.
>>>>>>>>>
>>>>>>>>> The original URL is 21?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Well, I just put in there a <wo:link string="test" action="$test"/> and by inspecting that link after I close the ajax modal dialog and the update container refreshes the href for the link is:
>>>>>>>>
>>>>>>>> http://192.168.1.9:53295/cgi-bin/WebObjects/Phynance.woa/wo/EmqPpwSYBiOiS7PPSLDXzw/8.0.0.9.1.1.13.1.5.1.2.1.1.3.51
>>>>>>>>
>>>>>>>> and clicking that generates the "You backtracked too far" error.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> The key to tracking this down is to know if it is the Ajax or the regular page cache that is missing the component.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm stepping through the restorePageForContextID() in ERXAjaxSession.java but I'm not sure what to look for.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sorry, I just meant if the URL that caused the error was a /ajax/ or /wo/ URL. It sounds like a /wo/ URL so that suggests to me that something in your dialog is generating /wo/ or /wa/ requests that are pushing the page out of the standard page cache.
>>>>>>>>
>>>>>>>> I did not see any /wo/ nor /wa/ requests. They are all /ajax/ requests.
>>>>>>>>
>>>>>>>> Maybe I'll try to create a test Wonder app with an ajax modal dialog with a single ajax link in it that displays the current time when clicked... Then I can click it many many times. Then close the dialog and then click on a link on the page afterwards to see if I can reproduce.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Chuck
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Chuck Hill Senior Consultant / VP Development
>>>>>>>>>
>>>>>>>>> Come to WOWODC this July for unparalleled WO learning opportunities and real peer to peer problem solving! Network, socialize, and enjoy a great cosmopolitan city. See you there! http://www.wocommunity.org/wowodc11/
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>
>>>
>>> --
>>> Chuck Hill Senior Consultant / VP Development
>>>
>>> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
>>> http://www.global-village.net/products/practical_webobjects
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden