Instead of increasing the timeout, perhaps make sure that your users are sure that the request, which keeps blocking the page map, takes less than 1 minute. This can be done by using a work structure such as Quartz and sending it a job instead of doing heavy processing in your request listener. This way, your user will quickly receive a response, and your response time will be much better.
Timeout is a special protection from Wicket to prevent the occurrence of bad events. IMO should be done less, not increased. Unfortunately, many web applications have queries that make the user wait more than 10 seconds, so this will quickly become problematic. Using 1 minute is a reasonable compromise. AFAIK is not configurable.
Timeout is a solution for queries that take too much time to process and save the page map for a long period of time. Access to the page map is synchronized, so you - the developer - have a single prototype programming model with state preservation when working with your components, and not a (scary) multi-threaded, state-programmed programming model that has done so much work with servlets.
In short: do no harm to your users, use the job structure to process your long-running tasks, and download processing from your user interface.
An alternative solution would be to enable multi-window support if the timeout is triggered by a user with multiple tabs, open and using both. This will create several page maps, and each page map will have its own guard.
Martijn dashorst
source share