[
https://issues.apache.org/jira/browse/GEODE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender updated GEODE-8613:
--------------------------------
Fix Version/s: 1.14.0
> 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
> Fix For: 1.14.0
>
>
> 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)
