Hello, This is real-life story. It started a relatively long time ago: our demo server from time to time had OurOfMemory condition. It was strange because the solution itself is very well "stress volume tested". So we were just rebooting demo server after such incidents. But it started to happen more frequently and we performed an investigation with interesting results which can be used as Best Practice and/or one more issue for Wicket.
1) We have found that most memory-consuming objects where java Threads. Specifically for InspectorPage from Wicket devutils. 2) Our applications pages don't have memory leakage condition. But there is one trick: some of our pages are built dynamically and depends on a data model. Sometimes data model might be recurrent, so without special treatment - Wicket will render that forever. We have this protection on our pages, but that was a main root-cause component: InspectorPage during inspecting of our pages for some reason doesn't see that actually recurrent elements are cut during rendering. 3) But how someone gets into InspectorPage? Apparently that was Google - it was trying to index our demo site and there is no protection from following to InspectorPage in DevUtils panel. So, some lessons learned items and comments: 1) If it's possible - do not deploy DevUtils - use them during actual development. 2) It will be good to investigate InspectorPage - why it's trying to build structure infinitely disregard of the fact that on real page it's actually cut off. 3) It might make sense to include such utils and etc into /robots.txt to protect from indexing 4) Also, it might make sense to add "nofollow" to a link in DevUtils panel which leads to InspectorPage Thanks, Ilia --------------------------------------------- Orienteer(http://orienteer.org) - open source Business Application Platform --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
