OFBiz多实例中JobManager的相关配置


OFBiz中的job相关的业务还是比较重要的,异步的service、eca已经任务计划都是通过这个来实现和调度的。

 

但是如果部署了2个OFBiz实例的话,就会出现冲突,每个实例都认为那些job是需要自己执行的,所以需要修改一些配置文件来达到这样的目的。

  • serviceengine.xml
    这个文件正在framework/service/config/serviceengine.xml,找到以下代码

<!-- Thread pool configuration (max/min threads, uses to live and time to live) -->
<thread-pool send-to-pool="pool"
    purge-job-days="4"
    failed-retry-min="3"
    ttl="18000000"
    wait-millis="750"
    jobs="10"
    min-threads="5"
    max-threads="15"
    poll-enabled="true"
    poll-db-millis="20000">
    <run-from-pool name="pool"/>
</thread-pool>
 

send-to-pool="pool"这里的pool改成其他名字,比如pool1、pool2,将run-from-pool name="pool"改成和上面一样的

  • general.properties
    这个文件在/framework/common/config/general.properties,将unique.instanceId=ofbiz1的值改成不一样的,比如2个实例分别叫做ofbiz1、ofbiz2

 

在上面的配置文件配置好以后,在配置定时任务的时候,pool这个输入框填写你想让哪个ofbiz实例去运行这个服务,如A服务让pool1运行,B服务让pool2运行

 

在serviceengine配置中,pool可以简单的理解为服务运行池,每个实例在任务调度的时候,run-from-pool这个属性的值会被读出来,所以每个实例只会去跑自己的服务,所以不会有冲突。

 

原先我以为 instanceId 是在job业务中是区分不同实例运行的标记,原来不是,通过以下代码来解读

//updateFields 是JobSandBox的字段,runByInstanceId=哪个实例跑的这个service,statusId=状态;SERVICE_QUEUED就是队列中
public static final Map<String, Object> updateFields = UtilMisc.<String, Object>toMap("runByInstanceId", instanceId, "statusId", "SERVICE_QUEUED");
List<EntityExpr> expressions = UtilMisc.toList(EntityCondition.makeCondition("runTime", EntityOperator.LESS_THAN_EQUAL_TO,
        UtilDateTime.nowTimestamp()), EntityCondition.makeCondition("startDateTime", EntityOperator.EQUALS, null),
        EntityCondition.makeCondition("cancelDateTime", EntityOperator.EQUALS, null),
       
//这里可以看到,只查询了runByInstanceId==null的任务
EntityCondition.makeCondition("runByInstanceId", EntityOperator.EQUALS, null));

// limit to just defined pools
List<String> pools = ServiceConfigUtil.getRunPools();
List<EntityExpr> poolsExpr = UtilMisc.toList(EntityCondition.makeCondition("poolId", EntityOperator.EQUALS, null));
//pools 是配置文件里面的run-from-pool,也就是读出来当前实例需要执行的任务
for (String poolName: pools) {
 poolsExpr.add(EntityCondition.makeCondition("poolId", EntityOperator.EQUALS, poolName));
}

// make the conditions
EntityCondition baseCondition = EntityCondition.makeCondition(expressions);
EntityCondition poolCondition = EntityCondition.makeCondition(poolsExpr, EntityOperator.OR);
EntityCondition mainCondition = EntityCondition.makeCondition(UtilMisc.toList(baseCondition, poolCondition));

// we will loop until we have no more to do
boolean pollDone = false;

while (!pollDone) {
    synchronized (this) {
        //将一些字段的值修改了,保存
        gator.storeByCondition("JobSandbox", updateFields, mainCondition);
        //重新读取一遍
        List<GenericValue> jobEnt = delegator.findByAnd("JobSandbox", updateFields, order);
       
    }
}

 

所以,这一小块的业务就是

  1. 用户定义一个service 由 哪个 pool 来执行

  2. 该 pool 通过 run-from-pool 这个来查询属于自己需要执行的service

  3. 在查询到任务之后,把 runByInstanceId 字段打上自己的 InstanceId ,表示这个任务已经被我认领,其他的实例不会再读取到这个任务了

 

大概业务就是这么多了,相关的代码在
framework/service/src/org/ofbiz/service/job/JobManager.java
framework/service/src/org/ofbiz/service/job/JobInvoker.java

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值