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

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


To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to