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
>
_______________________________________________
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
