确定 Tomcat 上多个 Web 应用程序的 Quartz 设置
我有一个具有多个 Tomcat 实例的服务器，每个实例包含大约 10 个应用程序上下文。我正在考虑使用 Quartz 来满足我们当前收到的一些调度要求。
我首先认为一个 Quartz 服务器运行并为每个实例的所有调度请求提供服务是最好的，但是似乎大多数用户指南都将 Quartz 与每个应用程序捆绑在一起。
我的调度程序必须在不同的数据库上针对不同的上下文运行作业。
有没有人有类似的设置？谁能推荐如何在多实例、多上下文设置中有效地使用 Quartz？将单独的调度程序与每个 Web 应用程序捆绑在一起是否会显着增加我需要的硬件资源？有什么一般建议吗？
谢谢。
I have a server with multiple Tomcat instances and each contains about 10 application contexts. I am considering using Quartz for some scheduling requirements we currently received.
I first thought that one Quartz server running and servicing all of the scheduling requests for each instance would be best, however it seems that most of the user guides bundle Quartz with each application.
My scheduler will have to run jobs on different databases for different contexts.
Does anyone out there have a similar set up? Can anyone recommend how to use Quartz efficiently in the multiple instance, multiple context set up? Will bundling a separate scheduler with each web app significantly increase the hardware resources I will need? Any general advice?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们执行了以下操作：
对于每个上下文，我们创建了一个 Web 服务来公开我们想要执行的功能。
我们使用 tomcat 的另一个实例来托管quartz 服务器。我们查看了 Quartz 提供的命令行服务器，它运行良好。我们只是想让我们的服务器管理员有一种简单的方法来启动/停止服务器并在崩溃时进行自动恢复等。他们习惯于使用 Tomcat 来执行此操作，因此我们选择使用 tomcat 来启动 Quartz。
在每个上下文中，我们将quartz客户端配置为使用RMI来创建触发器和作业。在作业详细信息中，我们包含了 Web 服务 URL，以便调度程序知道在哪个上下文上执行作业。
We did the following:
For each context we created a web service that exposes the functionality we want to execute.
We used another instance of tomcat to host the quartz server. We looked at the command line server provided by Quartz and it worked well. We just wanted an easy way for our server admin to start/stop the server and do automatic recovery on crash etc. They are used to doing that with Tomcat so we opted to use tomcat to start Quartz.
In each context we configured the quartz client to use RMI to create Triggers and Jobs. In the job details we included the web service url so the scheduler knows which context to execute the Job on.