[ https://issues.apache.org/jira/browse/WICKET-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849186#action_12849186 ]
Vincent commented on WICKET-2796: --------------------------------- Ok, did a proof of concept. See the attached unittest, which fails, but does print two stacktraces we can compare :) Original stacktrace: org.apache.wicket.WicketRuntimeException: After 1 second the Pagemap null is still locked by: Thread[Thread-2,5,main], giving up trying to get the page for path: form Begin of stack trace of Thread[Thread-2,5,main] java.lang.Thread.sleep(Native Method) java.lang.Thread.sleep(Thread.java:850) org.apache.wicket.SessionTest$1.run(SessionTest.java:16) java.lang.Thread.run(Thread.java:735) End of stack trace of Thread[Thread-2,5,main] at org.apache.wicket.SessionTest.test(SessionTest.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Patched stacktrace. org.apache.wicket.WicketRuntimeException: org.apache.wicket.WicketRuntimeException: After 1 second the Pagemap null is still locked by: Thread[Thread-3,5,main], giving up trying to get the page for path: form at org.apache.wicket.SessionTest.test2(SessionTest.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.apache.wicket.WicketRuntimeException: After 1 second the Pagemap null is still locked by: Thread[Thread-3,5,main], giving up trying to get the page for path: form at java.lang.Thread.sleep(Native Method) at java.lang.Thread.sleep(Thread.java:850) at org.apache.wicket.SessionTest$2.run(SessionTest.java:56) at java.lang.Thread.run(Thread.java:735) I like the patched stacktrace. It's more readable that the first imho. What do you think? > 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.