[ 
https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17205021#comment-17205021
 ] 

ASF GitHub Bot commented on GEODE-8553:
---------------------------------------

pdxcodemonkey commented on a change in pull request #660:
URL: https://github.com/apache/geode-native/pull/660#discussion_r497675027



##########
File path: cppcache/src/ThinClientLocatorHelper.cpp
##########
@@ -62,7 +62,7 @@ ThinClientLocatorHelper::ThinClientLocatorHelper(
     const ThinClientPoolDM* poolDM)
     : m_poolDM(poolDM) {
   for (auto&& locatorAddress : locatorAddresses) {
-    m_locHostPort.emplace_back(locatorAddress);
+    m_Locators.emplace_back(locatorAddress);

Review comment:
       If you're already renaming a member variable, it'd be great to make it 
conform to our preferred style, basically Google conventions.  This would just 
be `locators_`, with a trailing underscore.  Our rule of thumb for small 
refactors like this is to go ahead and do them as long as you're already 
editing the file in your PR.

##########
File path: cppcache/src/ThinClientLocatorHelper.cpp
##########
@@ -174,30 +176,25 @@ GfErrType 
ThinClientLocatorHelper::getEndpointForNewCallBackConn(
     ClientProxyMembershipID& memId, std::list<ServerLocation>& outEndpoint,
     std::string&, int redundancy, const std::set<ServerLocation>& exclEndPts,
     const std::string& serverGrp) {
-  std::lock_guard<decltype(m_locatorLock)> guard(m_locatorLock);
   auto& sysProps = m_poolDM->getConnectionManager()
                        .getCacheImpl()
                        ->getDistributedSystem()
                        .getSystemProperties();
-  int locatorsRetry = 3;
-  if (m_poolDM) {
-    int poolRetry = m_poolDM->getRetryAttempts();
-    locatorsRetry = poolRetry <= 0 ? locatorsRetry : poolRetry;
-  }
+
+  auto poolRetry = m_poolDM->getRetryAttempts();
+  auto locatorsRetry = poolRetry <= 0 ? 3 : poolRetry;
+
   LOGFINER(
       "ThinClientLocatorHelper::getEndpointForNewCallBackConn locatorsRetry = "
       "%d ",
       locatorsRetry);
-  for (unsigned attempts = 0;
-       attempts <
-       (m_locHostPort.size() == 1 ? locatorsRetry : m_locHostPort.size());
-       attempts++) {
-    ServerLocation loc;
-    if (m_locHostPort.size() == 1) {
-      loc = m_locHostPort[0];
-    } else {
-      loc = m_locHostPort[attempts];
-    }
+
+  auto locators = getLocators();
+  auto locatorsSize = locators.size();
+  auto maxAttempts = locatorsSize == 1 ? locatorsRetry : locatorsSize;
+
+  for (auto attempts = 0ULL; attempts < maxAttempts; ++attempts) {
+    const auto& loc = locatorsSize == 1 ? locators[0] : locators[attempts];

Review comment:
       A local variable that shadows `locators.size()` doesn't really clarify 
things much.  How about a boolean that represents the test you're doing?  
Something like:
   ```
   auto locators = getLocators();
   auto singleLocator = locators.size() == 1;
   auto maxAttempts = singleLocator ? locatorsRetry : locators.size();
   
   for (auto attempts = 0; attempts < maxAttempts; ++attempts) {
     const auto& loc = singleLocator ? locators[0] : locators[attempts];
   ```
   I'm not sure whether I prefer this or not, let me know what you think....

##########
File path: cppcache/src/ThinClientLocatorHelper.cpp
##########
@@ -357,22 +349,20 @@ GfErrType 
ThinClientLocatorHelper::getEndpointForNewFwdConn(
 
 GfErrType ThinClientLocatorHelper::updateLocators(
     const std::string& serverGrp) {
-  std::lock_guard<decltype(m_locatorLock)> guard(m_locatorLock);
   auto& sysProps = m_poolDM->getConnectionManager()
                        .getCacheImpl()
                        ->getDistributedSystem()
                        .getSystemProperties();
 
-  for (size_t attempts = 0; attempts < m_locHostPort.size(); attempts++) {
-    auto&& serLoc = m_locHostPort[attempts];
+  auto locators = getLocators();
+  for (const auto& loc : locators) {

Review comment:
       This is so much better - thanks!

##########
File path: cppcache/src/ThinClientLocatorHelper.hpp
##########
@@ -60,20 +63,23 @@ class ThinClientLocatorHelper {
       std::vector<std::shared_ptr<ServerLocation> >& servers,
       const std::string& serverGrp);
   int32_t getCurLocatorsNum() {
-    return static_cast<int32_t>(m_locHostPort.size());
+    return static_cast<int32_t>(m_Locators.size());
   }
   GfErrType updateLocators(const std::string& serverGrp = "");
 
  private:
+  std::vector<ServerLocation> getLocators() const;
   Connector* createConnection(Connector*& conn, const char* hostname,
                               int32_t port,
                               std::chrono::microseconds waitSeconds,
                               int32_t maxBuffSizePool = 0);
-  std::mutex m_locatorLock;
-  std::vector<ServerLocation> m_locHostPort;
+
+  /**
+   * Data members
+   */
+  mutable std::mutex m_locatorLock;

Review comment:
       The `mutable` keyword is usually a "code smell" - is this just needed in 
order to declare `getLocators` const?

##########
File path: cppcache/src/ThinClientLocatorHelper.cpp
##########
@@ -74,10 +74,15 @@ ThinClientLocatorHelper::ThinClientLocatorHelper(
       m_sniProxyHost(sniProxyHost),
       m_sniProxyPort(sniProxyPort) {
   for (auto&& locatorAddress : locatorAddresses) {
-    m_locHostPort.emplace_back(locatorAddress);
+    m_Locators.emplace_back(locatorAddress);
   }
 }
 
+std::vector<ServerLocation> ThinClientLocatorHelper::getLocators() const {

Review comment:
       This would be a great place for a comment block explaining why we're 
doing what we're doing, and why it's a bad idea to just return a reference to 
m_Locators.  These sorts of things tend to be forgotten over time.

##########
File path: cppcache/src/ThinClientLocatorHelper.cpp
##########
@@ -267,24 +263,20 @@ GfErrType 
ThinClientLocatorHelper::getEndpointForNewFwdConn(
   LOGFINER(
       "ThinClientLocatorHelper::getEndpointForNewFwdConn locatorsRetry = %d ",
       locatorsRetry);
-  for (unsigned attempts = 0;
-       attempts <
-       (m_locHostPort.size() == 1 ? locatorsRetry : m_locHostPort.size());
-       attempts++) {
-    ServerLocation serLoc;
-    if (m_locHostPort.size() == 1) {
-      serLoc = m_locHostPort[0];
-    } else {
-      serLoc = m_locHostPort[attempts];
-    }
+
+  auto locators = getLocators();
+  auto locatorsSize = locators.size();
+  auto maxAttempts = locatorsSize == 1 ? locatorsRetry : locatorsSize;
+
+  for (auto attempts = 0ULL; attempts < maxAttempts; ++attempts) {
+    const auto& loc = locatorsSize == 1 ? locators[0] : locators[attempts];

Review comment:
       Same as above




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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


> Reduce ThinClientLocatorHelper lock time
> ----------------------------------------
>
>                 Key: GEODE-8553
>                 URL: https://issues.apache.org/jira/browse/GEODE-8553
>             Project: Geode
>          Issue Type: Improvement
>          Components: native client
>    Affects Versions: 1.12.0, 1.13.0
>            Reporter: Mario Salazar de Torres
>            Assignee: Mario Salazar de Torres
>            Priority: Major
>              Labels: pull-request-available
>
> During my troublshootings, I've seen that locking m_locatorLock for the whole 
> scope of the class function members might cause some inter-locks.
> Problem here and in many other places of the NC is that networking operations 
> are performed while a mutex is locked. Therefore if *thread A* takes longer 
> than expected in performing its network operation, it might block another one 
> which does not requires any resource of the first *thread A*. Hence, the 
> inter-lock.
> This improvement is the first one of a series regarding to lock scope 
> reduction when it comes with code regarding networking in NC.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to