Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-2796

Improve error reporting on locked page maps



    • Improvement
    • Status: Resolved
    • Minor
    • Resolution: Fixed
    • 1.4.6
    • 1.4.8
    • wicket
    • None


      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:

      StackTraceElement[] stackTrace = t.getStackTrace();
      WicketRuntimeException cause = new WicketRuntimeException("Thread is locking page map.");
      throw new WicketRuntimeException("After " + timeout + " the Pagemap " +
       							pageMapName + " is still locked by: " + t +
       							", giving up trying to get the page for path: " + path,

      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:

      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

      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?


        1. SessionTest.java
          2 kB

        Issue Links



              ivaynberg Igor Vaynberg
              vin Vincent
              1 Vote for this issue
              1 Start watching this issue