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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
