the fix is in 1.4.x branch and will be part of 1.4.8. in the meantime you can build a fresh snapshot yourself and drop that into your application
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x -igor On Thu, Mar 18, 2010 at 3:27 PM, Nigel Parker <nigel.par...@mazeppa.no> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
