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
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.
