[
https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225715#comment-17225715
]
ASF GitHub Bot commented on GEODE-8553:
---------------------------------------
gaussianrecurrence commented on pull request #660:
URL: https://github.com/apache/geode-native/pull/660#issuecomment-721399787
Ok @pdxcodemonkey and @pivotal-jbarrett I think I came up with an
integration test for this change. It works as follows:
* Set 5s connect-timeout.
* Deploy 1 locator.
* Add 1 non-existent locator to the pool.
* Send 64 concurrent requests to get the server list.
* By probability if there are no interlocks ~50%+-E% of the requests
should
have completed in a brief period of time.
* Note that E% is the error allowance percentage, which is set to 10%.
* Therefore a 10 seconds timeout is set in order to reach the request
completed treshold.
* Test passes if the number of completed requests before the timeout was
greater or equal to the thresholds, otherwise it fails.
It does not cover everything, but I'd would appreciate your feedback in
order to see If I am in the right direction. Thanks!
----------------------------------------------------------------
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)
