工作管理器线程约束且页面无法显示
我们对某些功能进行内存密集型处理，并且我们希望限制对此处理的并行请求数量。我们可以使用 WebLogic 中的“工作管理器”进行配置，并限制该 servlet 的线程数量。
例如，如果我们将最大线程限制设置为3，那么如果有10个并行请求； 7 个请求正在排队。在某些情况下，队列中等待的请求可能需要长达 30-40 分钟才能得到处理。我们做了简单的测试，15分钟后收到的页面因超时无法显示，1小时后收到消息。
有谁知道WebLogic中是否有一项设置可以增加/减少超时并避免页面无法显示？
感谢任何人对此有任何想法。
We have a memory intensive processing for certain functionality and we would like to limit the number of parallel requests to this processing. We are able to configure by using "Work Managers" in WebLogic and putting a limit on the number of threads for that servlet.
For example, if we put maximim thread limit as 3, then if there are 10 parallel requests; 7 requests are in queue. There could be situations where these the requests waiting in queue could take up to 30-40 minutes to be processed. We did simple testing and the received page cannot be displayed due to timeout after 15 mins and received the message after 1 hour.
Does any one know if there is a setting in WebLogic to increase/decrease timeout and avoid page cannot be displayed?
Appreciate if any one has any thoughts around this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可能有一些东西，但我实际上没有检查，因为无论如何这都是一个坏建议。通过寻找这个，你正在试图解决这里错误的问题。即使您不介意用户等待（更不用说他可以刷新页面并排队越来越多的作业），浏览器也不适合像您所描述的那样长时间运行的进程（> 3000万）。
所以，我认为正确的答案是：使用异步，这是完美的用例。当用户单击按钮时，将 JMS 消息发送到队列（或创建 Quartz 作业）并向用户发送带有请求 ID 的页面，告诉他稍后再回来。处理完成后，在某处更新状态并使状态/结果可供用户使用。事实上，与使用浏览器相比，这样做的用户体验会更好，而且您遇到的问题也会更少。
There might be something but I actually didn't check as it would be a bad advice anyway. By looking for this, you are trying to solve the wrong problem here. A browser is just not made for long-running process like the one you are describing (>30mn) even if you don't mind the user waiting (not mentioning that he could refresh the page and queue more and more jobs).
So, the right answer here is in my opinion: use asynchronism, this is the perfect use case. When the user clicks on the button, send a JMS message to a queue (or create a Quartz job) and send the user a page with a request ID telling him to come back later. When the processing is done, update the status somewhere and make the status/result available to the user. Really, the user experience will be better doing this and you'll face less problems than with a browser.
1）使用其他工具（不是浏览器），例如 WGET，您可以在其中控制超时参数（--timeout）。
2）为什么使用HTTP？使用消息驱动 bean 并向其发送消息 JMS，并且不关心超时。
1) Use some other tool (not browser) like WGET where you can control timeout parameter (--timeout).
2) Why do you use HTTP? Use message driven beans and send message JMS to that and don't care about time outs.
也许石英可以满足您的需求？开始一份工作并根据需要检查它？
Perhaps quartz can do what you need? Start a job and check in on it as you need to?