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 ([email protected])
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/alexis.tual%40gmail.com
>>>>>>>
>>>>>>> This email sent to [email protected]
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list ([email protected])
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com
>>>>>
>>>>> This email sent to [email protected]
>>>>
>>>
>>
>> --
>> 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 ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
