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

Reply via email to