Alberto Gomez created GEODE-8613:
------------------------------------
Summary: 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
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)
