[GitHub] merlimat commented on a change in pull request #1124: Support Pulsar proxy from C++/Python client library

[GitBox]

merlimat commented on a change in pull request #1124: Support Pulsar proxy from 
C++/Python client library
URL: https://github.com/apache/incubator-pulsar/pull/1124#discussion_r164510154
 
 

 ##
 File path: pulsar-client-cpp/lib/Url.cc
 ##
 @@ -88,6 +88,12 @@ const std::string& Url::file() const { return file_; }
 
 const std::string& Url::parameter() const { return parameter_; }
 
+std::string Url::hostPort() const {
 
 Review comment:
   To return a reference, we would have to store the `hostPort` as a member 
variable. Since we don't always need the `hostPort()` in `Url` class, I prefer 
to just create it on the fly when needed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] merlimat commented on a change in pull request #1124: Support Pulsar proxy from C++/Python client library

[GitBox]

merlimat commented on a change in pull request #1124: Support Pulsar proxy from 
C++/Python client library
URL: https://github.com/apache/incubator-pulsar/pull/1124#discussion_r164509672
 
 

 ##
 File path: pulsar-client-cpp/lib/ConnectionPool.cc
 ##
 @@ -33,36 +33,37 @@ ConnectionPool::ConnectionPool(const ClientConfiguration& 
conf, ExecutorServiceP
   poolConnections_(poolConnections),
   mutex_() {}
 
-Future 
ConnectionPool::getConnectionAsync(const std::string& endpoint) {
+Future ConnectionPool::getConnectionAsync(
+const std::string& logicalAddress, const std::string& physicalAddress) {
 boost::unique_lock lock(mutex_);
 
 if (poolConnections_) {
-PoolMap::iterator cnxIt = pool_.find(endpoint);
+PoolMap::iterator cnxIt = pool_.find(logicalAddress);
 
 Review comment:
   Yes, though, for efficiency reasons, the proxy maintains a 1-1 relationship 
for connections (client->proxy vs proxy->broker). This allows the proxy to 
degrade itself to a mere TCP proxy after the initial handshake, just copying 
buffers from one side to the other, without deserializing anything. 
   
   For this to work, the client needs to be aware that some connections are for 
some broker and some are for a different broker. In this case the 
"logicalAddress" is the final broker address.
   
   Eg: lookup for topic "t-1" returns "broker-1", with proxy flag turned on. 
   
   Client connects to proxy address and adds this connection to pool, marking 
this is for "broker-1". 
   
   Next time the client will need a connection to "broker-1", it will reuse the 
same connection to proxy.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services