FISCO-BCOS / FISCO-BCOS/web3sdk
EventLog事件callback在多线程时次序不一致的问题
- Dominant language
- Java
- Stars
- 122
- Forks
- 81
- PR merge metrics
- No merged PRs in 30d
Description
在获取历史区块中event时
- 当status=1的finish callback和status=0的最后一条log callback在sdk线程池的**同一个线程**时,status为1的finish callback会在最后一条Log callback之后推送,获取正常
- 当status=1的finish callback和status=0的最后一条log callback在sdk线程池的**不同的线程**时,偶尔出现status为1的finish callback会在最后一条Log callback之前推送,推送异常。
代码如下:
即status=1的callback比status=0的callback先到达,导致未获取到完整的eventlog list,但是由于`status==1`导致我的CompletableFuture提前结束了。
```
private CompletableFuture> future;
private List finalList;
@Override
public void onPushEventLog(int status, List logs) {
logger.info(
"SyncEventLogCallback onPushEventLog params: {}, status: {}, logs: {}",
getFilter().getParams(), status, logs);
// status == 0 push not finish,
if (status == 0) {
// add in resultList
if (logs != null) {
finalList.addAll(logs);
}
} else if (status == 1){
if (logs != null) {
finalList.addAll(logs);
}
// avoid last log callback(status=0) coming after success callback(status=1)
// try {
// Thread.sleep(100);
// } catch (InterruptedException e) {
// logger.error("sleep 100ms interrupted:{}", JsonUtils.objToString(e.getStackTrace()));
// }
logger.info(
"SyncEventLogCallback push finished status: {}, finalList size:{}",
status, finalList.size());
future.complete(finalList);
} else {
// not 0, not 1, error
logger.error("SyncEventLogCallback onPushEventLog error!");
future.complete(finalList);
}
}
```
日志如下:

可以看到同一线程时,存储log的finalList size为1,但是不同线程时,finalList size为0就结束了。导致这两次过滤的入参相同,但是获取的事件列表不一致
**临时解决方法**:在status=1时,加上`Thread.sleep(100);`,让CompletableFuture稍晚结束,即可获取最后一条的log callback
Contributor guide
Research direction
Start at the onPushEventLog callback shown in the issue and reproduce the event-log request with identical filters while callbacks run on different SDK thread-pool threads. Check the ordering between status=0 log delivery and status=1 completion, then verify that the completed result consistently contains the full event-log list without relying on a sleep.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100