FISCO-BCOS / FISCO-BCOS/web3sdk

EventLog事件callback在多线程时次序不一致的问题

Open
#714 0 comments 0 reactions 0 assignees View on GitHub
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);
}
}

```

日志如下:
![image](https://user-images.githubusercontent.com/28867867/96569305-8e64e400-12fb-11eb-9be9-5b4a4b817c38.png)

可以看到同一线程时,存储log的finalList size为1,但是不同线程时,finalList size为0就结束了。导致这两次过滤的入参相同,但是获取的事件列表不一致

**临时解决方法**:在status=1时,加上`Thread.sleep(100);`,让CompletableFuture稍晚结束,即可获取最后一条的log callback

Contributor guide

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.