confluentinc#299: POC for project Loom integration for light weight threads (higher concurrency without Vert.x or Reactor) #147

Mirror of confluentinc/parallel-consumer#299
Opened by astubbs, 2022-05-13 · 2 comments upstream · last upstream activity 2023-04-28
Summarised, not copied. Discussion belongs here - the Confluent-hosted repository is no
longer maintained and may be archived.

Summary

Proof of concept for Project Loom integration, to get high concurrency without needing the Vert.x or Reactor modules.

Fork status

Not implemented. Searched every main and test source for
virtualthread|ofVirtual|newVirtualThreadPerTask|loom - zero hits; the only matches are prose in the
fork's upstream analysis doc. ParallelConsumerOptions has no such option.

The blocker is structural, not effort: the artifact targets Java 8 (release.target 8), and
virtual threads need 21+. So this needs either a runtime-gated path, a multi-release jar, or the Java
baseline move - which is the 0.7.x work in #53.

Fork PR #51 is the live vehicle for virtual-thread support and is open.

Do not simply close this as superseded by #51. The fork's own analysis ranks the orphaned PR below
as A5 and says explicitly: predates upstream confluentinc#908, compare approaches before redoing. There are two
designs to weigh.

Unmerged work

confluentinc/parallel-consumer#300 - Loom POC (Virtual Threads).

Closed unmerged, but not rejected: around 40 of the 53 open PRs were closed on a single day, 2023-06-15, when the maintainer left Confluent. That was an administrative sweep, not a review outcome. The fork's src/docs/development/upstream-pr-analysis.adoc catalogues them as revival candidates.

Ranked A5, with the analysis noting it predates upstream confluentinc#908 and advising compare approaches before redoing. That is a direct argument against treating this as simply superseded by the fork's own virtual-threads PR #51 - there are two designs to weigh, not one to adopt.