*jumps up and down on chuck's list*
On Jul 27, 2011, at 2:50 PM, Chuck Hill <ch...@global-village.net> wrote:
> 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/mgargano%40me.com
>
> This email sent to mgarg...@me.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
