我的问题的背景信息： 我有一个不寻常的用例，我在旧版本的web2py和较新的（最近的）版本上运行两个不同的（但相关的）应用程序。
例如
“新服务器”（与Ubuntu一起运行的EC2实例），它运行Web应用程序和与web2py版本上的Web应用程序相关的独立调度程序 2.14.6稳定+ timestamp.2016.05.10.00.21.47 （在Apache / 2.4.18（Ubuntu），Python 2.7.12上运行）
“旧服务器”（与Ubuntu一起运行的EC2实例），它运行Web应用程序和与web2py版本上的Web应用程序相关的独立调度程序 2.9.5稳定+ timestamp.2014.03.16.02.35.39 （在Apache / 2.4.7（Ubuntu），Python 2.7.6上运行）
最初这两个应用程序位于“旧”服务器上，我所做的是将其中一个应用程序迁移到更新的服务器。中长期旧服务器将升级并投入使用，但出于风险规避和短期优先级的原因，我要求这两个不同版本“共存”，因为它们指向相同的数据库基础架构（postgres RDS实例）
这两个应用程序具有相关的独立胶子调度程序，当它们位于相同的“旧”服务器上时，运行状态超过一年。在将其中一个调度程序进程迁移到较新的服务器之后，为了与关联的Web应用程序共处一地，我遇到了web2py调度程序的问题（主要表现在旧版本中）。显而易见的问题通常是旧版本独立调度程序将停止运行，实际上是锁定。
我发现对每个独立调度程序关联的任务集使用不同的组名有助于系统在与新胶子调度程序中的所需修改一起完成时起作用以阻止它从检查“属于”“旧”服务器版本的工作者。这是因为新的scheduler_worker中添加了一个名为“worker_stats”的列，该列未被“旧版”旧胶子调度程序版本填充。
以下差异输出描述了新行为的“修复/黑客”：
@@ -1083,7 +1081,7 @@ class Scheduler(MetaScheduler):
"""
sw, st, sd = db.scheduler_worker, db.scheduler_task, db.scheduler_task_deps
now = self.now()
- all_workers = db((sw.status == ACTIVE) & (sw.group_names == "|myNewGroupName|")).select()
+ all_workers = db(sw.status == ACTIVE).select()
# build workers as dict of groups
wkgroups = {}
for w in all_workers:
注意：我还确保旧的调度程序使用group_name“myOldGroupName”运行...这似乎是必要的，以确保没有锁定（最初我将旧的默认为“主”...但我怀疑这也导致冲突
初步请求社群反馈（可能随后我自己进一步阐述并提供技术细节，待决回复和任何此类请求）：
胶子调度器应该完全向后兼容吗？
当胶子调度程序需要使用相同的数据库表实时与另一个“版本”“共存”时，它是否向后兼容？
混合在同一共享数据库表上运行的新旧web2py版本是否“安全”？
注意：我可以确认到目前为止所做的所有操作，即使计划已开始并运行几个小时，它似乎最终会停止所有任务，不会让任务能够运行并且所有任务都处于排队状态。好像整个调度程序机制被锁定在两个服务器上独立的调度程序实例（即使理论上任务和相关工作程序是不相关的（？或者它们是什么？）