You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 11, 2024. It is now read-only.
From Kafka documentation, this is all the info the Produce Request (Took version 8 as example):
Produce Request (Version: 8) => transactional_id acks timeout_ms [topic_data]
transactional_id => NULLABLE_STRING
acks => INT16
timeout_ms => INT32
topic_data => name [partition_data]
name => STRING
partition_data => index records
index => INT32
records => RECORDS
The app also knows the broker address the request was made to, It also has the mappings between Brokers and local ports.
At a glance, I see the app could find the channel by checking the topic name on the Produce Request, match it with channels within the AsyncAPI doc with an Operation type of subscribe.
However, this solution won't scale that much since we are assuming operations and messages are a 1:1 relationship, but this is subject to change in version 3 of the spec.
Would it make sense to introduce some identifier in the message so we can validate directly looking by that identifier?
The text was updated successfully, but these errors were encountered:
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
From Kafka documentation, this is all the info the
Produce Request
(Took version 8 as example):The app also knows the broker address the request was made to, It also has the mappings between Brokers and local ports.
At a glance, I see the app could find the channel by checking the topic name on the
Produce Request
, match it with channels within the AsyncAPI doc with an Operation type ofsubscribe
.However, this solution won't scale that much since we are assuming operations and messages are a 1:1 relationship, but this is subject to change in version 3 of the spec.
Would it make sense to introduce some identifier in the message so we can validate directly looking by that identifier?
The text was updated successfully, but these errors were encountered: