[
https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208730#comment-17208730
]
ASF GitHub Bot commented on GEODE-8553:
---------------------------------------
gaussianrecurrence commented on pull request #660:
URL: https://github.com/apache/geode-native/pull/660#issuecomment-704262279
> If you push the build fix to your branch, my pipeline will run build/test
for all platforms automatically...
Oh that's nice. On either case I completed the execution of the tests.
They are all passing except for this new integration test:
BasicIPv6Test.queryResultForRange
Thing is the problem seems ip6-locahost does not exist in my host. I
modified it so it uses ::1 as binding address, just to see if that was the
problem but it failed due to ACE not being able to find the host. Which leds me
to think.
Shouldn't be IPV6 tests disabled if WITH_IPV6 CMake option is not enabled?
Or should I always compile with IPV6 in order to run the tests?
Summaziring here: "In theory all test should pass except for the IPV6 one"
----------------------------------------------------------------
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)
