增加“1 分钟后，Pagemap null 仍被锁定”的锁定时间例外
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.WicketRuntimeException:
After 1 minute the Pagemap null is still locked by:
Thread[http-8443-3,5,main], giving up trying to get the page for path: 3:timer
这个1分钟的设定在哪里？是检票口设置，还是雄猫？或者 ...？ 我该如何修改这个？
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.WicketRuntimeException:
After 1 minute the Pagemap null is still locked by:
Thread[http-8443-3,5,main], giving up trying to get the page for path: 3:timer
Where is this 1 minute set? Is a wicket setting, or a tomcat? or ...?
How can I modify this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
虽然我同意 Martijn 的回答（你不应该让用户等待超过一分钟），但可以通过调用
WebApplication.getRequestCycleSettings().setTimeout()< /code>在您的应用程序对象上。将其设置为 3 分钟的示例：
Although I agree with Martijn's answer (you shouldn't keep users waiting for more than a minute), the timeout can be set by calling
WebApplication.getRequestCycleSettings().setTimeout()on your application object.Example to set it to 3 Minutes:
为了用户的理智，可以确保保持页面映射锁定的请求花费的时间少于 1 分钟，而不是增加超时。这可以通过使用像 Quartz 这样的作业框架并向其提交作业来完成，而不是在请求侦听器中进行繁重的处理。这样您的用户就能快速得到答案，您的响应时间也会缩短很多。
暂停是 Wicket 特有的保护措施，旨在防止不良事件发生。 IMO应该减少而不是增加。不幸的是，许多 Web 应用程序的请求会让用户等待超过 10 秒，因此很快就会出现问题。使用 1 分钟是一个明智的妥协。 AFAIK 它是不可配置的。
超时是针对处理时间过长的请求以及长时间保持页面映射锁定的解决方案。对页面映射的访问是同步的，因此您（开发人员）在使用组件时拥有单线程、有状态的编程模型，而不是（可怕的）多线程、有状态的编程模型，而多线程、有状态的编程模型使使用 servlet 变得非常有趣。
简而言之：不要伤害您的用户，使用作业框架来处理长时间运行的任务并从 UI 中卸载处理。
如果超时是由于用户打开多个选项卡并同时使用这两个选项卡而导致的，则另一种解决方案是启用多窗口支持。这将创建多个页面地图，每个页面地图都有自己的守卫。
Instead of increasing the timeout perhaps ensure for the sanity of your users that the request keeping the page map lock takes less than 1 minute. This can be done by using a job framework like Quartz and submitting a job to it instead of doing the heavy processing in your request listener. This way your user gets an answer quickly and your response times will be much better.
The timeout is a Wicket specific safeguard to prevent bad things from happening. IMO it should be made less rather than increased. Unfortunately many web applications have requests that keep a user waiting for over 10 seconds, so that would become problematic quickly. Using 1 minute is a sensible compromise. AFAIK it is not configurable.
The timeout is a solution for requests that take too long to process, and keeping the page map locked for an extended period of time. Access to the page map is synchronized so that you—the developer—have a single threaded, stateful programming model when working with your components instead of the (dreaded) multithreaded, stateful programming model that made working with servlets so much fun.
In short: don't harm your users, use a job framework to process your long running tasks and offload the processing from your UI.
An alternative solution would be to enable multi window support if the time out is caused by a user having multiple tabs open and using both. This will create multiple page maps and each page map has its own guard.