Fix: broken websocket test and proxy-producer error handling #99
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
CLA is valid! |
rdhabalia
force-pushed
the
socket_test
branch
3 times, most recently
from
dc8b045
to
c121979
Compare
merlimat
reviewed
Nov 1, 2016
| @@ -28,7 +28,9 @@ | |||
| FailedToDeserializeFromJSON(3, "Failed to de-serialize from JSON"), // | |||
| FailedToSerializeToJSON(4, "Failed to serialize to JSON"), // | |||
| AuthenticationError(5, "Failed to authenticate client"), // | |||
| NotAuthorizedError(6, "Client is not authorized"); // | |||
| NotAuthorizedError(6, "Client is not authorized"), // | |||
| InvalidPayload(7, "Invalid base64 payload"), // | |||
There was a problem hiding this comment.
What about using PayloadEncodingError?
My thinking is that the payload itself should never be invalid, since we don't care about it.
There was a problem hiding this comment.
sure.. addressed it.
rdhabalia
force-pushed
the
socket_test
branch
2 times, most recently
from
1a89ed3
to
84ad313
Compare
rdhabalia
force-pushed
the
socket_test
branch
2 times, most recently
from
815bec1
to
c11605d
Compare
rdhabalia
commented
Nov 1, 2016
| "result": "send-error:3", | ||
| "errorMsg": "Failed to de-serialize from JSON", | ||
| "context": "1" | ||
| } |
There was a problem hiding this comment.
as doc doesn't have any failure response example: added failure response
There was a problem hiding this comment.
Ok, but keep it in a separate code block, to make it easier to see that they are 2 different json responses.
rdhabalia
force-pushed
the
socket_test
branch
from
c11605d
to
ac4d658
Compare
sijie
pushed a commit
to sijie/pulsar
that referenced
this pull request
Mar 4, 2018
hrsakai
pushed a commit
to hrsakai/pulsar
that referenced
this pull request
Dec 10, 2020
hangc0276
pushed a commit
to hangc0276/pulsar
that referenced
this pull request
May 26, 2021
**Fixes:** apache#166 apache#153 apache#99 **Issue:** KoP uses [Kafka-2.0.0](https://github.com/streamnative/kop/blob/78d9ba3487d4d7c85a5d667d45d9b38aaa7c824f/pom.xml#L46) which supports [API_VERSION's](https://kafka.apache.org/protocol.html#The_Messages_ApiVersions) **0** --> **2** When **_Kafka-Clients-2.4.x+_**(using `API_VERSION: 3`) connects to KoP, it panics and following error stack is observed: `10:22:23.281 [pulsar-io-22-4] ERROR io.streamnative.pulsar.handlers.kop.KafkaCommandDecoder - error to get Response ByteBuf: java.lang.IllegalArgumentException: Invalid version for API key API_VERSIONS: 3 at org.apache.kafka.common.protocol.ApiKeys.schemaFor(ApiKeys.java:312) ~[?:?] at org.apache.kafka.common.protocol.ApiKeys.responseSchema(ApiKeys.java:286) ~[?:?] at org.apache.kafka.common.requests.ApiVersionsResponse.toStruct(ApiVersionsResponse.java:129) ~[?:?] at org.apache.kafka.common.requests.ResponseUtils.serializeResponse(ResponseUtils.java:40) ~[?:?]` **Resolved By:** Returning an `UNSUPPORTED_VERSION` [error-code: 35](https://kafka.apache.org/protocol.html#protocol_error_codes), which would notify the **_kafka-client_** to lower it's `API_VERSION`. As no list of `ApiKeys & versions` were available for the **kafka-clients** to refer, it safely falls-back to using `API_VERSION: 0` and KoP continues processing the kafka-messages using `API_VERSION: 0`. **Tested producing/consuming with Kafka-Clients:** > 2.0.0 2.2.2 2.3.1 2.4.0 2.4.1 2.5.0 2.5.1 2.6.0 **More...** KoP could have returned the list of supported `ApiKeys & versions` while sending the `UNSUPPORTED_VERSION` error-code, which would have made the **_kafka-client_** select the **_latest_** supported `API_VERSION` and use `API_VERSION: 2` instead of falling all the way back and using `API_VERSION: 0` Notes on how **_Kafka-Brokers_** is supposed to handle this scenario: > 2. On receiving ApiVersionsRequest, a broker returns its full list of supported ApiKeys and versions regardless of current authentication state (e.g., before SASL authentication on an SASL listener, do note that no Kafka protocol requests may take place on an SSL listener before the SSL handshake is finished). If this is considered to leak information about the broker version a workaround is to use SSL with client authentication which is performed at an earlier stage of the connection where the ApiVersionRequest is not available. Also, note that broker versions older than 0.10.0.0 do not support this API and will either ignore the request or close connection in response to the request. > > 3. If multiple versions of an API are supported by broker and client, clients are recommended to use the latest version supported by the broker and itself. _Reference: [Kafka-Protocol Guide](https://kafka.apache.org/protocol.html#api_versions)_ We analyzed how various **_Kafka-Brokers_** respond to a similar situation where the **_kafka-client's_** `API_VERSION` is higher than what is supported by the **_Kafka-Broker_**.  _Reference: Wireshark packet captures - [Kafka-Protocol-Study.zip](https://github.com/streamnative/kop/files/5127018/Kafka-Protocol-Study.zip)_ From the study we can infer that, in a similar `API_VERSION` mismatch scenario the **_Kafka-Brokers_** doesn't return the list of supported `ApiKeys & versions` when notifying the **_kafka-client_** with the `UNSUPPORTED_VERSION` [error-code: 35](https://kafka.apache.org/protocol.html#protocol_error_codes). Thus, forcing the **_kafka-clients_** to fall-back to using `API_VERSION: 0`. To keep KoP working in sync with the **_Kafka-Broker_** working, we decided not to return the list of supported `ApiKeys & versions`.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Modifications
Result
No functional change