guqing's blog

guqing/halo

✍ 一款优秀的开源博客发布应用。

/lgtm

在 elastic thread 中并不是简单的转换操作

这里我是说的后续的 ServerResponse.ok().bodyValue() 步骤并不是说之前,也就是说后续的操作沿用之前的线程。

对于你说的 WebFilter 中执行，假如以下示例

final Flux<String> betterFetchUrls(List<String> urls) {
    return Flux.fromIterable(urls)
        .flatMap(url -> 
			// 比作当前调用的 Mono<ServerResponse> getLinkDetail(ServerRequest request) 方法
            Mono.fromCallable(() -> blockingWebClient.get(url))
            .subscribeOn(Schedulers.boundedElastic())
        );
}

那么对于订阅者

someSource.flatMap(a -> betterFetchUrls(xxx))
          .doOnNext(a -> xxx)

doOnNext 或者其他操作都会在上游执行线程也就是 someSource 相同的线程执行，并不会受到 betterFetchUrls 中 subscribeOn 的影响，因此 .publishOn(Schedulers.parallel()) 操作受影响的只有 .flatMap(dto -> ServerResponse.ok().bodyValue(dto));

/lgtm

我认为这是分情况的，对于链接中提到的 WebSession 创建的阻塞操作后切换到新线程是库开发者为了避免让后续的操作被之前的阻塞操作阻塞而开发者不清楚这一状况这与 flight-of-the-flux-3-hopping-threads-and-schedulers 提到的情况类似，但是对于现在的情况 boundedElastic 线程执行之后只是一个简单的转换操作并写响应，继续在之前的线程上执行应该并没有影响，publishOn 反而是造成线程切换，根据 schedulers 的描述的线程池性质，如果阻塞操作的后续还有耗时较长的操作（这会占用当前使用的 boundedElastic 线程很长时间导致其他需要此线程池的 task 没有机会分配到）这种情况下切换线程才是合理的。如果一味的跟随这一观点，那后续所有用包装了阻塞操作的后续都要使用 .publishOn 到 parallel 线程这应该不是最佳实践

/lgtm

不是很懂这个和 WebSessionId 生成或者 WebSessionServerRequestCache 有什么关系🫠

omegat-org/htmlparser

What this PR does?

为 halo-dev/halo#6531 补充文档说明

None

guqing/docs

The open-source repo for docs.halo.run