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

Support Topic lookup using Pulsar binary protocol #5

Merged
merged 1 commit into from
Nov 9, 2016

Conversation

rdhabalia
Copy link
Contributor

@rdhabalia rdhabalia commented Sep 10, 2016

Motivation

To improve lookup performance: adding lookup API in Pulsar binary protocol for:

  • PartitionedTopicMetadata
  • Topic-lookup: find BrokerService-Url

Modifications

  • Introduced two new protobuf-commands for partitionedMetadata and topic lookup
  • server/client api to handle lookup request/response

Result

Result: Client-library can do topic-lookup using pulsar binary protocol.

@yahoocla
Copy link

CLA is valid!

@rdhabalia rdhabalia changed the title CMS-1920 TCP: PartitionMetadata-Lookup + Topic-Broker lookup TCP: Topic lookup Sep 10, 2016
@rdhabalia rdhabalia added this to the 1.15 milestone Sep 10, 2016
@rdhabalia rdhabalia self-assigned this Sep 10, 2016
@rdhabalia rdhabalia added the type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages label Sep 10, 2016
@rdhabalia rdhabalia changed the title TCP: Topic lookup Support Topic lookup using Pulsar binary protocol Sep 10, 2016
}
});

LookupResult result = new LookupResult(new URI(candidateBroker), report.getPulsarServiceUrl(), report.getPulsarServieUrlTls());
Copy link
Contributor

@merlimat merlimat Sep 10, 2016

Choose a reason for hiding this comment

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

I think we should use the http & https urls from the report here (all 4 the urls)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually in this case, returned LookupResult contains redirect urls.

  • Http lookup request just requires broker-url where call should be redirected. So, LookupResult has one http/https url
  • Binary-Protocol request sends both broker service-url/tls and client decides which one needs to be selected based on client configuration.

@@ -56,7 +56,8 @@
private static final Logger log = LoggerFactory.getLogger(PulsarClientImpl.class);

private final ClientConfiguration conf;
private final HttpClient httpClient;
private HttpClient httpClient;
private boolean isHttpURI;
Copy link
Contributor

Choose a reason for hiding this comment

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

We should abstract the LookupService to have 2 different implementation instead of relying on the flag.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes.. made the change to abstract LookupService.

@@ -177,7 +177,8 @@ public SimpleLoadManagerImpl(PulsarService pulsar) {
this.realtimeResourceQuotas.set(new HashMap<>());
this.realtimeAvgResourceQuota = new ResourceQuota();
placementStrategy = new WRRPlacementStrategy();
lastLoadReport = new LoadReport();
lastLoadReport = new LoadReport(pulsar.getWebServiceAddress(), pulsar.getWebServiceAddressTls(),
Copy link
Contributor

Choose a reason for hiding this comment

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

This change is already in the other PR #11

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes..we picked up the same commit to unblock this enhancement.

Copy link
Contributor

Choose a reason for hiding this comment

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

That PR is merged, so you can just rebase to get rid of the commit from this PR.

*
* Lookup broker-service address for a given namespace-bundle which contains given topic.
*
* a. If current-broker receives lookup-request and if it's not a leader
Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes.. that is correct. added that point in comment as well.

String clientAppId, long requestId) {
final String cluster = fqdn.getCluster();
try {
// (1) validate cluster
Copy link
Contributor

Choose a reason for hiding this comment

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

can we put these validation checks in separate methods maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

actually, we have already abstracted all validation. and each validation step: we are returning different LookupResponse-ByteBuf

}

private final Type type;
private final LookupData lookupData;
private final URI httpRedirectAddress;
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you confirm if removing this will be backward compatible?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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== HttpRedirectUrl then redirect-http request to URL httpRedirectAddress.

However, in new change all urls service/web-service/tls will be part of LookupData and redirection will be determined using RedirectUrl type.

@@ -366,7 +357,8 @@ private LookupResult findBrokerServiceUrl(ServiceUnitId suName, boolean authorit
pulsar.getBrokerServiceUrl(), pulsar.getWebServiceAddress(), candidateBroker, suName);
}
// Now setting the redirect url
return new LookupResult(new URI(candidateBroker));
//new LookupResult(new URI(candidateBroker))
Copy link
Contributor

Choose a reason for hiding this comment

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

Please remove this line

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed comment..

return result;
}

public ObjectMapper jsonMapper() {
Copy link
Contributor

Choose a reason for hiding this comment

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

This method is already there in AdminResource.java

}

@Override
protected void handlePartitionRequest(CommandPartitionedTopicMetadata partitionMetadata) {
Copy link
Contributor

Choose a reason for hiding this comment

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

handlePartitionRequest -> handlePartitionMetadataRequest

Copy link
Contributor Author

Choose a reason for hiding this comment

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

alright.. renamed the method name.

return serviceAddress.toString();
}

static class LookupDataResult {
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we reuse the POJO that we already have for LookupResult

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

@merlimat merlimat modified the milestones: 1.16, 1.15 Oct 8, 2016
@rdhabalia
Copy link
Contributor Author

Please ignore travis-build for this PR for now: as it seems there is an issue with travis-build, it always picks up a wrong commit-1b99fa608daa42955e09356f89ae498d6c969347 from different PR and that wrong commit had a unit-testcase-failure-issue which is already fixed in later commit of PR. I have local-travis-job setup which is green by picking up correct commit.

uri.getPort());
pulsar.getLocalZkCache().getDataAsync(path, new Deserializer<LoadReport>() {
@Override
public LoadReport deserialize(String key, byte[] content) throws Exception {
Copy link
Contributor

Choose a reason for hiding this comment

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

This deserializer could be made static

lookup.getAuthoritative(), getRole(), lookup.getRequestId()).thenAccept(lookupResponse -> {
ctx.writeAndFlush(lookupResponse);
}).exceptionally(ex -> {
// it should never happen
Copy link
Contributor

Choose a reason for hiding this comment

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

This could actually fail for multiple reasons :) (invalid auth, no zk session.. etc )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

@@ -128,7 +136,7 @@ protected void validateSuperUserAccess() {
if (config().isAuthenticationEnabled()) {
String appId = clientAppId();
log.debug("[{}] Check super user access: Authenticated: {} -- Role: {}", uri.getRequestUri(),
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you wrap this log.debug() call with the if (log.isDebugEnabled())

class BinaryProtoLookupService implements LookupService {

private final ConnectionPool cnxPool;
protected InetSocketAddress serviceAddress;
Copy link
Contributor

Choose a reason for hiding this comment

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

serviceAddress can be final

@merlimat
Copy link
Contributor

merlimat commented Nov 9, 2016

@rdhabalia There seems to be a conflict with master in the latest push

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.

👍

@merlimat merlimat merged commit 004e022 into apache:master Nov 9, 2016
@rdhabalia rdhabalia deleted the lookup branch January 23, 2017 22:04
merlimat referenced this pull request in merlimat/pulsar Jul 7, 2017
* add protobuf.json to git

* make protobuf doc generation static
sijie referenced this pull request in sijie/pulsar Mar 4, 2018
hrsakai pushed a commit to hrsakai/pulsar that referenced this pull request Dec 10, 2020
hangc0276 referenced this pull request in hangc0276/pulsar May 26, 2021
)

*Motivation*

Use a customized version slows down the development.

*Modifications*

- Change to use reflection to access private fields and methods
- Add license headers
- Delete unneeded filees

*Verify this change*

- Enable CI
@zhcn zhcn mentioned this pull request Aug 25, 2022
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants