[
https://issues.apache.org/jira/browse/GEODE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215427#comment-17215427
]
ASF GitHub Bot commented on GEODE-8613:
---------------------------------------
pivotal-jbarrett commented on pull request #676:
URL: https://github.com/apache/geode-native/pull/676#issuecomment-710089765
> > I need more time to review this for correctness. I think the locking is
required here to both protect concurrent updates to the `m_poolSize` value in
various places as well as synchronize the CPU caches of this member.
>
> Wouldn't that already be guaranteed given that the type of `m_poolSize` is
`std::atomic<int32_t>`?
I hadn't looked into the type yet but mostly yes that should be safe. Though
if the pool and count are mutated independently there could be some issues with
a mismatch. I will poke into this later today.
----------------------------------------------------------------
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
> Remove exclusive access to pool connection creation/removal in native client
> ----------------------------------------------------------------------------
>
> Key: GEODE-8613
> URL: https://issues.apache.org/jira/browse/GEODE-8613
> Project: Geode
> Issue Type: Improvement
> Components: native client
> Reporter: Alberto Gomez
> Assignee: Alberto Gomez
> Priority: Major
> Labels: pull-request-available
>
> The Apache Geode C++ native client uses a mutex to grant exclusive access to
> the code that creates or removes pool connections (mutex_ member in
> ThinClientPoolDM class). The reason behind seems to be to perform atomically
> the creation of the connection and the update of the number of connections
> (m_poolSize) of the pool so that the number of connections in the pool and
> the counter are always aligned.
> This mutex is also used to protect the concurrent access to the connection
> queue structure (ConnectionQueue class).
> So, the mutex is used for two different purposes.
> Getting this mutex while creating/removing a pool connection has an impact in
> the performance of the client because connections cannot be created
> concurrently but there are also negative side effects that could lead to a
> freeze of the client if the connection creation is taking a long time (for
> example when the DNS is not available and name resolution calls take seconds
> to be answered).
> A particularly problematic case is that when a minimum number of connections
> has been configured in the client, loadconditioning or connection expiration
> is configured and the DNS becomes unavailable. If at a given point in time
> the number of connections in the pool is lower than the minimum configured,
> the thread that restores the minimum number of connections will try to create
> a new connection and will not release the mutex until it has finished. This
> will block other threads trying to get a connection from the queue
> unnecessarily.
> In this ticket, it is proposed to remove the locking of the mutex when the
> connection is created or removed. An alternative could be to create a new
> mutex for the creation or removal of connections so that the access to the
> ConnectionQueue is not affected by the creation/removal of connections but I
> do not consider it necessary just to maintain consistent (and not only
> eventually consistent) the number of connection of the pool and the counter
> of the connections (m_poolSize).
> Note that this ticket does not propose to remove the use of the mutex to
> access the ConnectionQueue. This will still be necessary to protect
> concurrent access to the connection queue data structure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
