Fixed handling errors for client requests #8518
Merged
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
merlimat
added
type/bug
merlimat
requested review from
ivankelly,
sijie,
srkukarni,
rdhabalia,
jerrypeng and
codelipenghui
jerrypeng
reviewed
Nov 11, 2020
| @@ -465,7 +443,7 @@ protected void handleGetLastMessageIdSuccess(CommandGetLastMessageIdResponse suc | |||
| log.debug("{} Received success GetLastMessageId response from server: {}", ctx.channel(), success.getRequestId()); | |||
| } | |||
| long requestId = success.getRequestId(); | |||
| CompletableFuture<MessageIdData> requestFuture = pendingGetLastMessageIdRequests.remove(requestId); | |||
| CompletableFuture<MessageIdData> requestFuture = (CompletableFuture<MessageIdData>) pendingRequests.remove(requestId); | |||
There was a problem hiding this comment.
if there is a cast exception, shouldn't we handle it? If the client somehow is returned a wrong request id that is for a different request type, a cast exception may happen here. If it does, the requestFuture will never get completed and may cause the client api call to block forever.
There was a problem hiding this comment.
The connection will get automatically closed and therefore the future will be completed there.
jerrypeng
approved these changes
Nov 11, 2020
sijie
approved these changes
Nov 11, 2020
codelipenghui
pushed a commit
that referenced
this pull request
Nov 12, 2020
`ClientCnx` is maintaining different maps for different types of requests. The problem is that on `handleError()` it's only checking on the main map, the one containing requests for creating producers and consumers, but it's ignoring the error on other kind of requests. For example, an error returned by broker on the `GetLastMessageId` request, will result in calls to `hasMessageAvailable()` to get stuck, since the error is ignored and the future never completed: ``` 18:11:09.083 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@602] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received error from server: XXX 18:11:09.084 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@612] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received unknown request id from server: 3 ``` There's no good reason to keep 1 map per kind of request. Instead, we should use a single map. (cherry picked from commit bb45b8c)
|
cherry-picked to branch-2.6 |
codelipenghui
pushed a commit
to streamnative/pulsar-archived
that referenced
this pull request
Nov 13, 2020
`ClientCnx` is maintaining different maps for different types of requests. The problem is that on `handleError()` it's only checking on the main map, the one containing requests for creating producers and consumers, but it's ignoring the error on other kind of requests. For example, an error returned by broker on the `GetLastMessageId` request, will result in calls to `hasMessageAvailable()` to get stuck, since the error is ignored and the future never completed: ``` 18:11:09.083 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@602] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received error from server: XXX 18:11:09.084 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@612] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received unknown request id from server: 3 ``` There's no good reason to keep 1 map per kind of request. Instead, we should use a single map. (cherry picked from commit bb45b8c) (cherry picked from commit eb5e81b)
flowchartsman
pushed a commit
to flowchartsman/pulsar
that referenced
this pull request
Nov 17, 2020
### Motivation `ClientCnx` is maintaining different maps for different types of requests. The problem is that on `handleError()` it's only checking on the main map, the one containing requests for creating producers and consumers, but it's ignoring the error on other kind of requests. For example, an error returned by broker on the `GetLastMessageId` request, will result in calls to `hasMessageAvailable()` to get stuck, since the error is ignored and the future never completed: ``` 18:11:09.083 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@602] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received error from server: XXX 18:11:09.084 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@612] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received unknown request id from server: 3 ``` ### Modifications There's no good reason to keep 1 map per kind of request. Instead, we should use a single map.
merlimat
added a commit
to merlimat/pulsar
that referenced
this pull request
Dec 19, 2020
### Motivation `ClientCnx` is maintaining different maps for different types of requests. The problem is that on `handleError()` it's only checking on the main map, the one containing requests for creating producers and consumers, but it's ignoring the error on other kind of requests. For example, an error returned by broker on the `GetLastMessageId` request, will result in calls to `hasMessageAvailable()` to get stuck, since the error is ignored and the future never completed: ``` 18:11:09.083 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@602] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received error from server: XXX 18:11:09.084 [pulsar-client-io-1-1:org.apache.pulsar.client.impl.ClientCnx@612] WARN org.apache.pulsar.client.impl.ClientCnx - [id: 0xa378924b, L:/127.0.0.1:58267 - R:localhost/127.0.0.1:6650] Received unknown request id from server: 3 ``` ### Modifications There's no good reason to keep 1 map per kind of request. Instead, we should use a single map.
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
ClientCnxis maintaining different maps for different types of requests. The problem is that onhandleError()it's only checking on the main map, the one containing requests for creating producers and consumers, but it's ignoring the error on other kind of requests.For example, an error returned by broker on the
GetLastMessageIdrequest, will result in calls tohasMessageAvailable()to get stuck, since the error is ignored and the future never completed:Modifications
There's no good reason to keep 1 map per kind of request. Instead, we should use a single map.