[ https://issues.apache.org/jira/browse/WICKET-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vincent updated WICKET-2796: ---------------------------- Attachment: SessionTest.java Unittest with prh proof of concept > Error reporting on locked page maps, revisited > ---------------------------------------------- > > Key: WICKET-2796 > URL: https://issues.apache.org/jira/browse/WICKET-2796 > Project: Wicket > Issue Type: Improvement > Components: wicket > Affects Versions: 1.4.6 > Reporter: Vincent > Priority: Minor > Attachments: SessionTest.java > > > I'm creating this issue as suggested by Igor in the comments of the following > issue: WICKET-433. > The change done for WICKET-433 results in a quite large error message that > has the potential to flood log files when running under heavy load. The error > message includes a full stack of the thread that is currently locking the > page map. Usually, an exception is raised that includes a message and a cause > so the catcher can decide to log the complete stack or not. In this case, I'd > suggest the same: create an exception, set the stack trace of the thread > locking the page map on it, and throw a WicketRuntimeException with a message > and a cause. Something like: > {code} > StackTraceElement[] stackTrace = t.getStackTrace(); > WicketRuntimeException cause = new WicketRuntimeException("Thread is locking > page map."); > cause.setStackTrace(stackTrace); > throw new WicketRuntimeException("After " + timeout + " the Pagemap " + > pageMapName + " is > still locked by: " + t + > ", giving up trying to > get the page for path: " + path, > cause); > {code} > This issue was raised by one of the administrators on my project that was > trying to break the application by doing a manual load and stress test (read: > disabling javascript and submitting requests like a maniac). Since our > application integrates with a web service that can take up quite some time, > up to 5 seconds, a queue starts to build up because Wicket allows only one > request per user to be executed because the page map is locked. While this is > a great design decision in my opinion (low impact for other users), after a > minute threads that are still waiting will start to abort. As quite a queue > had been built up at this point and each waiting thread throws an exception > with a quite verbose message (the blocking thread's stack), quite some lines > will be written to the log at this time - probably on error level. > Johan comments: > {quote} > how can a malicious user lock pages/pagemaps so create those kind of errors? > These errors are more or less programming/web application errors that you > need to fix > {quote} > Of course, you are right. This is a serious error that should never occur in > a properly tuned production environment. In production, the webservice should > respond much quicker and is viable for client-side caching, which we will > address in future iterations. > Our administrator's concern is that IF a user manages to build up a queue > long enough to trigger this error (whatever the cause), he will face a 'log > storm' that makes him effectively blind. This is the reason that stack traces > on error level are not allowed in our production environment. Of course, this > will only be a serious problem under very very heavy load. > Well enough with the theoretical mumbo-jumbo, do you like the idea? Shall I > cook up a proof of concept? And if successful, build a patch for this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.