likandia commented on PR #80:
URL: https://github.com/apache/kafka/pull/80#issuecomment-4698731699
## Second update: concrete Java-source case found
After empirical scan of storage/src/main/java for broker-identity-holding
patterns:
**`RemoteLogManager.java:152`** declares `private final int brokerId;` and
is a per-broker SERVICE class (instantiated once per KafkaServer).
Holders found via direct field declaration:
- `RemoteLogReader.java` — holds a RemoteLogManager field
- `RemoteLogOffsetReader.java` — holds a RemoteLogManager field
So knobs in those 3 storage classes ARE RS(1)-amenable today — no framework
changes needed. The system_replica_groups LLM should have emitted:
```
replica_groups.broker_remote_log:
parent_class: RemoteLogManager
field_paths:
RemoteLogReader: this.<rlmField>
RemoteLogOffsetReader: this.<rlmField>
```
Instead it emitted entries for Scala classes in core/ (ReplicaManager,
Partition, KafkaApis, GroupMetadataManager) which don't exist as .java files in
the source-base.
## Revised disposition
Method-chain shape is a separate (still-speculative) concern. The immediate
issue is **prompt-side**: when no broker-class itself is in source-base scope
(because the broker class is in another module or another language), the LLM
should fall back to identifying per-broker SERVICE classes that DO exist in
scope.
Going to update the prompt + re-run system_replica_groups on Kafka, and add
the RemoteLogManager replica group to the Kafka profile if it gets discovered.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
