Yunze Xu
> If the task isn't inherently decomposable, using ForkJoinPool won't improve performance and may introduce unnecessary overhead. It's only one typical case. From the [official document](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/ForkJoinPool.html): > as well as...
> If thread switching is needed, it’s better to specify a Pulsar-managed executor The issue is, where should a Pulsar-managed executor be used is very ambiguous. I agree that there...
Therefore, I'd like to talk about the use of `thenXXXAsync` or `thenXXXAsync` case by case. Take the case I've mentioned before: https://github.com/apache/pulsar/blob/3bd70fd74fd2586724d4830c140a42517e028959/pulsar-broker/src/main/java/org/apache/pulsar/broker/transaction/pendingack/impl/PendingAckHandleImpl.java#L171 We should replace `thenAcceptAsync` with `thenAccept` here. It...
> it would be better to use a dedicated ForkJoinPool where necessary, I agree.
@vraulji567 Could you fix the failed tests?
Another approach is to create the missed partitioned metadata automatically. For example, with this PIP implemented, when the broker detects `my-topic-partition-0` is accessed by a client but there is no...
> This is difficult because we can not obtain the maximum partition index. We can list all non-partitioned topics of the `-partition-` pattern and find the maximum `index`.
> Do this during topic creation (e.g., via admin topics create-partitioned-topic) or at runtime? Topic creation, or `BrokerService#getTopic` on a non-partitioned topic whose name ends with `-partition-`.
Then support creating missed partitions via admin API for such cases could be the solution. Currently the create-missed-partitions API does not work.
Yeah, it's related to the C++ core. And it's a known issue. It might be easy to fix. I will take some time for it when I'm free.