"You backtracked too far" error after closing AjaxModalDialog and clicking on a link on the page

[Ricardo J. Parada]

Hi All,

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 then finally clicks a DONE link to close the dialog. 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."

Any ideas?

Thanks,
Ricardo

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobje...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects-dev-garchive-31333%40googlegroups.com

This email sent to webobjects-dev...@googlegroups.com

[Michael Gargano]

my guess is your session is timing out. for some reason the Ajax components produce that error instead. I've been wondering how to fix it myself.

-mike

Sent from my iPhone

On Jul 12, 2011, at 4:35 PM, "Ricardo J. Parada" <rpa...@mac.com> wrote:

> Hi All,
>
> 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 then finally clicks a DONE link to close the dialog. 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."
>
> Any ideas?
>
> Thanks,
> Ricardo
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobje...@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:

> http://lists.apple.com/mailman/options/webobjects-dev/mgargano%40me.com
>
> This email sent to mgar...@me.com

[Chuck Hill]

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?

> then finally clicks a DONE link to close the dialog.

Are all of these links and clicks Ajax actions?

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

The key to tracking this down is to know if it is the Ajax or the regular page cache that is missing the component.

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/

[Ricardo J. Parada]

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. :-)

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

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

_______________________________________________

[Chuck Hill]

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?

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

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

[Ricardo J. Parada]

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 Hill]

On Jul 12, 2011, at 4:29 PM, Ricardo J. Parada wrote:

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.

Those should be OK, they won't affect the page caches.

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.  :-/

Yeah, that is what I would expect too.

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.

What is the context ID shown in the browser's location URL?

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.

I'd be interested if you can reproduce it.  The only think that I can think of is that the Ajax code is getting confused and using the regular page cache.  But then I would expect to see calls to super.savePage.

The only other thing that I can think of is that the session is getting switched, but with the session in the URL that should not happen.

Chuck

-- 

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

[John & Kim Larson]

I thought your action methods had to be void methods for Ajax actions, otherwise this happens. ?

jal

Sent from my iPhone

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobje...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:

http://lists.apple.com/mailman/options/webobjects-dev/the_larsons%40mac.com

This email sent to the_l...@mac.com

[Chuck Hill]

They don't need to be, it is good style IMO to make them void if they don't need to return anything.

Chuck

> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>
> This email sent to ch...@global-village.net

--
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 (Webobje...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:

[Alexis Tual]

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

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobje...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:

http://lists.apple.com/mailman/options/webobjects-dev/alexis.tual%40gmail.com

This email sent to alexi...@gmail.com

[John & Kim Larson]

At some point shoulda's become needta's after you've done them that way enough I guess. :-/

Even if you were going from an ID of 22 to 8, things should be okay since that is within the bounds of the backtrack cache of 30 that your error is complaining about. Is it possible you've corrupted your page by changing some variable a la the classic repetition with a checkbox gotcha? I mean it seems like a page cache issue, but it also seems like of those "WebObjects is broken! ... No wait, I'm broken." issues.

John A. Larson
President
Precision Instruments, Inc.
Ph: 847-824-4194
Fax: 866-240-7104

Sent from my iPhone

[Ricardo J. Parada]

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.

[Ricardo J. Parada]

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.

http://lists.apple.com/mailman/options/webobjects-dev/rparada%40mac.com

This email sent to rpa...@mac.com

[Ricardo J. Parada]

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());

        }

...

[Chuck Hill]

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

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 (Webobje...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:

[Ricardo J. Parada]

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.

[Ricardo J. Parada]

It seems other people have ran into this same problem. It would be great if we can figure out what's going on.
So far I just know how to reproduce in 5 easy steps which is very important. But I still don't understand why it happens. :-/

On Jul 15, 2011, at 10: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>

[Ricardo J. Parada]

Here is an even simpler app:

[Chuck Hill]

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

[Ricardo J. Parada]

Try the second one I sent out... That one is simpler and easier to understand.

Thanks

[Michael Gargano]

was there ever a resolution to this. i'm encountering this problem a lot.

-mike

> http://lists.apple.com/mailman/options/webobjects-dev/mgargano%40escholar.com
>
> This email sent to mgar...@escholar.com

[Chuck Hill]

Still teetering on the top of my To Do list

[Michael Gargano]

*jumps up and down on chuck's list*

> http://lists.apple.com/mailman/options/webobjects-dev/mgargano%40me.com
>
> This email sent to mgar...@me.com

[Michael Gargano]

just to put it back on the list... turns out my problem was caused by a commented out (in html) AjaxModalContainer inside my AjaxModalDialog. the parser was still rendering the container code inside the comment. removing the comment made everything happy again. :)

-mike

[Ricardo J. Parada]

I sent out a little app to reproduce the problem in a few easy steps.

Setting the er.extensions.maxPageReplacementCacheSize property to something bigger than 30 definitely helps but you could still get the error if you reach the new limit. 

So I settled with a workaround that has the entire page refresh after closing the AjaxModalDialog (AMD) instead of updating an AjaxUpdateContainer (AUC).  

In my app, when the user clicked the SAVE button in my AMD, the component used to save changes and then close the AMD using AjaxModalDialog.close(context()) upon a successful save.  But because of this problem ("You backtracked too far") I changed it to refresh the page  as follows:

// This used to be: AjaxModalDialog.close(context());

// But because that was causing the "You backtracked too far" error after the user clicked

// on a link of the page right after closing the AMD after having clicked more than 30

// times in the dialog.  The code below refreshes the page and the AMD goes away.

AjaxUtils.redirectTo(page());

[Alexis Tual]

Yes same conclusion here, at some point you've got to refresh the whole page with a classic refresh to avoid these errors.

Anyway, for building ajax only application (one page, no full page refresh) I think client side js + ERREST should be the way to go.

Alex