Thank you Johan for your reply. Agree that original problem should be fixed. This is a critical problem for us. We have found out during the last 24 hours that some of our pages are retaining a session reference. With Ajax requests this gives a doubling of session size for every request, and we now believe this to be the cause of the StackOverflowErrors. We will try this in production tomorrow.
We upgraded to to 1.4.7 but still see that the pagemap is locked when the stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7? Thanks Nigel Johan Compagner wrote: > > i fixed 2075 so that it should always unlock the pages. > > Problem is that you still could get weird errors because that page is not > in > a valid state in the session. > So if back buttons/page versions are used it could be that that doesnt > work > > So what should be fixed is the original problem > > > > On Wed, Mar 17, 2010 at 21:03, Nigel Parker <nigel.par...@mazeppa.no> > wrote: > >> We are a Wicket shop and for one of our clients have been running a >> Wicket application successfully for over 2 years. We are now at >> version 1.4.0. The traffic on the system is increasing and we are now >> seeing an increased frequency of pagemap locking which is beginning to >> be a serious problem for the users. By subclassing WebRequestCycle we >> have identified that a StackOverflowError under serialization in >> RequestCycle.detach() leaves the pagemap locked for the next minute. >> If our analysis is correct this is essentially the problem reported as >> https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we >> cannot reproduce the problem in our test environment and it occurs >> only in about one in every thousand requests with no apparent >> consistent pattern about what the user has been doing. Can anybody >> suggest an immediate strategy for further investigations? In >> particular: >> >> - is there a practical way to find out what is causing the >> serialization problem. The stack trace is no help. We do in many cases >> have large amounts of data in the session, but doubling the default >> stack size leaves the problem frequency unchanged leading us to >> suspect a logical error rather the sheer amount of data. >> >> - by overriding RequestCycle.detach() and catching the >> StackOverflowError we can get control when the error occurs. Is there >> any way we can persuade Wicket to release the pagemap lock? I have >> looked at the code and this doesn't look straightforward. >> >> - can we get Wicket itself to suppress the StackOverflowError so that >> detach() continues and releases the lock? >> >> Grateful for any suggestions. >> >> Nigel >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > -- View this message in context: http://old.nabble.com/StackOverflowError-under-serialization-leaves-pagemap-locked-tp27938028p27950858.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
