Support Topic lookup using Pulsar binary protocol - #5
Conversation
|
CLA is valid! |
There was a problem hiding this comment.
I think we should use the http & https urls from the report here (all 4 the urls)
There was a problem hiding this comment.
Actually in this case, returned LookupResult contains redirect urls.
- Http lookup request just requires broker-url where call should be redirected. So,
LookupResulthas onehttp/https url - Binary-Protocol request sends both broker service-url/tls and client decides which one needs to be selected based on client configuration.
e254af3 to
ff3c89b
Compare
There was a problem hiding this comment.
We should abstract the LookupService to have 2 different implementation instead of relying on the flag.
There was a problem hiding this comment.
yes.. made the change to abstract LookupService.
e5dcb7a to
f37db88
Compare
There was a problem hiding this comment.
yes..we picked up the same commit to unblock this enhancement.
There was a problem hiding this comment.
That PR is merged, so you can just rebase to get rid of the commit from this PR.
There was a problem hiding this comment.
Don't we return the broker address if the bundle is already owned? If I'm not wrong, we only redirect the request if the bundle is not owned.
There was a problem hiding this comment.
yes.. that is correct. added that point in comment as well.
There was a problem hiding this comment.
can we put these validation checks in separate methods maybe?
There was a problem hiding this comment.
actually, we have already abstracted all validation. and each validation step: we are returning different LookupResponse-ByteBuf
There was a problem hiding this comment.
Could you confirm if removing this will be backward compatible?
There was a problem hiding this comment.
yes.. as we were not returning httpRedirectAddress to client and it was being used in internal method to find out final returning result.
- If
Type== HttpRedirectUrlthen redirect-http request to URLhttpRedirectAddress.
However, in new change all urls service/web-service/tls will be part of LookupData and redirection will be determined using RedirectUrl type.
There was a problem hiding this comment.
removed comment..
There was a problem hiding this comment.
This method is already there in AdminResource.java
There was a problem hiding this comment.
handlePartitionRequest -> handlePartitionMetadataRequest
There was a problem hiding this comment.
alright.. renamed the method name.
There was a problem hiding this comment.
Shouldn't we reuse the POJO that we already have for LookupResult
There was a problem hiding this comment.
LookupResult POJO is being used to return Lookup result by Broker-http-lookup. However, to implement Lookup-Response-handling in binary-protocol lookup we need few more additional attributes such as authoritative, redirect, partitions. So, we have this POJO at client side to handle Future.Response for topic-lookup and partition-lookup
d6b782e to
76094a4
Compare
There was a problem hiding this comment.
This deserializer could be made static
There was a problem hiding this comment.
This could actually fail for multiple reasons :) (invalid auth, no zk session.. etc )
There was a problem hiding this comment.
Actually, lookupDestinationAsync(..) handles all failure scenarios (auth, no zk session,..) and always returns appropriate ByteBuf with specific error-response. therefore, future should not complete with exception.
I have addressed all other comments as well.
There was a problem hiding this comment.
Can you wrap this log.debug() call with the if (log.isDebugEnabled())
There was a problem hiding this comment.
serviceAddress can be final
|
@rdhabalia There seems to be a conflict with master in the latest push |
* add protobuf.json to git * make protobuf doc generation static
Motivation
To improve lookup performance: adding lookup API in Pulsar binary protocol for:
Modifications
Result
Result: Client-library can do topic-lookup using pulsar binary protocol.