I will try it later.
On 2011-07-15, at 7: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 (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/alexis.tual%40gmail.com >>>>>>> >>>>>>> This email sent to alexis.t...@gmail.com >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com >>>>> >>>>> This email sent to rpar...@mac.com >>>> >>> >> >> -- >> 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 >> >> >> >> >> >> >> > -- 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com