[
https://issues.apache.org/jira/browse/GEODE-8698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251317#comment-17251317
]
ASF GitHub Bot commented on GEODE-8698:
---------------------------------------
pivotal-jbarrett commented on pull request #699:
URL: https://github.com/apache/geode-native/pull/699#issuecomment-747663207
Do you know why there would have been a lock here in the first place.
Without rationalizing the locking, and yes its a mess, I fear removing locks.
Perhaps we should use
[`std::lock`](https://en.cppreference.com/w/cpp/thread/lock) to avoid deadlocks
on these locks. This would allow us to keep the locks in place until we have a
clearer picture about the locking relationships between these two. If you have
already done that analysis can you share it here?
----------------------------------------------------------------
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:
[email protected]
> Remove TcrPoolEndPoint::registerDM unnecessary DM lock
> ------------------------------------------------------
>
> Key: GEODE-8698
> URL: https://issues.apache.org/jira/browse/GEODE-8698
> Project: Geode
> Issue Type: Bug
> Components: native client
> Affects Versions: 1.12.0, 1.13.0
> Reporter: Mario Salazar de Torres
> Priority: Major
> Labels: pull-request-available
>
> Within TcrPoolEndPoint::registerDM, there is a lock for the DM connection
> queue mutex,
> which is not really necessary given that, as stated before, having a hard
> restriction on the connection number is not a must.
> Problem with this lock is that if any of the pool endpoints fails,
> connections are on hold while this endpoint is restored.
> One of the examples I've seen is that whenever a server goes down, and a pool
> with subscription enabled tries to re-open the subscription connection, all
> of the threads get locked due to this, even if they are not connecting to the
> server which is failing.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
