Hello everyone,

I am the founder of Elastic-Job, the project is established by dangdang.com. I have no time to develop Elastic-Job and maintain the community during recent 3 years.

Currently, we need a distribute scheduler framework to process data migration of Apache ShardingSphere(https://github.com/apache/shardingsphere), I am VP of Apache ShardingSphere too. I want start a discussion about donate elastic-job as a subproject of Apache ShardingSphere.

The benefits are:

1. Apache ShardingSphere is an active community, there are more contributors to deal with Elastic-Job.
2. We can continuous develop more features of Elastic-Job.

The challenge for current community is:

1. All issue and pull request need change to English.

Please give some advice. If no suitable reason to reject, I will try to ask dangdang.com provide SGA for donation and start to write the proposal.

Welcome give me some feedback, thank you very much.

There is a problem with elasitcjob 3. X. I have two nodes for task scheduling service. The first node starts normally, and the second node reports job conflict with register center exception. What is the reason?

Please answer these questions before submitting your issue. Thanks! 开源不易，我们希望将精力放在完成新功能和解决有价值的问题上，为了让大家的配合更具有效率，请填写以下列出的全部问题

Which version of Elastic-Job do you using?（您使用的Elastic-Job版本为？） elastic-job-lite：2.1.5 Expected behavior （您预期的结果是） 如何把ReconcileService和Curator-TreeCache 线程数稳定住，现在一直在增加 Actual behavior （实际运行的结果是） 每天这两个线程大概增加一倍的数量 Steps to reproduce the behavior （可重现问题的操作步骤）

1.手工创建任务 new SpringJobScheduler(elasticJob, regCenter, liteJobConfiguration, jobEventRdbConfiguration, elasticJobListeners).init(); 2.手工删除任务 JobRegistry.getInstance().shutdown(jobName); //清除对象和zookepper缓存 regCenter.remove("/" + jobName); //清除目录

1. 提供接口触发elasticjob任务，然后延迟30s执行
2. 实时触发的时候实际是修改定时任务的cron的值
3. 但是发现"ReconcileService" prio=5 os_prio=0 tid=0x00007f9330386800 nid=0x2dae1 waiting on condition [0x00007f9220ad1000] 和"Curator-TreeCache-2" daemon prio=5 os_prio=0 tid=0x00007f94f0010800 nid=0x29a6f waiting on condition [0x00007f93196dd000] 线程数一直在增加. 其实我们的定时任务只有10个，每天就是修改这10个任务的相应执行实际；
4. 不知道这样使用是否有什么问题？ 以前我们是要实现实时任务就是新增定时任务，就是延迟1min来执行，但是这样会产生大量的任务；线程数同样也是没法控制住；最终我们采用修改时间的办法来实现，发现这两个线程的数量是一致的.

Please provide the reproduce example codes (such as github link)，otherwise we will label the issue as Invalid and close it.（为了节省复现问题的时间，请务必提供可重现的代码，否则我们会将issue直接标记为invalid并关闭） Code should based on https://github.com/elasticjob/elastic-job-example （代码请基于 https://github.com/elasticjob/elastic-job-example）

试了各种办法模拟失效转移都不成功，仔细研究了源码，发现源码中有个小bug。 `class JobCrashedJobListener extends AbstractJobListener {

    @Override
    protected void dataChanged(final String path, final Type eventType, final String data) {
        if (isFailoverEnabled() && Type.NODE_REMOVED == eventType && instanceNode.isInstancePath(path)) {
            String jobInstanceId = path.substring(instanceNode.getInstanceFullPath().length() + 1);
            if (jobInstanceId.equals(JobRegistry.getInstance().getJobInstance(jobName).getJobInstanceId())) {
                return;
            }
            List<Integer> failoverItems = failoverService.getFailoverItems(jobInstanceId);
            if (!failoverItems.isEmpty()) {
                for (int each : failoverItems) {
                    failoverService.setCrashedFailoverFlag(each);
                    failoverService.failoverIfNecessary();
                }
            } else {
                for (int each : shardingService.getShardingItems(jobInstanceId)) {
                    failoverService.setCrashedFailoverFlag(each);
                    failoverService.failoverIfNecessary();
                }
            }
        }
    }
}`

失效转移是从这个监听器开始的，当zookeeper上有服务器节点被Removed时，触发监听，查询该服务器被分配的任务项 public List<Integer> getShardingItems(final String jobInstanceId) { JobInstance jobInstance = new JobInstance(jobInstanceId); if (!serverService.isAvailableServer(jobInstance.getIp())) { return Collections.emptyList(); } List<Integer> result = new LinkedList<>(); int shardingTotalCount = configService.load(true).getTypeConfig().getCoreConfig().getShardingTotalCount(); for (int i = 0; i < shardingTotalCount; i++) { if (jobInstance.getJobInstanceId().equals(jobNodeStorage.getJobNodeData(ShardingNode.getInstanceNode(i)))) { result.add(i); } } return result; } 在查询宕机服务器分配的任务项时，先判断该服务器是否可用，如果可用，才继续查询 `public boolean isAvailableServer(final String ip) { return isEnableServer(ip) && hasOnlineInstances(ip); }

private boolean hasOnlineInstances(final String ip) {
    for (String each : jobNodeStorage.getJobNodeChildrenKeys(InstanceNode.ROOT)) {
        if (each.startsWith(ip)) {
            return true;
        }
    }
    return false;
}`

判断服务器节点是否可用的方法如上，如果服务器节点存在，认为可用，这与上面失效转移监听被触发的条件（服务器节点被removed）相矛盾

Please answer these questions before submitting your issue. Thanks!

Which version of Elastic-Job do you using?

2.0.5

Expected behavior

启动task后，在Job平台上点击触发，触发任务执行，执行完后，下一次任务按schedule设定的time触发下一次执行。

Actual behavior

启动task后，在Job平台上点击触发，触发任务执行，执行完后，没到配置的时间，立即开始了下一次的执行。两次执行完后，Job停止执行。

Steps to reproduce the behavior

任务schedule的CRON：0 * 12 10 * ? 第一次执行完的时间：01/11 22:50:14.142 第二次开始执行的时间：01/11 22:50:14.163

Please provide the reproduce example codes (such as github link) if possible.

作业的xml配置：

<!--配置作业注册中心 -->
    <reg:zookeeper id="regCenter" server-lists="#{systemEnvironment.JAVA_ZOOKEEPER_HOST}"
                   namespace="task/dsp-ps-dts" base-sleep-time-milliseconds="1000"
                   max-sleep-time-milliseconds="3000" max-retries="3"/>

<job:simple id="adtsJobA" class="dsp.ps.dts.task.job.DtsJobA" registry-center-ref="regCenter"
                cron="0 * 12 10 * ?" sharding-total-count="1" description="数据迁移任务A"/>

Job平台上： 支持自动失效转移 未勾选 支持misfire 已勾选

以下为生产的线程镜像： `"order-autoconfirmreceive-job-0ff1c802d8df43dca22c251cd159d0d0_QuartzSchedulerThread" #6964 prio=5 os_prio=0 tid=0x00007f375dd9a800 nid=0x8a3f in Object.wait() [0x00007f36033c2000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.quartz.simpl.SimpleThreadPool.blockForAvailableThreads(SimpleThreadPool.java:452) - locked <0x00000000c7d59588> (a java.lang.Object) at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:263)

"order-autoconfirmreceive-job-0ff1c802d8df43dca22c251cd159d0d0_Worker-1" #6963 prio=5 os_prio=0 tid=0x00007f375dd98800 nid=0x8a3e waiting on condition [0x00007f36034c3000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at com.dangdang.ddframe.job.util.concurrent.BlockUtils.sleep(BlockUtils.java:32) at com.dangdang.ddframe.job.util.concurrent.BlockUtils.waitingShortTime(BlockUtils.java:27) at com.dangdang.ddframe.job.lite.internal.sharding.ShardingService.blockUntilShardingCompleted(ShardingService.java:125) at com.dangdang.ddframe.job.lite.internal.sharding.ShardingService.shardingIfNecessary(ShardingService.java:108) at com.dangdang.ddframe.job.lite.internal.schedule.LiteJobFacade.getShardingContexts(LiteJobFacade.java:115) at com.dangdang.ddframe.job.executor.AbstractElasticJobExecutor.execute(AbstractElasticJobExecutor.java:103) at com.dangdang.ddframe.job.lite.internal.schedule.LiteJob.execute(LiteJob.java:26) at org.quartz.core.JobRunShell.run(JobRunShell.java:202) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) - locked <0x00000000c7d59880> (a java.lang.Object) `

这种任务无需sharding， 但是被block，一旦修改里面其对于zk的某个的属性值，对应目录就会消失掉，但是任务没执行。。

例如： set /elastic-job-lite/order-autoconfirmreceive-job-0ff1c802d8df43dca22c251cd159d0d0/leader/election/instance 10.72.27.53@-@86594

求助有没解决办法。正在研习源代码中

I have one job named “cronJob” running on two servers。I found that three sharding items was stuck at the moment，I manually triggered the job，then sharding item 0、2 started to run as the cron principle，but sharding item 1 was still stuck。The dumped information is below：

/cronJob/sharding | /cronJob/sharding/2 | /cronJob/sharding/2/running | /cronJob/sharding/2/instance | ip1@-@102156 /cronJob/sharding/1 | /cronJob/sharding/1/instance | ip2@-@165035 /cronJob/sharding/0 | /cronJob/sharding/0/running | /cronJob/sharding/0/instance | ip1@-@102156 /cronJob/servers | /cronJob/servers/ip1 | ENABLED /cronJob/servers/ip2 | ENABLED /cronJob/leader | /cronJob/leader/sharding | /cronJob/leader/failover | /cronJob/leader/failover/items | /cronJob/leader/election | /cronJob/leader/election/instance | ip1@-@102156 /cronJob/instances | /cronJob/instances/ip1@-@102156 | /cronJob/instances/ip2@-@165035 | /cronJob/config | cron: 0/10 * * * * ? description: '' disabled: false failover: true jobErrorHandlerType: '' jobExecutorServiceHandlerType: '' jobName: cronJob jobParameter: 0=Beijing1,1=Shanghai,2=Guangzhou,3=Guangzhou jobShardingStrategyType: '' maxTimeDiffSeconds: -1 misfire: true monitorExecution: true overwrite: true reconcileIntervalMinutes: -1 shardingItemParameters: 0=Beijing,1=Shanghai,2=Guangzhou,3=Guangzhou shardingTotalCount: 3

Fixes #1720 .

Changes proposed in this pull request: Detect System Property "jobInstanceId", if it is exists, use IP concat with this property instead of jvm name.

Which version of Elastic-Job do you using?（您使用的Elastic-Job版本为？）

2.1.5

Expected behavior （您预期的结果是）

任务不要重复执行

Actual behavior （实际运行的结果是）

任务重复执行

Steps to reproduce the behavior （可重现问题的操作步骤）

3个节点 1分钟执行一次任务。0 * * * * ? 场景一、 在 25秒的时候， kill掉其中一个节点， 这个节点的任务会迅速被其它节点获取并立即执行。 （备注： 假设修复了https://github.com/elasticjob/elastic-job-lite/issues/669 这个bug） 在下一个分钟的0秒的时候，重新分片，全部分片执行。

那么这次失效转移的分片 不就是提前重复执行了一次吗？

场景二、 存活的节点每抢占一个分片，都会触发jobScheduleController.triggerJob()， 但是job在执行的时候，是批量获取的failover分片啊

    @Override
    public ShardingContexts getShardingContexts() {
        boolean isFailover = configService.load(true).isFailover();
        if (isFailover) {
            **List<Integer> failoverShardingItems** = failoverService.getLocalFailoverItems();
            if (!failoverShardingItems.isEmpty()) {
                return executionContextService.getJobShardingContext(failoverShardingItems);
            }
        }

那么触发的job执行次数就是过剩的，最后剩下的job 就会执行分片操作，并执行属于本节点的分片任务。 重复执行。

ZookeeperRegistryCenter#init第100行、101行，这里实际上采用的异步方式发起连接，但在本机（4核8线程）上测试时发现，ConnectionStateManager状态改变后立刻返回，几乎不可能出现线程切换，在101行对客户端连接状态的判断实际上取得仍然是未连接状态。既然是初始化，这里为何要采用异步连接？既然是异步连接为何在返回后立刻取值判断？线程没有切换之前，获取的值肯定是未连接状态。这里的处理逻辑是否有问题还请看看！

Bug Report

I use elasticjob with spring-boot, datasource config correctly, while I cannot get any job trace data and job history data.

Which version of ElasticJob did you use?

3.0.0-beta

Which project did you use? ElasticJob-Lite or ElasticJob-Cloud?

ElasticJob-Lite

Expected behavior

Can see job trance and history in ui console at: http://localhost:8088/#/history-trace

Actual behavior

Empty table

Reason analyze (If you can)

JobScheduler.findTracingConfiguration() returns empty result.

Steps to reproduce the behavior.

Use the official example, "elasticjob-example-lite-springboot“, datasource as:

spring:
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:tcp://localhost/~/test
    username: sa
    password: 

Example codes for reproduce this issue (such as a github link).

I want to run a demo for Elastic-Job, when i add elastic-job-springboot-starter dependence,it does not work, if remove it that is work normal.

version

• SpringBoot 2.3.3
• Mybatis SpringBoot Starter 2.2.2
• elastic-job springBoot Starter 3.0.2

this is my pom file

`

	<dependency>
		<groupId>org.projectlombok</groupId>
		<artifactId>lombok</artifactId>
		<optional>true</optional>
	</dependency>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-web</artifactId>
	</dependency>

	<dependency>
		<groupId>org.apache.shardingsphere.elasticjob</groupId>
		<artifactId>elasticjob-lite-spring-boot-starter</artifactId>
		<version>3.0.2</version>
	</dependency>

	<!-- https://mvnrepository.com/artifact/org.mybatis.spring.boot/mybatis-spring-boot-starter -->
	<dependency>
		<groupId>org.mybatis.spring.boot</groupId>
		<artifactId>mybatis-spring-boot-starter</artifactId>
		<version>2.2.2</version>
	</dependency>


	<dependency>
		<groupId>com.oracle.database.jdbc</groupId>
		<artifactId>ojdbc8</artifactId>
	</dependency>

	<dependency>
		<groupId>com.oracle.database.nls</groupId>
		<artifactId>orai18n</artifactId>
	</dependency>`

this is the error message Caused by: java.lang.IllegalArgumentException: Property 'sqlSessionFactory' or 'sqlSessionTemplate' are required at org.springframework.util.Assert.notNull(Assert.java:201) at org.mybatis.spring.support.SqlSessionDaoSupport.checkDaoConfig(SqlSessionDaoSupport.java:122) at org.mybatis.spring.mapper.MapperFactoryBean.checkDaoConfig(MapperFactoryBean.java:73) at org.springframework.dao.support.DaoSupport.afterPropertiesSet(DaoSupport.java:44) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1790) ... 95 more

Fixes #2142 .

Changes proposed in this pull request:

one job, multi instances completed on concurrency, can cause once listener execute some times, my current system use redis lock to avoid, but source code should add a distributed lock to avoid this, use curator InterProcessMutex now, please help review and give some advice.

When we use k8s deploy our service which integrated with ejob-lite，service IP is always not fixed. Zookeeper Servers node list is getting longer and longer. JobShutdownHookPlugin won't clear services node, and servers node also not as ephemeral node, both have other considerations?

Version: ElasticJob-Lite 3.0.1 problem：

1. Applicatoin in k8s has two instance when failover enabled；
2. Job execute and has finish in one of instance；
3. Restart the sharding pod, job will executed in another instance not in next trigger time. I think with failover enabled, the job will be sharding in new node and wait to execute

When I register a transient task, the result returned is "Name cannot be null."

elasticjob-cloud version :3.0.2 mesos version: 1.11.0 zookeeper version: 3.7.1

How to solve this problem

What happened？

There are 1 security vulnerabilities found in commons-codec:commons-codec 1.10

• MPS-2022-11853

What did I do？

Upgrade commons-codec:commons-codec from 1.10 to 1.13 for vulnerability fix

What did you expect to happen？

Ideally, no insecure libs should be used.

The specification of the pull request

PR Specification from OSCS Signed-off-by:pen4[email protected]