Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: broken websocket test and proxy-producer error handling #99

Merged
merged 1 commit into from
Nov 1, 2016

Conversation

rdhabalia
Copy link
Contributor

Motivation

  • Web-socket unit-test cases are broken and not validating functionalities correctly
  • Websocket proxy-producer was missing few validation/error-handling in msg-produce scenario

Modifications

  • Fixed: all web-socket unit-testcases
  • Fixed: websocket-proxy-producer validation/error handling

Result

No functional change

@yahoocla
Copy link

yahoocla commented Nov 1, 2016

CLA is valid!

Copy link
Contributor

@merlimat merlimat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work, I just have a minor naming suggestion

@@ -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"), //
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using PayloadEncodingError?

My thinking is that the payload itself should never be invalid, since we don't care about it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure.. addressed it.

@rdhabalia rdhabalia force-pushed the socket_test branch 2 times, most recently from 1a89ed3 to 84ad313 Compare November 1, 2016 17:33
Copy link
Contributor

@merlimat merlimat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@rdhabalia rdhabalia force-pushed the socket_test branch 2 times, most recently from 815bec1 to c11605d Compare November 1, 2016 18:23
"result": "send-error:3",
"errorMsg": "Failed to de-serialize from JSON",
"context": "1"
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as doc doesn't have any failure response example: added failure response

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, but keep it in a separate code block, to make it easier to see that they are 2 different json responses.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure. done.

@merlimat merlimat merged commit 1f05368 into apache:master Nov 1, 2016
@merlimat merlimat added this to the 1.16 milestone Nov 1, 2016
@rdhabalia rdhabalia deleted the socket_test branch November 11, 2016 23:02
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_**.

![Kafka-Broker-Client-Wireshark-Results](https://user-images.githubusercontent.com/63665447/91243701-34d3a500-e710-11ea-9752-f9980333ce1d.png)
_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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants