Great! That means I don't have to waste time tracking down non-existent timeouts & can focus elsewhere. Thanks for the quick feedback.
From: Martin Grigorov <mgrigo...@apache.org> To: users@wicket.apache.org Date: 07/26/2012 09:56 AM Subject: Re: Ajax Timeouts On Thu, Jul 26, 2012 at 5:50 PM, Richard W. Adams <rwada...@up.com> wrote: > Yes, it is my code. My server code will eventually reply. What I can't > control is how long a database operation will take. Typically the database > work finishes under 10 seconds, but sometimes can run up to a minute or > longer. > > If I understand you correctly, even if takes 5 minutes (an extreme > example), the client will still patiently wait until it gest the reply, > correct? To say it another way: As long as the server code eventually > replies (in less than the session timeout, which is currently 60 minutes, > I think), the client will still get the reply. Is that accurate? If so, > then my problem is probably something other than an Ajax timeout. Yes, the Ajax call will wait. In that timeframe no other request can access the same page instance too. Wicket 6 supports Ajax call timeout by org.apache.wicket.ajax.attributes.AjaxRequestAttributes#setRequestTimeout(). It just delegates to jQuery#ajax()'s timeout mechanism. I haven't tried it with your use case though. > > > > > From: Martin Grigorov <mgrigo...@apache.org> > To: users@wicket.apache.org > Date: 07/26/2012 09:41 AM > Subject: Re: Ajax Timeouts > > > > On Thu, Jul 26, 2012 at 5:35 PM, Richard W. Adams <rwada...@up.com> wrote: >> So once the client request gets access to the page instance, it will > wait >> forever for a reply? > > this is your code, no ? > > once the Ajax call gets access to the page Wicket executes > onEvent(AjaxRequestTarget). Here it is your job to not block forever > >> >> >> >> >> From: Martin Grigorov <mgrigo...@apache.org> >> To: users@wicket.apache.org >> Date: 07/26/2012 09:27 AM >> Subject: Re: Ajax Timeouts >> >> >> >> Hi, >> >> The timeout is to get access to the page instance. It is for both Ajax >> and normal requests. >> See org.apache.wicket.settings.IRequestCycleSettings#getTimeout >> >> You must have some exceptions in the logs if this is the reason. >> >> But even if Ajax request fails to get access to the page then it will >> end by calling its failure handler. >> >> On Wed, Jul 25, 2012 at 7:50 PM, Richard W. Adams <rwada...@up.com> > wrote: >>> My Wicket app occasionally "freezes" on making an Ajax submit that >> invokes >>> a potentially lengthy database operation. My theory is that the > database >>> work is taking longer than Wicket allows, & the Ajax call times out. > I'm >>> guessing that the browser does not detect this timeout, so my "Please >>> Wait" message continues to be displayed, making the user think he will >>> eventually get an answer from the server. However, in these cases, no >>> matter long he waits (up to many minutes), no reply is ever > forthcoming. >>> >>> Before I invest a lot of time trying to FIX this problem, is there a > way >>> to determine that an Ajax timeout actually IS the problem? Also, does >>> anyone know what Wicket's default Ajax timeout interval is? >>> >>> I looked over the Javadocs for the various Wicket Ajax classes, but > none >>> of them seemed to address this particular issue. Any advice or pointers >>> would be greatly appreciated! >>> >>> >>> >>> >>> >>> ** >>> >>> This email and any attachments may contain information that is >> confidential and/or privileged for the sole use of the intended > recipient. >> Any use, review, disclosure, copying, distribution or reliance by > others, >> and any forwarding of this email or its contents, without the express >> permission of the sender is strictly prohibited by law. If you are not >> the intended recipient, please contact the sender immediately, delete > the >> e-mail and destroy all copies. >>> ** >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> ** >> >> This email and any attachments may contain information that is > confidential and/or privileged for the sole use of the intended recipient. > Any use, review, disclosure, copying, distribution or reliance by others, > and any forwarding of this email or its contents, without the express > permission of the sender is strictly prohibited by law. If you are not > the intended recipient, please contact the sender immediately, delete the > e-mail and destroy all copies. >> ** > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > ** > > This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. > ** -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. **
