Still teetering on the top of my To Do list
On 2011-07-27, at 11:48 AM, Michael Gargano wrote:
> was there ever a resolution to this. i'm encountering this problem a lot.
>
> -mike
>
>
> On Jul 15, 2011, at 1:56 PM, Ricardo J. Parada wrote:
>
>> Try the second one I sent out... That one is simpler and easier to
>> understand.
>>
>> Thanks
>>
>>
>>
>>
>> On Jul 15, 2011, at 1:52 PM, Chuck Hill wrote:
>>
>>> 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/mgargano%40escholar.com
>>
>> This email sent to mgarg...@escholar.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
_______________________________________________
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
